A ServiceNow family upgrade is not complete when the upgrade engine finishes. The real work is proving that your business processes, integrations, security controls, and customizations still behave correctly.
The most important evidence often appears in Upgrade History, especially the skipped changes list. A skipped record means ServiceNow detected a customer modification and preserved it instead of automatically replacing it with the new out-of-box version. That protection prevents data loss, but it also leaves your instance without some vendor changes until you review the record.
Use this checklist to turn skipped changes into deliberate decisions rather than last-minute production surprises.
Upgrade testing is useful only when the sub-production instance resembles production. Clone production into a dedicated test or upgrade environment before beginning your technical review.
Before the clone:
After the clone, validate that the instance has the expected users, groups, update sets, custom tables, and integration configuration. A stale clone can produce a reassuring but inaccurate test result.
Do not wait for skipped changes to tell you what has been customized. Build an inventory of business rules, script includes, client scripts, UI policies, ACLs, notifications, workflows, flows, integrations, and modified dictionary records.
For each important customization, capture:
This inventory makes review faster because the team can distinguish intentional business behavior from an abandoned experiment.
Run the upgrade in sub-production first. Record its start and finish time, duration, warnings, errors, and counts of upgraded and skipped records. These numbers become a baseline for the production change plan.
Review System Diagnostics > Upgrade History and open the completed upgrade record. Export or assign the skipped changes list so that every item has an owner and resolution status. Avoid resolving records directly in production without first validating the decision in the upgraded clone.
Not every skipped record deserves equal attention. Prioritize records that can affect availability, access, or transaction volume:
Also flag records with no known owner. An undocumented customization on a critical table is a risk even when its code looks simple.
A good skipped-change review considers three versions:
The difference between the customer version and previous baseline reveals what your team changed. The difference between the previous and new baselines reveals what ServiceNow changed. This separation is essential: comparing only the customer version with the new baseline mixes both sets of changes and makes intent harder to identify.
Use the upgrade comparison tools to inspect the fields and script differences. For scripts, look beyond added lines. Check changed conditions, execution order, APIs, null handling, roles, and queries.
Every skipped change should end with one documented decision.
Retain it when the business requirement still exists and the new baseline does not address it. Confirm that the code uses supported APIs and still works in the target release.
Revert when the customization is obsolete, duplicates new platform behavior, or was never intended for production. Test the affected process after reverting.
Merge when you need the business customization and ServiceNow's new fixes or features. Rebuild the smallest possible customization on top of the new baseline rather than copying the entire old script forward.
For every outcome, record the rationale, reviewer, date, test evidence, and deployment method.
A form that loads without errors does not prove an upgrade succeeded. Test complete user journeys and their downstream effects.
Your regression suite should cover:
Include negative tests. Verify that unauthorized users cannot read or modify protected data and that failed integrations create visible, actionable errors.
Compare objective results between the pre-upgrade and upgraded environments. Review slow transactions, node logs, scheduled job duration, flow execution time, integration latency, and query behavior on heavily used tables.
Pay special attention to custom scripts that query inside loops, run synchronously, or execute on every update. An upgrade may expose an existing inefficiency because platform behavior or data volume has changed.
After remediation and user acceptance testing, repeat the process on a newly refreshed clone if time allows. A rehearsal confirms the final sequence, validates update sets or application deployments, and produces a realistic outage estimate.
Your production runbook should include:
For the first 24 to 72 hours, monitor failed transactions, integration queues, flow executions, email delivery, scheduled jobs, authentication, and support volume. Compare results with the baseline captured during rehearsal.
Do not close the upgrade solely because users can log in. Close it when critical tests pass, skipped changes are accounted for, operational metrics are stable, and unresolved issues have owners.
ServiceNow upgrades become predictable when every customization has an owner, every skipped change has a decision, and every decision has test evidence. The goal is not to preserve all custom code or blindly accept every new baseline. It is to keep required business behavior while adopting platform fixes and reducing future maintenance.
Treat the upgraded clone as a rehearsal, not a sandbox. That discipline turns upgrade weekend from guesswork into a controlled release.