| Phase 1 - Read the release notes and plan your upgrade |
| 1 |
Review the Orlando release notes for the target
ServiceNow feature release and patch, in addition to product and release
documentation.
For Orlando-specific upgrade
considerations, see Pre- and post-upgrade tasks for various products.
|
 |
|
|
| Phase 2 - Complete these
planning tasks. |
| 2 |
Confirm which ServiceNow instances are in-scope for upgrade.
|
|
|
|
| 3 |
Confirm the instance hosting model. For example, ServiceNow cloud, on-premise,
or off-premise.
|
|
|
|
| 4 |
Based on the Orlando release notes and other release
materials, determine new functionality or notable changes that need to be
validated after the upgrade.
|
|
|
|
| 5 |
Confirm plans to enable or disable features introduced in the new product
release.
|
|
|
|
| 6 |
Review the Browser support to determine browser
prerequisites. For example, versions and types supported, and additional
requirements for new UI versions. Compare these supported browsers to your
corporate standard and identify any gaps.
|
|
|
|
| 7 |
Create a project plan for cloning, upgrading, and testing.
|
|
|
|
| 8 |
Identify the core team of testers, power users, and key stakeholders required
to validate functionality in the ServiceNow instances before and after the
upgrade.
|
|
|
|
| 9 |
Confirm whether there are
any
change freeze windows impacting the timing for environment
clones or upgrades. For example, end quarter.
|
|
|
|
| 10 |
Confirm which of the following situations applies to your ServiceNow
non-production instances:
- Development and testing can be frozen until the production upgrade is
completed.
- Continued development (and testing) activities need to continue in a
non-production instance while upgrade, remediation, and testing activities are
performed in parallel on another instance.
- Once the final upgrade to your production instance is complete, the cloning
of your final production instance to your non-production instance will wait
until after the production upgrade is complete.
|
|
|
|
| 11 |
Confirm the availability of other systems required for integration testing (key
resources and environments).
|
|
|
|
| 12 |
Confirm whether there are any restrictions in which ServiceNow instances can be
used for integration testing. For example, an interfacing system is only set up
to access a specific ServiceNow test instance.
|
|
|
|
| 13 |
Confirm the testing scope and approach.
|
|
|
|
| 14 |
Create a comprehensive test plan including test cases for all core instance
functionality and integrations.
|
|
|
|
| 15 |
Confirm the method for tracking any defects identified during testing.
|
|
|
|
| 16 |
Create a high-level implementation plan that covers:
- the sequence and timing to upgrade non-production and production
instances
- the instances to be cloned
- the instance to be used for integration testing.
|
|
|
|
| 17 |
Confirm whether there are any change freeze windows impacting the timing
for environment clones or upgrades. For example, end quarter.
Responsible: ServiceNow or Customer |
|
|
|
| 18 |
Determine whether existing internal training materials, Knowledge Base articles
in the customer instance, or other supporting documentation must be updated to
align with the upgraded version. For example, changes in functionality or user
interface.
|
|
|
|
| 19 |
Optional: Schedule the ServiceNow Configuration Review, which
provides recommendations to align the customer configurations with ServiceNow best
practices. Note: There may be a service charge and require professional services
engagement. |
|
|
|
| 20 |
On your production instance, create a system clone and select your
development instance as the Target instance. Notify
impacted users and internal stakeholders of the scheduled date/time for cloning
(from production) and upgrade of the non-production instance. Note: It is
important to test on a system that reflects the production instance as closely
as possible. If your non-production and production instances are the same
size, include the production audit log and the attachment data, and ensure
that you have deselected the exclude options.
|
|
|
|
| Phase 3 - Verify your upgrade configurations and schedule the development
instance upgrade in HI |
| 21 |
Check the configuration of the Upgrade
scheduled job to view how often and when it runs.
|
|
|
|
| 22 |
Verify that the Upgrade sys_trigger is set
properly for upgrading.
|
|
|
|
| 23 |
Verify that the Check Upgrade Script
sys_trigger is set properly for upgrading.
|
|
|
|
| 24 |
Schedule the upgrade in HI.
|
|
|
|
| 25 |
If applicable, request a version entitlement.
|
|
|
|
| Phase 4 - Upgrade and validate the development instance |
| 26 |
Using the Upgrade Monitor, monitor the upgrade to your instance and
validate that the upgrade to your development instance is complete.
|
|
|
|
| 27 |
After the upgrade for your development instance is complete, process the skipped records
list in the Upgrade
Monitor.
|
|
|
|
| 28 |
Identify your update sets.
|
|
|
|
| 29 |
Before and after upgrading, conduct smoke tests on your development instance. Use your
comprehensive test plan to perform functional testing.
|
|
|
|
| Phase 5 - If applicable: Upgrade and validate your other non-production
instances, such as your test instance |
| 30 |
On your production instance, create a system clone and select your
development instance as the Target instance.
|
|
|
|
| 31 |
Schedule the non-production upgrade in HI and verify your upgrade
configurations.
|
|
|
|
| 32 |
Validate that the upgrade to your non-production instance is complete.
|
|
|
|
| 33 |
Install any optional plugins that were installed on your development
instance.
|
|
|
|
| 34 |
Install any custom applications and post-upgrade fix scripts that you need.
|
|
|
|
| 35 |
Install update sets.
|
|
|
|
| 36 |
Perform functional testing and monitor the performance of your instance.
|
|
|
|
| Phase 6 - Prepare to upgrade the production instance |
| 37 |
Confirm sign-off from IT and Business stakeholders that all non-production
instance defects have been fixed and validated in update sets.
Responsible: Customer |
|
|
|
| 38 |
Confirm the core team of key stakeholders required to validate
functionality in the ServiceNow instance after the production upgrade.
Responsible: Customer |
|
|
|
| 39 |
Confirm coverage for Day 1 support post-upgrade. Responsible:
Customer |
|
|
|
| 40 |
Create a Production Upgrade Implementation Plan that includes all upgrade
steps, roles and responsibilities, communication plans, key contacts, support
coverage for Day 1, and so forth. Responsible: Customer |
|
|
|
| 41 |
Schedule a walkthrough and sign-off of the Implementation Plan with key
stakeholders and the core team. Responsible: Customer |
|
|
|
| 42 |
Submit and obtain approvals for change records as required by the
organization change process. Responsible: Customer |
|
|
|
| 43 |
Send a communication to key stakeholders and end users with details for
the production upgrade outage, new features, and so forth. Responsible:
Customer |
|
|
|
| 44 |
Profile the performance of your instance before
upgrading.
|
|
|
|
| 45 |
Use the ServiceNow Performance homepage to
document the performance of your instance before the upgrade.
|
|
|
|
| 46 |
On your clone, perform functional testing and monitor the
performance of your instance.
|
|
|
|
| Phase 7 - Upgrade the production instance |
| 47 |
Schedule the upgrade in HI.
|
|
|
|
| 48 |
If applicable, request a version entitlement.
|
|
|
|
| 49 |
Monitor the upgrade to your
instance and validate that the
upgrade to your production instance is complete.
|
|
|
|
| 50 |
Apply any update sets and post-upgrade fix scripts that you
have.
|
|
|
|
| 51 |
Validate and test your instance by conducting user acceptance
testing (UAT). Verify
with all key stakeholders that the system is performing properly after
production upgrade, and key functionality is available.
|
|
|
|
