Legacy system migration: how to move without a big-bang cutover

Why a big-bang cutover is riskier than it looks

A big-bang migration replaces the old system with the new one in a single event, usually over a weekend. It's appealing because it looks simpler on a project plan - one date, one go-live, done. In practice it means every risk in the project lands on the same day, with no real way to test the outcome under full production load until it's already live.

If something is wrong - a data field mapped incorrectly, a workflow that doesn't match how staff actually work, performance that only shows up at real volume - you find out on Monday morning with customers waiting and no old system to fall back on.

The strangler pattern: migrating slice by slice

The alternative, often called the strangler pattern, is to build the new system alongside the old one and move functionality across gradually - one module, one process, or one group of users at a time - until the old system has nothing left to do and can be switched off.

• Pick a genuinely low-risk slice first - a report, a single workflow, a small team - to prove the approach before anything critical moves.
• Route traffic or users to the new system slice by slice, rather than switching everyone at once.
• Keep the old system doing everything else until each slice is confirmed working.
• Only decommission the old system once nothing depends on it anymore.

This takes longer in total than a single cutover weekend, but each individual step is small, reversible, and low-stakes. If a slice doesn't work, you undo that slice - you don't undo the whole migration.

Data migration and reconciliation

Moving the software is usually the easier half of a legacy system migration. Moving the data correctly, and proving it moved correctly, is where most of the real risk sits - particularly with older systems where the data itself has accumulated years of inconsistencies.

1. 01Audit the source data first - duplicates, missing fields, inconsistent formats, and undocumented exceptions all need identifying before anything is moved.
2. 02Define the mapping explicitly - which field goes where, and what happens to anything that doesn't have an obvious new home.
3. 03Migrate in a test environment first and compare record counts and key totals against the source system.
4. 04Reconcile continuously during parallel running, not just once at the end - a mismatch caught on day one is a fix; the same mismatch caught after three months is a much bigger problem.

Reconciliation is the discipline of proving, with evidence, that the new system's data matches the old one - record counts, financial totals, key business figures - rather than assuming a migration script worked because it ran without errors.

Running old and new in parallel

Parallel running means operating both systems side by side for a defined period, with the old one still treated as the source of truth until the new one has been proven under real conditions. It costs more short-term - staff effort, sometimes duplicate licensing - but it buys certainty that a big-bang switch can't.

In practice this is usually scoped tightly: a defined period, defined checks (do the totals match, do the reports agree, does every user's workflow actually work), and a clear decision point at the end rather than an open-ended overlap that drags on indefinitely.

Always keep a way back

A rollback plan is what turns a risky migration into a manageable one. It means knowing, before you move anything, exactly how you'd revert to the old system if a slice doesn't work - not figuring it out under pressure once something has already gone wrong.

If you're at the stage of recognising the system needs to move at all, it's worth first reading how to spot when a legacy system becomes a risk, and if the driver is a support deadline specifically, our guide to end-of-life software covers how much runway that typically leaves you.

This staged, reconciled approach is how we run every legacy software modernisation project - because the risk in these migrations is almost always in the sequencing and the data, not the new code itself. The NCSC's guidance on migrating legacy IT covers the security side of the same argument in more detail.

If you're weighing up whether a phased migration makes sense for your specific system, get in touch and we'll talk through a sequencing plan before any commitment is made.