Every legacy system invites the same fantasy: tear it down and rebuild it clean. It's almost always a mistake. Big-bang rewrites are where budgets die — and the new system usually reinvents bugs the old one had already solved, years later and at several times the cost. The instinct is understandable: the old code is ugly, no one fully understands it, and a green field feels liberating. But the ugliness is often load-bearing.
Why rewrites fail
- The old system encodes years of undocumented edge cases — the weird tax rule, the customer-specific discount, the workaround for a partner's broken API — that a rewrite quietly drops, then rediscovers as production incidents.
- You ship nothing new for months, sometimes years, while the rewrite catches up to where you already were. The business doesn't stop needing features in the meantime.
- Two systems in parallel doubles maintenance, not halves it. Every bug fix and every new requirement now has to land in two places.
Why this matters
Modernisation is rarely a technical problem in isolation — it's a business-continuity problem. The legacy system is, right now, making money and serving customers. A rewrite asks the business to bet that fragile, low-visibility process against a multi-month project that delivers no value until the very end. That's a bad trade, and it's why so many rewrites are quietly abandoned halfway through, leaving the organisation maintaining two half-finished systems instead of one working one.
The incremental path
- 1.Strangle, don't replace. Put a façade in front of the legacy system; route functionality to new services one slice at a time, until the old core has nothing left to do.
- 2.Start at the seams — modernise what changes or hurts most first, so the early work pays for itself.
- 3.Keep the data where it is, at first. Decoupling the data store is its own project; don't take it on at the same time as everything else.
- 4.Ship continuously — every slice delivers value and de-risks the next, and at every point you have a working system you could stop on.
A good modernisation is invisible to users and reversible at every step. A rewrite is a held breath until launch day.
A concrete example
A retailer with a 15-year-old monolith wants to modernise checkout. Instead of rebuilding the platform, they put a routing layer in front of it and rebuild only the payment flow as a new service. Traffic shifts gradually, the old path stays as an instant fallback, and the team learns the real-world quirks before touching anything else. Six weeks in, customers have a faster checkout and the business has taken on near-zero risk — the opposite of a two-year rewrite that ships nothing until it's done.
What this means for your team
Frame modernisation as a sequence of small, shippable, reversible bets, each justified on its own merits. Modern AI tooling genuinely accelerates the grind — understanding old code, mapping dependencies, drafting tests to lock in existing behaviour before you change it — but it accelerates a disciplined process; it doesn't replace one. If you're staring down a system everyone's afraid to touch, we've done this before and can help you map the seams.