Week 3 of 8
Clones and instance refresh
ServiceNow’s own upgrade checklist starts by cloning production to development. A clone copies data and metadata from the latest daily backup, and it overwrites work in progress on the target: open update sets and scoped apps that exist only there.
Clone profiles control what comes across. Logging, audit, notification, workflow context and license tables are excluded by default. Preservers keep target data, but only for the table and its parents; child tables must be preserved one by one.
This week: write the clone down as a checklist and test its result
- Before the clone, export every in-flight update set and list unreleased apps you must reinstall afterwards.
- Review the clone profile: exclusions, preservers (including child tables) and cleanup scripts. Record why each custom entry exists.
- After the clone, check that outbound email, integration endpoints, credentials and MID Servers point at non-production targets before anyone tests.
- Run a short smoke suite on the cloned instance. A failed smoke means the cycle has not started.
- Note the rollback limit: only the most recent clone, within seven days. Decide in advance who calls it.
Number of the week
7 days
to roll back the most recent clone (two days on a sharded instance). After that, the clone is permanent.
Source: ServiceNow docs, Roll back a clone (Australia)Use this week
- ServiceNow Clone & Instance Refresh Checklist →
Before, during and after checks for every clone, plus a profile register for exclusions, preservers and cleanup scripts.
- Test Schedule & Cycle Calendar →
Clones, upgrades and test cycles on one calendar, with freezes.
Next week: ATF. Where ServiceNow’s own test framework is strong, and where it stops.
Get the playbook in your inbox, one week at a time
Subscribe free and every template in the library is yours.