how do you decommission ServiceNow without losing data?

Agree what you're keeping and who owns it. Migrate what the new platform needs. Pull the rest of the required history and attachments into an archive. Reconcile it against the source, test it with real users and restricted users, and get the business owner's sign-off. Only then follow ServiceNow's retirement process.

ServiceNow Decommissioning Checklist: Records, Access and Sign-Off

10 Nov 2026 · By Ruann van der Merwe, Strategic Advisor — Synapse Software
Strategic Advisor at Synapse Software

Before anyone signs off on a ServiceNow shutdown, ask for one document: the acceptance report for the records you’re keeping. It should show what was pulled out, what failed, who tested access and who runs the archive from here.

If nobody can produce that report, you’re not ready to switch the instance off. This checklist is how you get to it while the source is still available.

Start with what you actually have to keep

Every business has its own requirements and policies, so there’s no universal list. Go through each record category and write down why you’re keeping it, for how long, whether it’s under legal hold and who can authorize disposal.

Include what’s needed to make sense of each record: the fields, the related records and the attachments. An incident without its journal history or a change without its approvals isn’t much use to an auditor.

Records and legal decide the scope. The technical team’s job is to prove it was delivered.

Five steps before shutdown

Do all five while you can still compare the archive against the live instance.

Inventory the instance. Tables, record counts, attachment counts and sizes, custom data and the retention decision for each. List exclusions explicitly, so the extraction report reconciles against the same scope.
Decide what the new platform needs. Some history supports live work, like open problems, recurring incidents or contract disputes. Move that. Everything else gets a retention or disposal decision.
Pull and reconcile the retained data. Document filters, extraction times, transformations, failed records, attachments and relationships. Fix or formally accept every gap before the source goes away.
Test retrieval and access. Have real users search, open and export records without touching ServiceNow. Make sure restricted users can’t see records or attachments they shouldn’t. Test that you can recover the archive itself.
Approve and retire. Confirm the last access date with ServiceNow, name the archive’s operating owner and get the accountable owner’s sign-off. File the acceptance report, exceptions and recovery contacts with the shutdown record.

Here’s who owns each sign-off:

Before you decommission	Owner and evidence required
Approve the record inventory and retention	Records owner: signed scope, periods, holds and disposal decisions
Accept the live migration	Service owner: destination accepted, including any history needed for live work
Accept the retained dataset	Data lead: reconciled counts, attachment results, mappings, resolved or accepted failures
Pass retrieval, access and recovery tests	Business and security owners: user test results, denied-access checks, recovery evidence
Authorize source shutdown	Accountable owner: acceptance references, approved exceptions, operating handover, confirmed retirement terms

What the acceptance report should show

Expected, pulled and failed record counts, all against the same scope and cutoff date. Attachment reconciliation. Any field or relationship discrepancies. User retrieval results, access failures and the recovery test.

Two things to watch for. If the report shows a completion percentage, ask what it’s a percentage of and what was excluded. And a handful of sample records that open correctly proves those records work. It doesn’t prove the extraction is complete.

Every exception gets an owner and a decision.

Where Cortex Archive for ServiceNow fits in

Cortex Archive for ServiceNow gives you a self-hosted, read-only interface to your historical records, relationships and attachments. It connects to the source data with read-only credentials. The current Cortex release notes cover the ServiceNow Sync Utility for pulling the data, plus full-text search and CSV export of search results.

Test what Cortex actually delivers against the scope in your acceptance report, not against a demo.

Then hand over properly. The operations team needs the retained-data inventory, configuration, support ownership, backup and recovery instructions and the disposal schedule. Have them run a retrieval test themselves before the migration team leaves, and file the results with the shutdown approval.

Frequently Asked Questions

What do I need to preserve before decommissioning ServiceNow?

Whatever your records, legal, security and business owners approve, plus the context needed to use it. That often means incidents, changes, requests, problems, journal history, approvals, related records and attachments.

Can I just export everything to files before shutdown?

For a narrow scope, maybe. Flat files usually lose relationships, display values, history or attachments. If people need to search and read records in context, use a structured read-only archive.

What proves the archive is ready?

The acceptance report: reconciled record and attachment counts, tested record context, allowed and denied access, retrieval results and a recovery test, signed off by the accountable owner. A product demo doesn’t prove anything about your data.

Do we still have records obligations after the instance is gone?

Usually, yes. It depends on the record, legal holds, contracts, policy, regulation and jurisdiction. Confirm the retained scope with legal and records before shutdown.

How do we calculate decommissioning savings?

Compare total cost over the retention period. One-time: extraction, setup and validation. Ongoing: infrastructure, licenses, access admin, backup, support and disposal. Put that against keeping the old instance running. Use your real contract and operating costs, not an assumed percentage.

Does Cortex support ServiceNow decommissions?

Yes, through a self-hosted, read-only archive. What it covers depends on the data you pull and how it’s configured, so test custom tables, relationships, attachments, access and performance before you rely on it.

Planning a ServiceNow shutdown? Look at Cortex Archive for ServiceNow and use this checklist to define what sign-off actually requires.