Upgrading ServiceNow from Washington DC to Yokohama

[nizar_tliba]

Pre-Upgrade Preparation

• Read the combined ServiceNow WDC to Yokohama release notes to understand new features, deprecations, and changes.

• Verify compatibility of custom applications, integrations, and plugins with the new version.

Preview upgrade and Assess Existing Customizations

• Run the Upgrade Readiness Check from the ServiceNow System Diagnostics module.

• Identify custom scripts, UI policies, business rules, and workflows that may be affected.

• Document any customizations that require refactoring.

Backup Your Instance

• Request a Full clone back from Production instance to a temporary sub-production instance.

• Export any important update sets, configurations, and reports.

 Notify Stakeholders and Plan Downtime

• Inform end users, developers, and administrators about the upgrade timeline.

• Schedule a maintenance window to minimize disruption.

Upgrade Execution

Clone Sub-Production Instances

• Clone the production environment into a sub-production instance (e.g., dev or test).

• Ensure data integrity and validate the cloned instance.

Apply the Upgrade in a Sandbox Environment

• Create a Change from HI portal (Now Support) to request the upgrade.

• Select the Yokohama release package and initiate the upgrade.

• Monitor the Upgrade Monitor for errors and conflicts.

Resolve Upgrade Conflicts

• Use the Upgrade History module to review skipped updates.

• Resolve conflicts using the Compare and Revert functionality.

• Test and validate that custom scripts, workflows, and integrations function correctly.

• Use Upgrade Plan to automate any post-upgrade task.

User Acceptance Testing (UAT)

• Define test cases based on business-critical processes.

• Involve key users to validate system behavior.

• Address any bugs or unexpected issues.

Production Upgrade

Schedule and Execute the Upgrade

• Confirm no active incidents or pending changes.

• Apply the upgrade to the production instance.

• Monitor performance and logs for post-upgrade issues.

Post-Upgrade Validation

• Perform smoke testing on core functionalities.

• Verify integration points, APIs, and data consistency.

• Ensure that performance metrics are within acceptable ranges.

Communicate Upgrade Completion

• Notify stakeholders that the upgrade was successful.

• Provide documentation on new features and enhancements.

• Monitor user feedback and address any post-upgrade concerns.

Post-Upgrade Optimization

Review Performance and Logs

• Use the Instance Observer portal to analyze system performance.

• Check logs for errors, warnings, or anomalies.

Optimize and Refactor Customizations

• Update configurations to align with best practices.

• Leverage new Yokohama features to replace outdated customizations.

Continuous Monitoring and Improvements

• Request scheduled health scans from Servicenow.

• Gather feedback from users to identify areas for improvement.

[Mark Manders]

Have you ever done an upgrade, or are you just creating posts by copy/pasting (WRONG!!!) ChatGPT generated content? 

Did you even read what you posted?

- Please tell me what the upgrade readiness check is. There is no such module. 

- Why document customizations on upgrade prep. That should have been done while creating the customizations.

- Why contact ServiceNow Support for a data backup? Backups are part of your contract and created daily.
- You are completely skipping data preservers and excludes while cloning
- No mention of cleanup scripts

- Apply the upgrade to a sandbox instance? You just cloned PROD over non-PROD. What do you mean, sandbox instance?

- Upgrades need to be scheduled through NowSupport. Good luck doing that from Upgrade History.

- Are you living in the 1950s? Use Upgrade Center / Upgrade Monitor to check on the upgrade and the skipped changes.
- You are creating test cases after the upgrade is already done? Why not before? Where is ATF in this post? Or Instance Scan for that matter?

- Why shouldn't there be any active incidents or changes before upgrading PROD? The instance stays up and can be used.

- Providing documentation should not be done after PROD upgrade is done, but before the process starts. How are your key users testing without knowing new/changed functionality?

- Performance Analytics to analyze system performance? Really? Please tell me how to do that with PA? 

- Next to that: if you really performed this upgrade, you would know that Performance Analytics is now under Platform Analytics.

- Updating scripts to align with best practices after the upgrade of PROD is done? That should be part of the development process, not the upgrade process.

- Replacing outdated customizations should be done before UAT, so it can be released as part of the upgrade.

- Health checks should be created before the upgrade process starts.

If you want to contribute to the ServiceNow community, do it with content that you know something about. This post only shows that you have no idea what an upgrade is about and the worst thing is that people will read it and get completely confused when following it.