Almost every business with an ageing core system eventually has the same conversation. The current software is awkward. The people who built it have moved on. Every change feels risky. Someone proposes the clean solution: stop patching it, build a fresh replacement properly, and switch over when it is ready. It sounds responsible. It is the single most reliable way to spend a large budget and have nothing to show for it.
This is not a fringe opinion. It is the settled view of the people who have spent their careers replacing legacy systems. The pattern is so consistent that one of the field’s most cited voices reduced it to a warning that gets repeated at every conference.
If you do a big-bang rewrite, the only thing you’re guaranteed is a big bang.
Why rewrites go down in flames
The core reason is uncomfortable: you do not actually know what your old system does. Over years, an application accumulates behaviour — a rounding rule for one customer, a quiet exception for a particular product, a validation that exists because of an incident in 2018 that nobody remembers. Most of it is undocumented. Some of it is wrong but depended upon. A rewrite asks a team to reproduce all of that from a system they can only read by guessing, while the original keeps changing underneath them.
The trap has a name. Teams set out to achieve "feature parity" — the new system must do everything the old one did — and discover that the target is both enormous and invisible. You are committing to rebuild behaviours you cannot see, to a standard of "the same", for a system that real users will compare unforgivingly against the one they already know.
Feature parity… is a pattern we see a lot when you’re starting bottom-up and it’s a technology-led project, but it is a trap.
There is a second, quieter cost. A multi-year rewrite trains an organisation to release rarely, in enormous increments. When it is finally done — if it is finished — the team has lost the muscle for shipping small, frequent, low-risk changes, which is precisely the capability that would have prevented the system becoming legacy in the first place.
You’re training people to release software infrequently in very big increments… it’s almost impossible to then transition from releasing every year to releasing every two weeks.
The estimate is worse than you think
Rewrites are also chronically under-estimated, and not by a little. The size of an old system is hidden in its undocumented behaviour, so the part you cannot see is exactly the part you forget to cost. Even practitioners who deliver successful, accelerated modernisations report the same pattern: the work was several times larger than anyone planned, and any speed gained on the building was eaten by the sheer scale that only became visible once they started.
The path that looks slower and finishes faster
The alternative is not to live with the old system forever. It is to change it in place, in small steps, while it stays live and keeps earning. Instead of building a parallel replacement and switching over once, you move one capability at a time out of the old system and into the new, verifying each move in production before taking the next. The old and new run side by side throughout. At every point you have something that works, and at every point you can stop, or reverse, without losing the lot.
This is the difference between a single, enormous, all-or-nothing bet and a series of small, reversible ones. Each step delivers a little value, proves a little of the unknown behaviour, and reduces the risk of the next. It looks slower because there is no dramatic "go-live" — but a programme that ships value every few weeks and never risks the whole business is the one that actually reaches the end. The specific techniques for doing this safely — strangler-fig, branch-by-abstraction, parallel running and feature flags — have their own piece in this series.
It is worth saying that a clean rebuild is occasionally the right answer — a low-value system, small enough to fully understand, where an off-the-shelf product now does the job better. The point is not that rewrites are never correct. It is that "rewrite" should be the conclusion of a value-and-risk argument, not the opening instinct.
If you are weighing a rewrite right now, the most valuable thing you can do first is map honestly which parts of the system carry real value and which would be genuinely dangerous to rebuild. Our free Software Health Check is built to produce exactly that picture before you commit a budget — at /application-modernisation/free-assessment.