Leaving ServiceNow: What to Check in Your Migration SOW
Before you sign a ServiceNow migration statement of work (SOW), ask one question: what happens to the records that aren’t in it?
Say an auditor asks for a change approval from 2021, six months after ServiceNow is switched off. Who pulls it, and from where? If the SOW doesn’t say, the answer is nobody.
Put the historical records in the contract. Once the SOW is signed, anything outside it has no owner, no budget and no deadline. Adding it later means a change order, usually priced when the vendor knows you have no alternative, and sometimes after the source data is already gone.
What the SOW says vs what actually happens
| What the SOW says | What it usually means in practice |
|---|---|
| “Migrate open and active records” | Everything closed stays behind in ServiceNow |
| “Historical data excluded” | No owner, no budget and no deadline for the history |
| “Customer to export legacy data” | Nobody has checked what export format or access you’ll get |
| “Two-year history window” | Older approvals and incidents are left without a home |
| “Go-live acceptance” | Nobody tested whether anyone can still find old records |
What migration teams are built to cover
Migration teams focus on what the new platform needs on day one: open incidents, active requests and changes, current users, live configuration, integrations and a set window of history. That data gets mapped, transformed and tested in the new system.
Older records add mapping, attachment and testing work without helping day-one operations, so they usually get cut. That’s often the right call for the migration. It’s the wrong call if nobody picks them up.
Set up the records workstream separately
Start with what people will need to retrieve, not with a tool. For each type of record you’re keeping, write down:
- who owns it and why it has to be kept
- how long it’s kept and how it’s disposed of
- the fields, related records, journal entries, approvals and attachments needed to understand it
- who needs to search for it and produce it
- the security, logging and backup requirements for the retained copy
- the test it has to pass before shutdown
Keep records for a documented business, contract or legal reason. “Keep everything” sounds safe, but it’s still a decision, and it comes with storage, security and retrieval costs.
Know your last day of access
ServiceNow has previously described a suspension period of around 30 days between a hosted instance being switched off and being retired. Don’t plan around that. Confirm the current process, your export deadline and any recovery options in Now Support and your agreement, and finish extraction and testing before suspension starts.
Backups don’t solve this either. ServiceNow’s backups exist to recover the platform, not to give you a records service after your contract ends. Decide what retention period and retrieval service your business actually needs, and specify it.
Spell out the export
Agree how the data comes out before you set a shutdown date. Depending on your agreement and tooling, that could be an export, API extraction, replication or a database copy. Write down the format, tables, attachments, permissions, cost and deadline. If you’re counting on a database copy, check your contract actually entitles you to one.
Then require an extraction report: source instance, filters, extraction time, expected and delivered counts, failed records, attachment totals and any transformations. If an API rebuilds records into a new database, the report should include the mappings needed to read that copy.
The archive test that matters
Before shutdown, pick five records: one with a long journal history, one with attachments, one with custom fields, one with related tasks and one with restricted access. Using only the proposed archive, have a real user find, open and export each one. Compare the results against the live instance while you still have it.
Then write that test into the SOW: the record counts reconcile, attachments open, users can produce what they need, restricted users are blocked and the business owner signs off on any known gaps. Set retrieval time targets using your own records and volumes.
“We have over 3 million records and we can provide any information needed thanks to Cortex.” IT leader, Cortex customer
Where Cortex Archive for ServiceNow fits in
Why this comes from experience, not theory Cortex Archive runs across 100+ enterprises. One 32,000-employee education organization moving from Cherwell to their new ITSM platform archived more than 3 million records in a single weekend, without slowing down go-live.
Cortex Archive for ServiceNow is a self-hosted, read-only way to search and read your historical records, relationships and attachments. It connects to the source data with read-only credentials and keeps its own configuration separately.
The ServiceNow Sync Utility, covered in the current Cortex release notes, pulls exports through the API into PostgreSQL and retries failed records. Cortex then gives you full-text search and CSV export of search results. Test both stages with your own data: the tooling existing doesn’t prove your custom tables, attachments and access rules are covered.
Six things to put in the SOW
- The active migration scope, with every excluded record type listed.
- A records owner and retention decision for each historical record type.
- The export method, who delivers it and the last date you can access the source.
- The retained data, mapping documentation and an extraction report.
- Reconciliation, attachment, access and retrieval tests.
- Business sign-off and operational handover before the source is retired.
Frequently Asked Questions
Does a ServiceNow migration include all historical data?
Only what the SOW explicitly includes. Check the history window, table filters, custom fields, journal entries, attachments and related records. If the history sits outside the migration, get it priced and assigned.
Will ServiceNow give us a full database copy when we leave?
Check your agreement and confirm the options with ServiceNow, in writing: format, scope, timing and fees. A plan that assumes a database copy will just arrive is incomplete until someone owns it.
How long is a hosted instance suspended before retirement?
ServiceNow has previously described around 30 days, but confirm your current terms. Don’t treat it as a guaranteed recovery window.
Are ServiceNow backups an archive?
No. Backups are for recovery. An archive needs a retention period, a way to retrieve records, access controls and an owner after ServiceNow is gone.
Can a CSV export meet our retention needs?
For a narrow requirement, possibly. Test whether references, comments and attachments survive and whether users can actually find what they need in the files.
When can we safely decommission the instance?
When the migration is accepted, retained records reconcile, retrieval and access tests pass, the archive has an owner and tested backups, and the business owner has signed off on any gaps.
Related reading
- ServiceNow Decommissioning Checklist: Records, Access and Sign-Off
- ServiceNow System Archive vs Live Archive: What Happens When You Retire the Instance
- ServiceNow Instance Consolidation: What Happens to the Old Records
- Why DIY ITSM Archives Fail Audits
Planning a ServiceNow exit? Look at Cortex Archive for ServiceNow and use your own records to define the acceptance test.