1. Map the seams
Identify natural boundaries in the legacy system — modules, bounded contexts, or simply the least-coupled screens — where a facade can intercept traffic without touching everything else.
Guides
Legacy system migration: a phased approach
Replacing a system a business depends on every day is a data integrity problem first and a software project second. This guide sets out the strangler-fig approach we use to move off legacy platforms without a single high-risk cutover weekend, and the verification work that makes it defensible.
It complements our legacy modernisation service and our discovery and scoping sprint, which is where a migration's phasing and cost bands are actually established.
Approach
The strangler-fig approach
Rather than replacing a legacy system in one event, a facade or routing layer sits in front of both the old and new systems and gradually redirects capability from one to the other, slice by slice, until the legacy system has nothing left to do. The name comes from the strangler fig plant, which grows around a host tree until the host is no longer needed.
2. Insert the facade
A routing layer sits in front of both systems and directs each request to whichever side currently owns that capability. It is the single piece of new infrastructure every subsequent slice depends on, so it is built and hardened first.
3. Order the slices by risk and value
Start with a slice that is well-understood, lower risk, and still visibly valuable — proving the pattern works builds confidence for the harder slices later. Save the most tightly coupled, highest-risk capability for when the team and the facade are both proven.
4. Build, verify, redirect, retire
Each slice is built against production-shaped data, verified through reconciliation, redirected via the facade, run in parallel, and only then is the legacy code path for that slice retired.
5. Repeat until nothing legacy remains
The facade itself is the last thing removed, once every capability has moved and the legacy system has no remaining callers.
The ordering of slices matters more than most teams expect. Migrating the highest-risk, most tightly coupled capability first, because it is the "most important", tends to produce the worst outcomes: the team has no proven facade pattern, no track record of reconciliation working correctly, and no fallback plan if the slice fails. Order by a combination of risk, coupling and value, not by organisational priority alone.
Data integrity
Verifying every record, not sampling it
Sampling is not sufficient for a migration a business will run on. Every migrated slice needs full-population verification with an audit trail a sceptical stakeholder can inspect after the fact.
Reconciliation counts
Row counts and aggregate totals (sums, counts by category) compared between source and target after every batch load, run automatically and alerting on any mismatch.
Checksums
Hash comparisons on records that should be byte-for-byte identical after transformation, catching silent corruption that count-based checks miss.
Field-level diffing
A field-by-field comparison tool that surfaces every discrepancy between source and target records, not just whether a record exists on both sides.
Exception queues
Records that fail reconciliation are routed to a queue for manual review rather than silently dropped or silently overwritten, with an owner assigned to clear it before cutover.
Sign-off gates
A named business owner formally accepts each slice's reconciliation report before it is allowed to move from parallel running to being the system of record.
Parallel running
Dual-write versus shadow-read
Dual-write sends every write to both the legacy and new system simultaneously, so both stay current and either can be treated as the system of record at any point. It is the safer option where writes are infrequent enough that the added latency and complexity are acceptable, and it gives the cleanest rollback path because the legacy system never falls behind.
Shadow-read keeps the legacy system as the sole system of record for writes, but replays the same reads against the new system in the background and compares the results, without exposing shadow results to users. It is lower risk to implement because it never touches the legacy system's write path, but it verifies read behaviour only, so a separate batch reconciliation is still needed to prove the write path is correct.
Run parallel for long enough to see the full range of business activity a system encounters — typically a full month-end, quarter-end and any seasonal peak specific to the business, rather than a fixed number of calendar days. Divergences found during this period go into the same exception queue as data migration errors, with a named owner and a decision on whether the divergence is a bug or a deliberate behaviour change.
Cutover
Planning the cutover
Freeze window
A defined period, communicated well in advance, during which non-essential changes to the legacy system are disallowed so the final reconciliation is comparing a stable target.
Runbook
A step-by-step document naming who executes each step, in what order, with the exact commands or actions and the expected result at each stage — written so someone who did not build the system could follow it under pressure.
Communications
Advance notice to every affected team, a single channel for cutover-day status updates, and a named point of contact for anyone who spots something wrong.
Go/no-go criteria
An explicit checklist agreed before the day — reconciliation within tolerance, exception queue cleared or explicitly accepted, rollback tested — that a named decision-maker signs off against, rather than a judgement call made in the moment.
Rollback
Rollback procedures and the point of no return
A rollback procedure is a tested, timed sequence for reverting to the legacy system as the system of record, not a hope that the old system is "still there". Test it before cutover, not during an incident.
Rollback becomes impossible, or prohibitively expensive, once writes have occurred against the new system that have no equivalent representation in the legacy schema — for example, a workflow state the old system cannot express — or once downstream systems have started consuming data from the new system in a way that cannot be unwound. Identify this point explicitly for every slice before it goes live, and treat crossing it as a one-way decision that requires the same sign-off as the cutover itself.
Timelines and cost
Realistic timelines and cost bands
| System scope | Indicative duration | Indicative cost band |
|---|---|---|
| Single-purpose system, limited integrations | 4–7 months | £180,000–£350,000 |
| Core operational system, moderate integration surface | 9–14 months | £400,000–£750,000 |
| Enterprise-wide platform, heavy integration and compliance load | 14–24 months | £800,000 and above |
These are indicative bands, not quotes. A discovery sprint produces a phased estimate specific to your systems and data quality, with the tightest confidence on the first phase and honestly wider ranges on the phases that depend on what discovery finds.
Questions
Frequently asked
How long does a legacy system migration realistically take?
For a core operational system with meaningful integration surface, expect nine to eighteen months from first slice to full decommission of the old system. Anyone quoting a fixed date before discovery has not accounted for the data quality issues you will find in month two.
Can we migrate everything in one cutover instead of phasing it?
You can, and some genuinely small systems justify it. For anything a business depends on daily, a single cutover concentrates all the risk into one weekend and gives you no early warning if the new system behaves differently under real load. We recommend it only when the strangler-fig approach is not technically possible.
What is the single most common reason a migration goes wrong?
Underestimating data quality in the source system. Duplicate records, inconsistent reference data and undocumented manual workarounds are discovered during reconciliation, not before, however much analysis precedes the build.
What happens to staff who know the old system's quirks?
They are the most valuable people in the project. The workarounds they have learned are often undocumented business rules the new system needs to replicate or deliberately correct — deliberately, with sign-off, not by accident.
Migrating off a legacy system?
Tell us what the current system does and which parts of it worry you. We will map the seams before we talk about a plan.
Talk to us