Getting off a legacy system without a big-bang rewrite
The rewrite that ships everything at once is the most expensive way to modernise and the most likely to fail. The incremental alternative is slower to describe and faster to finish.
Every legacy system reaches the same meeting. It is slow, the person who understood it has left, adding anything takes a fortnight, and someone says the word "rewrite."
What usually follows is an eighteen-month project to rebuild everything and switch over one weekend. It is the most expensive way to modernise and, by a distance, the most likely to fail — not because the engineering is hard, but because of what happens around it.
Why the big bang fails so reliably
The old system does not stop. While the rewrite is under way, the business still needs changes. Now every change has to be made twice, in two codebases, by a team already stretched. The second implementation is always the one that gets rushed.
The requirements are in the code. A system that has run for a decade has absorbed a decade of decisions. Not the ones in the documentation — the ones in a conditional somebody added on a Tuesday in 2019 because a particular customer needed something. Nobody remembers, and you will find them in production.
Value arrives only at the end. For the entire project there is nothing to show. That makes it politically fragile: the first budget review, the first reorganisation, the first quarter where something else is urgent, and the whole thing is at risk. Half a rewrite is worth nothing at all.
The switch is a cliff. Everything that was wrong reveals itself at once, on the busiest weekend somebody could schedule, with no way back that anyone has actually rehearsed.
The alternative: strangle it
The pattern that works is old and well-named. You put a layer in front of the legacy system, and you move functionality behind it a piece at a time. Each piece, once moved, is real: in production, serving traffic, delivering value. The old system shrinks until what remains is small enough to switch off without ceremony.
It goes roughly like this.
Put a seam in front. A routing layer — a reverse proxy, an API gateway, sometimes just a thin service — that sits between users and the legacy system. On day one it forwards everything through unchanged. Nothing has moved yet, and nothing has broken. This is the whole foundation of the approach: you now have somewhere to redirect from.
Pick the first slice carefully. The first one matters more than the rest, because it proves the approach and it teaches you where the mines are. Look for something that is:
- Self-contained, with few dependencies on the rest of the system
- Read-heavy rather than write-heavy, so mistakes are recoverable
- Genuinely painful today, so people notice it improve
- Small enough to finish in weeks, not quarters
Resist starting with the hardest part on the theory that it de-risks the project. It does the opposite: it puts the most complex work in front of a team that has not yet learned the system's habits.
Move it, route it, keep the old path warm. Build the replacement, run it in parallel, compare the outputs on real traffic before you send any users to it. Then move traffic gradually — a percentage, an internal team, one customer segment — with a rollback that is a config change, not a deployment.
Repeat, and do not skip the deletion. The step teams miss is removing the old code once a slice is fully migrated. Skip it and you now have two systems forever, which is worse than the one you started with. A slice is not done until its predecessor is gone.
Data is the hard part
Everything above is manageable. Data is where these projects actually get difficult, because two systems that both think they own a record will diverge, and the divergence is silent.
Some things that help:
- Pick one owner per record type, explicitly. Not "mostly the new system." One. Everything else reads.
- Sync in one direction if you possibly can. Bidirectional sync means conflict resolution, and conflict resolution means someone has to decide what happens when both sides changed the same field. That decision is a policy question, not a technical one, and it is best avoided.
- Reconcile continuously and loudly. A job that compares both sides and shouts about differences. You want to hear about drift on the day it starts, not in a customer complaint a month later.
- Keep the old data reachable. Not necessarily migrated — reachable. There is usually a long tail of historical records that nobody needs in the new system but somebody will need to look at once a year.
What it costs
Incremental migration is not cheaper in engineer-hours than a rewrite. Running two systems in parallel, building the seam, keeping the data honest — that is real work that a big bang does not do.
It is cheaper in the ways that end up mattering:
| Big bang | Incremental | |
|---|---|---|
| First value delivered | At the end | Weeks in |
| Cost of stopping early | Total loss | Keep what shipped |
| Rollback | A weekend | A config change |
| Business changes meanwhile | Built twice | Built once, in the new system |
| Discovery of unknowns | All at once, at the end | Gradually, while there is time |
The last row is the one that decides most projects. Every legacy system contains surprises. The only question is whether you meet them one at a time, with the budget and the calm to deal with them — or all together, on go-live weekend.
Where to start
You do not need a modernisation strategy to begin. You need one slice, chosen well, taken all the way to production and deleted from the old system. That single loop teaches you more about what the migration will really cost than any amount of upfront planning, and unlike a plan, it leaves you better off than you started even if the rest never happens.
