Why ServiceNow upgrades get delayed

ServiceNow names every release after a city. Xanadu. Yokohama. Washington. Each one arrives with new capabilities, security patches and performance improvements. Each one also requires your team to understand what customisations you have built, what integrations depend on them, and what might break if you touch them.

That is where most organisations get stuck.

The problem is not the upgrade itself. The problem is the technical debt that accumulates between upgrades. Scripts nobody has reviewed in three years. Business rules that fire on events they were never designed for. Customisations that were documented once, by someone who has since left the company.

In our experience, most teams that come to us for an upgrade are two or three versions behind. Not because they do not care. Because every previous upgrade felt too risky to attempt without help.

The longer you wait, the harder it gets. Two missed versions means two cycles of technical debt compounding on top of each other. Three missed versions means your upgrade project is now a remediation project first.

Get an upgrade assessment →

What changes between ServiceNow versions

ServiceNow upgrades are not like software patches. Each major release introduces changes to the platform that can affect how your customisations behave. Understanding what type of change is coming tells you where to focus your preparation.

01	Platform core changes Changes to how the Now Platform handles scripting, APIs and database operations. These are the most likely to break existing customisations. ServiceNow publishes a compatibility guide for each release, but reading it requires understanding what you have built in the first place.
02	UI and portal updates ServiceNow has been moving from Classic UI to Next Experience (Polaris). If your organisation has not completed this transition, each new release pushes the legacy interface further from the supported path. Custom portal pages and UI macros are the most commonly affected.
03	ITSM and ITOM module updates Changes to incident management, change management, CMDB schema and ITOM capabilities. These affect workflows, SLAs and reporting. If your team has heavily customised these areas, each upgrade requires careful validation before go-live.
04	AI and automation capabilities Each recent release has added significant Now Assist and agentic AI capabilities. These require specific configurations to activate and may interact with existing automation workflows. Teams that stay current get access to these features. Teams that fall behind do not.

What makes a ServiceNow upgrade go wrong

Most upgrade problems are predictable. They come from the same sources every time.

Skipped versions Each skipped version adds another layer of changes your team has not validated. Jumping two or three versions means the upgrade project grows significantly in scope and risk.

Undocumented customisations If your team cannot list every modification made to out-of-box ServiceNow functionality, the upgrade will surface surprises. The question is not whether something will break. It is whether you will know what broke and why.

No upgrade environment Upgrading directly on a production instance without a tested sub-production environment is the fastest way to cause an outage. A proper upgrade path runs through at minimum a development and a UAT instance first.

Insufficient testing coverage Upgrade testing is only as good as your test cases. If your team has not maintained a regression test suite, the upgrade validation relies on people manually checking what they can remember. Critical paths get missed.

How to upgrade ServiceNow without breaking production: a step-by-step guide

A ServiceNow upgrade done well is a structured process, not a leap of faith. Here is the approach we use with clients.

Step 1	Run a pre-upgrade health check Before anything else, understand the current state of your instance. How many customisations exist? Which ones touch out-of-box tables or scripts? How accurate is your CMDB? A two-week health check gives you a complete picture of what you are upgrading and what the risks actually are. If you are not sure what state your instance is in, read our article on ServiceNow platform health check before planning an upgrade.
Step 2	Review ServiceNow upgrade notes and compatibility ServiceNow publishes release notes and an upgrade centre for every version. Review the breaking changes, deprecated features and compatibility notes specific to your modules. Pay particular attention to any changes that affect scripting, APIs, or CMDB schema if your instance relies on these heavily.
Step 3	Remediate custom code before upgrading ServiceNow flags customisations that conflict with the new version during the upgrade process. The goal is to resolve as many of these as possible before the upgrade runs, not after. This means reviewing skip records, update sets and any scripts that override out-of-box behaviour.
Step 4	Upgrade development, then UAT, then production Never upgrade production first. The standard path is development instance first, then user acceptance testing, then production. Each environment surfaces different issues. Development catches configuration problems. UAT catches workflow and integration issues that only appear under realistic conditions.
Step 5	Run regression testing against critical workflows Test every critical business process: incident management, change management, service requests, integrations with SAP or other enterprise systems, and any ITOM workflows that depend on Discovery or Service Mapping. Automated test suites are significantly faster and more reliable than manual testing at this stage.
Step 6	Plan your rollback and go-live window Define a rollback plan before you start the production upgrade. Know exactly what you will do if a critical issue is discovered post-go-live. Schedule the upgrade during a low-traffic window with your team available. The first 48 hours after a production upgrade require active monitoring.

