Testing a ServiceNow family upgrade: what to prove before you sign

On ServiceNow, the upgrade is not a project you choose to start. It is a calendar the vendor sets, and the only question is whether your testing keeps up with it. This guide is for the person who signs off a family upgrade: what ServiceNow actually commits to, what changes underneath you, and the evidence worth collecting before production moves.

The calendar you are on

ServiceNow releases in families named after places. Moving between families is an upgrade; moving between patches and hotfixes inside a family is an update^[8]. Its stated policy is to support the most recent family and the one immediately before it. Two families ship a year, so you upgrade roughly once a year to stay supported, patches come only for supported families, and an instance that falls onto an unsupported family gets an upgrade scheduled by ServiceNow^[6].

As of mid-October 2026, Australia is the current GA family, Zurich is the previous one, and Brazil is in early availability, with Brazil Patch 1 released to early customers on October 8^[1],[2],[3]. Release Testing Preview opens at least 60 days before GA for sub-production instances^[7]. If you are not using that window to look at the next family, you are giving away the cheapest testing time you will get.

Why the evidence matters more than the plan

ServiceNow can roll back an update (a patch or hotfix), by default within 10 days. It does not offer that for a family upgrade, and it advises against restoring production from a backup^[8]. ServiceNow recommends upgrading from the instance furthest from production inward: development, then test, then production. Its guidance is smoke tests on development, ATF and optional UAT on test, and UAT only on production, because ATF is meant for non-production instances^[8]. Its own 51-step planning checklist ends with functional and performance tests on a production clone, a performance benchmark before the production upgrade, and UAT after it^[9]. In other words, the go/no-go decision rests entirely on what you proved on dev and test.

Step 0: scope the upgrade before anyone touches an instance

Scope starts with the release notes, read from your current family all the way to the target, not just the target on its own. ServiceNow’s Brazil notes say exactly that, and list upgrade paths from Australia, Zurich and Yokohama^[1]. If you are on Zurich, that means a choice: take Australia now, or wait for Brazil and read two families of notes. Either way, every product you run (ITSM, HR Service Delivery, Customer Service, ITOM, Security Operations, Finance and Supply Chain workflows) needs an owner who reads its section and rates the impact.

Upgrade Preview in Upgrade Center gives a view of the upgrade experience without upgrading the instance, and ServiceNow publishes sample upgrade project plans and the checklist to work from^[23]. Combine three inputs into a regression scope per product area: the release-note impact, how heavily you have customized it, and how many skipped records the development upgrade produces. High on any of the three means full regression; medium impact means targeted tests plus a smoke suite; the rest gets a smoke suite. Write the scope down before testing starts, so nobody argues about it in the go/no-go meeting.

Also check the patch level you are aiming for, not just the family. ServiceNow’s patching program publishes target versions each quarter; for Q4 2026 they are Australia Patch 5a, Zurich Patch 12 and Yokohama Patch 13 Hotfix 5a^[2]. Some features depend on a minimum patch: the ATF Test Agent, for example, needs Australia Patch 2 or Zurich Patch 9^[15].

Step 1: start from a clone you can trust

The checklist starts by cloning production to development^[9]. A clone copies data and metadata from the source’s most recent daily backup. It overwrites in-flight update sets and scoped apps that exist only on the target, so export them first. Logging, audit, notification, workflow context and license tables are excluded by default. Preservers keep target data, but child tables must be preserved one by one^[11]. Only the most recent clone can be rolled back, within seven days, or two on a sharded instance^[12].

Treat the clone as a test step with its own pass criteria: email redirected, integrations and credentials pointed at non-production partners, test users active, smoke suite green. The Clone & Instance Refresh Checklist lists the checks.

Step 2: make skipped records a test activity

The upgrade does not apply ServiceNow’s changes to objects you have customized. They appear on the upgrade record under Upgrade Center, Upgrade History, in Skipped Changes to Review, alongside Claim Outcomes to Review and Customization Unchanged. ServiceNow ranks them from Priority 1 (UI pages and UI macros) to Priority 5, and you resolve each as Retained, Reverted or Reviewed; some arrive as Skipped Manual Merge and need hand work^[10]. The checklist puts this review straight after the development upgrade^[9].

Step 3: use ATF for what it does well

The Automated Test Framework runs automated tests after a change and rolls back its test data. It supports Core UI, meaning classic lists and forms, but not Next Experience components such as UI Builder pages and landing pages. Results are deleted after 30 days by default^[13]. The ATF Test Generator and Cloud Runner Store app generates tests for forms, catalog items and flows and runs them on a ServiceNow-hosted browser, with two parallel tests free^[14]. From Australia, the ATF Test Agent writes and runs tests from a prompt; ServiceNow’s own presenter said it does not watch for application changes and that human review remains the gate^[15].

Three practical consequences for upgrade testing:

• Workspaces need another approach. If agents work in a UI Builder workspace, ATF will not reach that UI. Cover it manually or with another tool.
• Keep the evidence. Export suite results for each cycle or enable retention, or your sign-off evidence disappears after a month.
• Do not test as admin. A suite that runs as admin proves logic, not access.

The ATF Suite Coverage & Maintenance Tracker records runner, persona and UI surface per test and shows which critical processes have no coverage.

Step 4: test access as real people

Xanadu added Deny-Unless ACLs, an option to deny access by default when an ACL is misconfigured or empty, and rules to find such ACLs^[18]. Both supported families include them. Access regressions rarely show up in functional tests, so run a role matrix on test after every upgrade: each persona, table and operation, with an expected allow or deny, and at least as much attention on the denies. The ACL & Role Test Matrix counts any failed deny as a possible exposure.

Step 5: integrations, ERP and AI agents

Integration Hub spokes are distributed through the ServiceNow Store, each with its own version and compatible families^[19]. Confirm each spoke supports your target family and test it end to end. If you use ERP Canvas, note that it connects to SAP ECC and S/4HANA, Oracle E-Business Suite and Workday, and has supported updating SAP tables since 2024^[20]. Those flows belong in both teams’ regression scope.

AI features need a different kind of evidence. In August 2026 the Now Assist branding became ServiceNow Otto^[22]. For AI agents, ServiceNow’s agentic evaluations score many runs on task completeness, tool calling correctness and tool choice accuracy. Its guidance suggests 10 to 50 samples for initial testing and 100 to 300 for production readiness, warns that generated runs change real records, and says human review is essential^[21]. Run them in sub-production, before and after the upgrade, and compare.

Step 6: gate, then sign

Instance Scan checks for security, upgrade, manageability, user experience and performance issues, with full scans and point scans on a record, update set or application^[16]. Both Instance Scan and ATF suites can be run through the CI/CD API^[17], so you can block a fix update set that introduces new findings or failing tests before it reaches test. Scan production before the upgrade and again after, and explain the difference.

The Family Upgrade Test Plan & Runbook turns this into a dated plan, with regression scope by product area and a sign-off sheet that recommends go or no-go. For the shared criteria format, see the go/no-go readiness checklist.