The Ultimate Guide to Upgrading Your ServiceNow Instance: Step-by-Step

[Bill Martin]

Keeping your ServiceNow instance up-to-date is essential for ensuring smooth operations, better performance, and access to new features. This blog post walks you through the ServiceNow full upgrade process, ensuring you avoid common pitfalls and minimize downtime.

Why Upgrade Your ServiceNow Instance?

Upgrading allows your organization to:

• Access new features and improvements
• Apply security patches to maintain system integrity
• Improve performance and stay aligned with the latest best practices

By following this step-by-step guide, you can manage upgrades with confidence and avoid unexpected disruptions.

Step-by-Step ServiceNow Upgrade Process

Below is a breakdown of the 9 key steps to follow for a successful upgrade.

1. Preparation Before the Upgrade

• Ensure recent backups are available in case of rollback.
• Notify stakeholders and users of the planned upgrade.
• Review customizations, integrations, and plugins that could be impacted.

2. Review Release Notes

• Understand new features and bug fixes introduced in the release.
• Identify any deprecated features to ensure continuity.
• Learn about resolved performance issues that may benefit your setup.

3. Plan and Schedule the Upgrade

• Select a low-usage window to minimize disruption.
• Inform relevant personnel to be available during the upgrade.
• Prepare a rollback plan as a contingency.

4. Request the Upgrade

1. Log in to the ServiceNow HI Portal: hi.service-now.com.
2. Go to Upgrades > Instance Upgrades.
3. Request the upgrade for your non-production instance first.
4. Select the target version and follow the prompts.

5. Upgrade a Non-Production Instance First

• Test all customizations and integrations to avoid surprises in production.
• Simulate common user workflows to ensure everything functions correctly.
• Monitor the system for performance changes after the upgrade.

6. Test the Upgraded Instance

• Conduct unit testing to validate core functionalities.
• Perform regression testing to ensure nothing broke during the upgrade.
• Test integrations with external applications, APIs, or plugins.
• Get end-users involved for User Acceptance Testing (UAT).

7. Fix Any Issues Found

• Use the Upgrade Monitor to check for conflicts.
• Adjust customizations (scripts, workflows) as needed.
• Resolve any errors in logs to ensure a stable production environment.

8. Upgrade the Production Instance

• Schedule the production upgrade in the HI Portal.
• Communicate with users about the timing and any downtime.
• Monitor the upgrade progress using the Upgrade Monitor.

9. Post-Upgrade Tasks

• Perform smoke testing to ensure all critical systems work.
• Address any minor bugs or post-upgrade issues.
• Update documentation to reflect new features and changes.
• Monitor performance over the next few days to catch any hidden issues.

Conclusion

Upgrading a ServiceNow instance is a critical task that ensures your platform stays secure, efficient, and packed with the latest features. Following these Nine (9) steps to upgrade ServiceNow Instance will help you manage the upgrade with minimal downtime and maximum confidence.

Before tackling your production environment, always upgrade a non-production instance first and test thoroughly to identify and fix any issues early.

[Bill Martin · Accepted solution]

This is an excellent step-by-step breakdown of the ServiceNow upgrade lifecycle that highlights the critical importance of non-production testing and skip-log review. Following this structured 9-step approach is the best way to mitigate risk and ensure a seamless transition to the latest platform features.

If you found this guide helpful, please Like this post so others in the community can easily find these steps!

[AgataF]

Hello Bill, 

Thank you for sharing a high-level step-by-step breakdown of the ServiceNow upgrade lifecycle. We are considering to upgrade DEV and TEST separately to have time for the testing performed for each environment. Suggestion that we've made is to keep a change freeze period prolonged as the versions of platform in each non-production environment will differ. What are your thoughts on this? We are considering to have DEV and TEST upgrade performed at once, but we do also have a heavy customizations. 

Kind Regards, 

Agata

[Bill Martin]

Hi @AgataF ,

Happy to share how we usually approach this. The heavy customization piece is really what drives the decision for you.

On the environments themselves - DEV, TEST and PROD is the bare minimum, but with a heavily customized instance I'd push for more than that if you can.

Having a proper UAT or staging tier (and a separate integration or sandbox instance where it makes sense) really pays off, because it gives you somewhere realistic to prove things out before PROD.

Match the number of instances to how much you've customized and how many integrations you run, not just the standard three.

On the DEV and TEST timing, I'd actually lean away from a big gap between them. Running the two on different versions for a while makes it painful to move update sets between them, and it tends to stretch the freeze out rather than shrink it.

We keep them close together and go DEV, then TEST/UAT, then PROD.

A couple of things that have saved us a lot of grief:

- Clone PROD down over DEV and TEST before you upgrade, so each one looks like production. Just back up any in-flight dev work first.

- Work the skipped records in the Upgrade Center properly. Each one is a keep-or-revert-to-OOB call. Pull them early, note your decisions, and reuse those decisions in the next environment - that's what keeps DEV and TEST in sync and saves you retesting from scratch.

- On the freeze, I wouldn't drag it out. Given how often ServiceNow ships patches, a long freeze usually creates more risk than it avoids. We just limit the significant changes during the window instead.

- Lean on ATF and a solid regression pass on non-prod, then UAT before PROD, with the focus on your customizations and integrations.

The official upgrade docs (Upgrade your instance / Upgrade Center) go into the clone-first approach, skipped records, ATF and rollback if you want the detail.

Hope that helps,