How to migrate off ServiceNow without breaking operations

The technical migration is not the hard part. The hard part is that a live service desk cannot stop while you replace the thing it runs on.

That constraint shapes everything. It is why these programmes are sequenced the way they are, and why the ones that skip the first phase tend to discover the real scope halfway through the third.

Phase 1 — Analysis: find out what is actually in use

Every ServiceNow estate contains substantially more than is used. Workflows built for a reorganisation that happened, forms for a business unit that was sold, integrations to systems that were decommissioned.

The analysis phase establishes the real picture:

• Which workflows carry volume. Not which exist — which processed a record in the last ninety days.
• Which integrations are live. Every inbound and outbound connection, with an owner and a purpose.
• Which customisations encode business logic that exists nowhere else and must be reproduced.
• Which data must move, which must be archived, and which can be left behind.
• Who actually uses the platform, by role and by frequency.

This phase routinely cuts the assumed scope substantially. That reduction is the single largest cost saving available in the whole programme, and it is only available at the start.

It also produces the thing the business case needs: a defensible statement of what the replacement has to do, rather than an assumption that it must do everything the old platform did.

Phase 2 — Development: build the target, narrow first

Build the processes that carry volume, properly, before building anything else.

The temptation is to reproduce the old platform feature for feature. Resist it: you are carrying forward a decade of accumulated compromise, much of which existed to work around constraints that no longer apply.

A useful discipline is to require a named owner to justify each carried-forward customisation against current business need. Anything without an owner does not get built. This is uncomfortable and it is where the savings are.

Phase 3 — Migration: processes and open records, not history

Migrate:

• Configuration and reference data — the CMDB, service catalogue, assignment groups, users.
• Open records — active incidents, requests, changes, problems.
• Recently closed records, for a defined window, so that day-to-day lookups work.

Archive rather than migrate:

• Historic closed records beyond the window. Export them to a read-only archive that satisfies audit and retention needs.

Full history migration is one of the most reliable ways to add cost and risk to this kind of programme for value that almost nobody uses. Ask how often anyone opens a four-year-old incident. The answer is usually "for audit", and an export satisfies audit.

Phase 4 — Go-live: parallel running with a hard cut-over

Run both platforms for a defined period, with one rule: new records are created only in the new platform from the cut-over date. Existing open records finish where they started, or get migrated in a controlled batch.

Without that rule, parallel running does not end. Teams keep using what they know, the new platform never reaches critical mass, and six months later you are paying for both.

Communicate the cut-over date well in advance, hold it, and make sure the service desk leadership owns it rather than the project.

Phase 5 — Hypercare: where adoption is decided

For four to eight weeks after go-live, run elevated support: daily triage, a named response team, a fast path from "this is broken" to a fix, and visible tracking of what is being resolved.

This phase is regularly cut when the programme is running late, and it is the worst possible economy. Users form their permanent opinion of a platform in the first month. An excellent migration with poor hypercare is remembered as a failed migration.

Where these programmes fail

Four of those five are decided in the first phase. That is why analysis is not a preliminary — it is the phase that determines whether the rest is realistic.

Getting the sequence right

None of this is exotic. It is the same discipline any well-run transformation needs: know what you have, decide what you are actually replacing, prove it on real work, and support people properly through the change.

Where organisations get into trouble is treating a platform replacement as a procurement decision followed by an implementation, rather than as a transformation with a procurement decision inside it.

We run this sequence as a service — ServiceNow replacement sets out each phase and what you get from it. If your driver for leaving is jurisdiction rather than cost, start with why organisations leave ServiceNow to make sure you are solving the right problem.