Consolidation and migration
Two platforms, one date, no room to be wrong
Consolidating ServiceNow instances after a merger, or moving off a legacy system that is being switched off. We do the profiling first, get the mapping signed off, rehearse the cutover, and reconcile record by record.
Where this usually starts
You did not choose to have two of these
Platform consolidation is almost never the project someone set out to do. It arrives attached to something else: an acquisition, a merger, a vendor sunset, a licence that is not being renewed. The date comes from that other thing, which is why it does not move.
Two ServiceNow instances, one company
Both sides have years of customization. Sys IDs collide, custom tables are rarely one to one, and reference fields point at records that may not exist on the destination. Neither instance can go quiet while you sort it out.
Legacy systems being switched off
The end date is set by someone else, and the data has to arrive in ServiceNow in a shape people can actually work in. History, relationships, and attachments all have to survive the move, not just the record counts.
A cutover date that will not move
The date is set by a contract, a licence expiry, or an integration deadline. The migration has to fit the window, and it has to be rehearsed enough that you know it will.
Evidence
What this looks like when it goes right
A higher-education institution running two ServiceNow instances, both heavily customized, both carrying live ticket flows that could not be paused.
How we work
Four things, in this order
-
Profile before you plan
We catalogue every customization, reference field, and business rule on both sides before proposing a mapping. Most migration surprises are discoveries that should have happened in week one.
-
Map with sign-off
Field-level mapping documents go to the business owners who own that data, and they sign off before anything moves. This is the step that gets skipped, and it is the step that causes the arguments after cutover.
-
Rehearse the cutover
A versioned runbook with owners, blackout windows, and a rollback procedure, rehearsed against real volumes before the window rather than during it. The old system keeps running until it does not, so the load has to be repeatable rather than a single irreversible attempt.
-
Prove it, record by record
Every record gets its source and destination identifiers logged, so reconciliation is something you can audit rather than something you have to trust.
Booking Q4 2026 and Q1 2027
We are currently engaged, and we plan consolidation work well ahead of it by choice. A migration with a fixed cutover date wants its profiling and mapping done months before the window, not weeks. If your date lands in late 2026 or the first half of 2027, now is the right time to be having the conversation.
If you would rather start smaller, our sustaining engineering retainer is a rolling monthly block of hours. It is a reasonable way to get a known engineer into your platform ahead of a larger piece of work.
If the date you are working against is Cherwell's, support for it ends on 31 December 2026 and we have written the ninety-day version of this: Cherwell to ServiceNow before the deadline.
If you are pulling a business apart rather than putting two together, that is a different problem and we have written it up separately: carve-outs and divestitures on a TSA clock.
Tell us what you are consolidating and what date you are working against.