ServiceNow ships two major platform releases every year, and skipping them isn't really an option — eventually your instance falls out of supported status. For most organizations, the upgrade itself isn't the hard part. What's hard is doing it without breaking something a customization was quietly depending on.
Start with an honest customization inventory
Before touching anything, get a real answer to a simple question: what has actually been customized in this instance? Not what's documented — what's actually there. Run an Update Set history review and a scoped-app audit, and compare it against what the team believes has been changed. The gap between those two lists is usually where upgrade surprises come from.
Use a sub-production instance that mirrors reality
Testing an upgrade against a sub-prod instance that hasn't been refreshed from production in eight months tells you very little. Clone production data into your test instance close to the upgrade window, so the customizations you're testing are the same ones actually running live.
Triage customizations into three buckets
Once you know what's customized, sort it:
- Skip-tested, low-risk — simple UI tweaks, cosmetic changes, things unlikely to interact with platform internals.
- Needs regression testing — anything touching core tables (incident, task, sys_user) or business logic that runs on every transaction.
- High-risk, needs a human review — heavily scripted integrations, anything using deprecated APIs, or customizations built years ago by someone no longer on the team.
That third bucket is where most real upgrade incidents come from. It deserves disproportionate attention relative to its size.
Read the upgrade's deprecated API list, seriously
Every release notes page includes a list of deprecated or removed APIs. It's easy to skim past. Cross-reference that list against your actual scripts before upgrade day, not after something breaks in production. This single step catches a large share of avoidable upgrade incidents.
Schedule the upgrade with a rollback plan, not just a maintenance window
A maintenance window tells you when you're doing the upgrade. It doesn't tell you what happens if something goes wrong at 2am. Before upgrade day, know exactly what your rollback path looks like and who owns the decision to trigger it.
The goal is a boring upgrade
None of this is about heroics during the upgrade window. It's about doing enough groundwork beforehand that the actual upgrade day is uneventful — which, for a twice-yearly recurring event, is exactly what you want it to be.