The riskiest sentence in enterprise IT is we will rewrite it from scratch. The graveyard of big-bang rewrites is full of projects that were eighty per cent done for three years while the business froze around them.
The alternative is not to keep the legacy system. It is to stop treating replacement as an event.
Why the rewrite fails, specifically
Rewrites do not fail because the new code is bad. They fail because of three structural properties that are present from day one.
- The target keeps moving. The business does not stop changing during a three-year rebuild. Every change has to be made twice, in the old system to keep trading and in the new one to keep parity, and the gap between them widens.
- Nothing ships until everything ships. Value arrives only at cutover, so the project has no way to prove itself and no way to be partially right. A steering committee cannot course-correct against a system nobody has used.
- The specification is the old system, and nobody has read it. Behaviour accumulated over fifteen years lives in code, not documents. The rewrite team builds what the business describes; the business describes what it believes it does.
The public examples are instructive because the failure mode is always the same shape. When TSB Bank moved 5.2 million customer accounts in a single cutover event in April 2018, the widely reported consequences — customers locked out for weeks, and a cost the bank put in the hundreds of millions — did not come from a team that could not write software. They came from a migration with no incremental path and no way back.
Grow around, not replace
The strangler pattern inverts the rewrite. The new platform starts as a thin layer around the legacy core, absorbing one capability at a time — reporting first, then a workflow, then a module — each behind an interface the rest of the estate already understands. The legacy system does not get switched off. It gets hollowed out until switching it off is an anticlimax.
The sequencing matters more than the technology:
- Reporting first. Reads are safe. Moving reporting to the new platform proves the data model, delivers visible value in weeks, and touches nothing that can corrupt a ledger.
- Then a bounded workflow with a clear input and output — something whose correctness can be checked without understanding the whole system.
- Then a module that owns its data. This is the first genuinely hard step, because it means deciding where the record of truth now lives.
- Then the core, by which point most of the surface area has already moved and the remaining risk is understood rather than assumed.
The facade is the whole trick
Every capability that moves goes behind an interface that hides which system is serving it. Consumers do not know, and must not need to know, whether a request is answered by the legacy core or the new platform. That indirection is what makes each step reversible — and reversibility is the property that turns a bet into a sequence of decisions.
Parallel-run or it did not happen
Before any capability cuts over, both systems run it simultaneously and the outputs are reconciled — every invoice, every balance, every edge case the old system handled in ways nobody documented. We have run month-end close on both systems during transitions. That is not caution theatre. It is how the undocumented behaviour is found before it finds you.
What a parallel run actually surfaces, in our experience, is rarely a calculation error. It is the rules nobody could state: the customer category that gets a different rounding treatment, the tax logic that changed in 2019 and was implemented as an exception rather than a rule, the branch whose data has always been loaded a day late.
Two disciplines make the parallel run worth its cost:
- Reconcile automatically, not by sampling. A daily diff of every record beats a monthly review of twenty.
- Write the explanation down. Every discrepancy resolved is a piece of undocumented behaviour recovered. That log becomes the specification the rewrite never had.
Knowledge rescue
The scariest legacy risk is not the code. It is the retirements. The people who know why the system does the strange thing on the fourth of April are leaving, and their knowledge is not written anywhere.
Modernisation is the last structured opportunity to capture it, and it only happens if it is treated as a deliverable rather than a side effect. In practice that means the discovery phase interviews the operators rather than only the managers, every unexplained behaviour becomes a test rather than a note, and the reasoning is recorded next to the rule so the next team inherits the why and not just the what.
What this costs, and what it buys
The honest trade-off: a strangler migration runs longer in calendar time than a rewrite is planned to, and it requires maintaining two systems and the integration between them for the duration. That is a real cost, and anyone who tells you otherwise is selling.
What it buys is that the project can be stopped at any point and still be worth something. Each capability moved is value delivered and risk retired. A rewrite cancelled at eighty per cent is worth nothing at all.
When a rewrite is the right answer
Criteria to apply to your own situation:
- The system is small enough that a full rebuild is measured in months rather than years.
- The platform is genuinely at end of life — no security patches, no hardware, no one who can compile it.
- The business process is being deliberately replaced too, so parity with the old behaviour is not the goal.
Where those hold, the incremental path adds cost for risk that is not there. Where they do not, the sequence above is the one that finishes.