ServiceNow Instance Consolidation: What Happens to the Old Records
One of our customers, a life sciences company, went through two corporate events in quick succession. First a merger combined two companies into one. A few months later, the combined business spun off one of its divisions as a separate, privately held company.
Two companies became one. Then one became two.
Every one of those moves left ITSM history behind. The combined company was already archiving its Cherwell history with Cortex, and it added its ServiceNow history on top. When the spun-off division stood up on its own, it needed access to its share of that history too, and it became a Cortex customer as well.
Here’s the lesson. The cutover to one ServiceNow instance is the part everyone plans. The records left in the retired instance are the part that comes back to bite you, and after a merger the business may not stay in the shape you just built.
Same ticket number, two different records
Both instances started counting from the same place. INC0012345 in Company A and INC0012345 in Company B are two different incidents, probably with two different outcomes.
Keep the source instance label next to every record’s original ID and ticket number. Use it in search, in reconciliation and in anything you export for an auditor. If your team can only tell the records apart by the number, you’ll hand someone the wrong incident eventually.
Watch the fields too. Two instances can both have a field called “Category” that means completely different things. Document what each field meant in its source before you map anything into the surviving instance.
Not all history belongs in the new instance
A closed ticket can still matter. It might be linked to an open problem, a recurring fault or a customer dispute. That history should move.
Most of the rest shouldn’t. Migrating ten years of closed tickets from the retired instance adds mapping and testing work, and bloats the platform you’re trying to clean up. Use this split as the starting point:
| In the consolidation | Where it goes | Why |
|---|---|---|
| Active work and history still needed | Migrate to the surviving instance | Supports ongoing work |
| Other history approved for retention | Read-only archive | Keeps the original context retrievable |
| Attachments, approvals and linked records | Stay with the record they support | You can’t interpret the record without them |
| Post-close ownership and disposal authority | Named owner in the records plan | Someone has to be accountable after the project team leaves |
Somebody has to own the leftovers
Your legal and records teams decide who owns each retained set, how long it’s kept, whether any legal holds apply and who can approve disposal. That answer depends on the deal, so get it in writing.
Then map the old users and groups to the new organization. Test it. A new group membership should not suddenly give someone access to HR, customer or deal records from the other company.
Keep the histories separable
This is what that customer’s year teaches. The merger combined two histories. The spin-off needed part of that history carved back out for the new company.
If you blend both instances into one undifferentiated archive, a future divestiture turns into a forensic exercise. Tag every retained record with its source company and business unit on the way in. It costs almost nothing at consolidation time and saves weeks if the business splits later.
Archive the retired instance before you switch it off
Cortex Archive for ServiceNow gives you a self-hosted, read-only interface to the historical records, relationships and attachments from the retired instance. It connects to the source with read-only credentials and keeps its own configuration separately.
Include the retired instance in your acceptance testing, and make sure users can tell which company each record came from.
For the business case, compare real numbers. One-time: extraction, mapping, validation, setup. Ongoing: infrastructure, access admin, backup, support and eventual disposal over the retention period. Put that next to the cost of keeping the old instance licensed and running. Record volume alone won’t tell you which is cheaper.
Frequently Asked Questions
Does consolidation migrate all historical data into the surviving instance?
Only what’s in the agreed migration scope. Everything else needs a retention decision, an owner and a way to retrieve it.
What happens to the retired instance’s data when we switch it off?
Anything that only lives there becomes unavailable. Archive what you need to keep and test it before shutdown.
Do we inherit the acquired company’s retention obligations?
Often, but the deal’s legal and records owners decide what transfers. Get the answer by record category, then build access and disposal rules around it.
Should we just keep the old instance running?
You can. It’s still a system to license or host, secure, patch, back up and support. Compare that against a read-only archive on cost, access control and record fidelity.
How do we handle duplicate ticket numbers?
Store the source instance and original record ID with every visible ticket number. Never reconcile two datasets on the ticket number alone.
What if the business splits again later?
Tag retained records by source company and business unit when you archive them. That’s what makes a later carve-out straightforward.
When should we start archiving?
During discovery, not after cutover. Pull the history, reconcile it, test it with real users, then retire the instance once owners sign off.
Related reading
- Retire the Platform, Keep the History: Build vs Buy
- Why DIY ITSM Archives Fail Audits
- Cortex deployment requirements
- Cortex release notes
Consolidating ServiceNow instances? Look at Cortex Archive for ServiceNow and test the retired instance’s records with the people who’ll own them after close.