How long does a ServiceNow upgrade take?

The honest answer depends almost entirely on how much technical debt your instance carries and how many versions you are behind.

One version behind, low technical debt 2 to 4 weeks from health check to production go-live.

One version behind, high technical debt 4 to 8 weeks. Most of the extra time goes into custom code remediation, not the upgrade itself.

Two or more versions behind Not realistically estimable upfront. The timeline depends on an individual project plan built around what the health check finds.

ServiceNow upgrade guide: questions we get asked

Can we skip ServiceNow versions when upgrading? Technically yes. ServiceNow allows you to upgrade across multiple versions. In practice, each skipped version adds untested changes and increases the risk of post-upgrade issues. If you are two or more versions behind, we recommend upgrading to an intermediate version first, stabilising, and then continuing.

What is a ServiceNow skip record and why does it matter? A skip record is created when the upgrade process detects that a customisation conflicts with an out-of-box change in the new version. ServiceNow skips the update to preserve your customisation. Skip records are not errors, but they require review: each one means a decision about whether your customisation should be preserved or replaced with the new out-of-box behaviour. Unreviewed skip records accumulate across upgrades and become a source of technical debt.

How do we know if our customisations will break during an upgrade? ServiceNow provides an Upgrade Preview tool that simulates the upgrade and identifies conflicts before you commit. Running this on your development instance first gives you a list of at-risk customisations. A pre-upgrade health check goes further, reviewing actual usage patterns and flagging customisations that are likely to cause issues even if the Upgrade Preview does not flag them.

Should we upgrade to the latest ServiceNow version or the previous one? For most organisations, we recommend upgrading to the version that has been generally available for at least three months. Brand new releases have known issues that get patched quickly. Waiting one patch cycle reduces risk without significantly delaying access to new capabilities.

What happens if something breaks after go-live? Post-upgrade issues fall into two categories: issues that were visible in testing but accepted, and issues that only appear under production load. The first category is managed through your UAT sign-off process. The second requires active monitoring in the first 48 hours and a clear escalation path. This is why having experienced ServiceNow engineers available immediately after go-live matters more than most teams expect.

What a successful ServiceNow upgrade looks like

A well-executed upgrade is not memorable. The platform goes down for a maintenance window. It comes back up on the new version. Users notice the new features, not the disruption.

Getting there requires honest preparation: knowing what you have built, cleaning up what no longer serves you, testing thoroughly, and having experienced people ready at go-live. It is a project, not a button press.

The organisations that upgrade on schedule, every six months, are the ones that treat upgrades as routine maintenance rather than emergency projects. The earlier you start, the smaller the project.

Key takeaways - The problem is not the upgrade. It is the technical debt that accumulates between upgrades. - Skipping versions compounds risk. Two versions behind means double the untested changes. - Always upgrade development and UAT before production. Never go straight to production. - Start with a health check. You cannot plan an upgrade without knowing what you are upgrading. - Organisations that upgrade on schedule treat it as routine maintenance. Those that do not, treat it as a crisis.

Ready to upgrade your ServiceNow instance?

We run pre-upgrade assessments and end-to-end upgrade projects for mid-size and enterprise ServiceNow customers. Start with a health check to understand what you are working with, then build a plan that fits your timeline.

Get an upgrade assessment →

HappyMan Solutions
Your system works. Your team is happy. That's the job.