When to modernize a legacy system, and what it costs to get it wrong

01The test: what is it actually costing you

Not whether the code is unpleasant - whether it is imposing a measurable cost. Slower delivery, more incidents, hiring difficulty, a compliance requirement it cannot meet, or a roadmap item it structurally cannot support. If you cannot name one of those specifically, the system is not the problem you think it is.

Code that is ugly but stable and rarely modified costs nothing. Rewriting it converts a working system into a new one with fresh bugs, for no return. The systems worth modernising are the ones that change often and are painful to change - that intersection, not aesthetics, is the signal.

02Why full rewrites overrun

A rewrite has to rediscover requirements that nobody wrote down - the edge cases, the regulatory quirks, the customer-specific behaviour that someone added in 2019 for a reason that is no longer recorded. That discovery happens in production, under pressure, after the budget was set.

Meanwhile feature development stalls, the business runs two systems in parallel for far longer than planned, and the team that knew the old system starts leaving because maintaining it has become a dead-end role. The pattern is consistent enough to plan around rather than hope to avoid.

03The incremental approach that works

Put a facade in front of the old system, then move functionality behind it piece by piece. Each piece ships value on its own, the old path stays available until the new one is proven under real traffic, and you can stop at any point with something better than you started with.

It is slower to start and dramatically more likely to finish. It also fails safely - if the programme loses funding halfway, you have a partially modernized system that works, rather than an abandoned rewrite and a legacy system nobody maintained for eighteen months.

• Facade first, then move functionality behind it.
• Keep the old path live until the new one is proven.
• Each increment ships value independently.
• Losing funding halfway leaves you better off, not stranded.

04What to do before any modernization

Get tests around the current behaviour, particularly the parts you intend to change. Without them you cannot tell whether the new implementation matches the old one, and 'matches the old one' is the actual requirement - including the behaviour everyone considers a bug but some customer depends on.

Then document what the system does from observation rather than from the documentation, which will be wrong. This work is unglamorous and it is what separates modernization programmes that land from ones that discover requirements in production.

05The cost of doing nothing

Deferring is a legitimate choice, but price it honestly. An unsupported runtime version means security patches stop, which eventually becomes a compliance problem rather than a technical preference. Hiring gets harder and more expensive as the stack ages. And delivery slows gradually enough that nobody notices until a competitor ships faster.

The point is not that you must modernize. It is that 'not yet' should be a decision with a cost attached and a review date, rather than an absence of one.