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.

Confirm which ServiceNow instances are in-scope for upgrade.

Confirm the instance hosting model. For example, ServiceNow cloud, on-premise, or off-premise.

Based on the Orlando release notes and other release materials, determine new functionality or notable changes that need to be validated after the upgrade.

Confirm plans to enable or disable features introduced in the new product release.

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.

Create a project plan for cloning, upgrading, and testing.

Identify the core team of testers, power users, and key stakeholders required to validate functionality in the ServiceNow instances before and after the upgrade.

Confirm whether there are any change freeze windows impacting the timing for environment clones or upgrades. For example, end quarter.

1. Development and testing can be frozen until the production upgrade is completed.
2. 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.
3. 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.

Confirm the availability of other systems required for integration testing (key resources and environments).

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.

Confirm the testing scope and approach.

Create a comprehensive test plan including test cases for all core instance functionality and integrations.

Confirm the method for tracking any defects identified during testing.

Confirm whether there are any change freeze windows impacting the timing for environment clones or upgrades. For example, end quarter.

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.

Check the configuration of the Check distribution for possible upgrade scheduled job to view how often and when it runs.

Verify that the Check distribution for possible upgrade sys_trigger is set properly for upgrading.

Verify that the Check database for possible upgrade sys_trigger is set properly for upgrading.

Schedule the upgrade in HI.

If applicable, request a version entitlement.

Using the Upgrade Monitor, monitor the upgrade to your instance and validate that the upgrade to your development instance is complete.

After the upgrade for your development instance is complete, process the skipped records list in the Upgrade Monitor.

Identify your update sets.

Before and after upgrading, conduct smoke tests on your development instance. Use your comprehensive test plan to perform functional testing.

On your production instance, create a system clone and select your development instance as the Target instance.

Schedule the non-production upgrade in HI and verify your upgrade configurations.

Validate that the upgrade to your non-production instance is complete.

Install any optional plugins that were installed on your development instance.

Install any custom applications and post-upgrade fix scripts that you need.

Install update sets.

Perform functional testing and monitor the performance of your instance.

Confirm sign-off from IT and Business stakeholders that all non-production instance defects have been fixed and validated in update sets.

Confirm the core team of key stakeholders required to validate functionality in the ServiceNow instance after the production upgrade.

Confirm coverage for Day 1 support post-upgrade.

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.

Schedule a walkthrough and sign-off of the Implementation Plan with key stakeholders and the core team.

Submit and obtain approvals for change records as required by the organization change process.

Send a communication to key stakeholders and end users with details for the production upgrade outage, new features, and so forth.

Profile the performance of your instance before upgrading.

Use the ServiceNow Performance homepage to document the performance of your instance before the upgrade.

On your clone, perform functional testing and monitor the performance of your instance.

Schedule the upgrade in HI.

If applicable, request a version entitlement.

Monitor the upgrade to your instance and validate that the upgrade to your production instance is complete.

Apply any update sets and post-upgrade fix scripts that you have.

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.