The Costs Nobody Puts on the Invoice
Every company with software older than three years has legacy code. That is normal. What is not normal is how systematically the true costs of that code are underestimated.
The obvious costs – longer development times, more bugs, painful onboarding – are well known. But the really expensive consequences of legacy code are the ones that never appear in a Jira ticket.
The Visible Costs
Let us start with what is measurable:
Development speed: Features that take two days in a modern codebase take two weeks in legacy systems. Not because the developers are slower, but because every change has side effects that must be understood and safeguarded against.
Bug rate: Legacy code typically has a 3–5x higher bug rate than modern code. Not because it was badly written, but because it has grown over years without the architecture growing with it.
Testability: Old code was often written without tests. Adding tests retroactively is possible but expensive – and without tests, every change is a shot in the dark.
Documentation: The older the code, the more likely it is that the people who wrote it have left the company. The knowledge lives in the code – and sometimes in no one at all.
The Invisible Costs
This is where it gets expensive:
Talent attrition: Good developers want to work with modern technologies. A team that spends 80% of its time keeping legacy systems running loses its best people. And their replacements cost more and need months to get up to speed on the old code.
Opportunity cost: Every hour a developer spends on legacy maintenance is an hour not invested in new features, new products, or new markets. This is the most expensive line on the invoice – and it never appears explicitly.
Security risks: Old frameworks and libraries eventually stop receiving security updates. The vulnerabilities remain open because an update would break half the application. This is not a hypothetical risk – it is the default state of legacy systems.
Integration capability: Modern APIs, webhooks, AI services – legacy systems often cannot connect to current technologies, or can only do so with massive effort. That means the business misses opportunities that competitors with modern systems can seize.
The Psychological Trap
Legacy code survives not despite its costs, but because of a psychological trap: the sunk-cost fallacy.
"We have invested ten years in this system" is not an argument for investing another ten. But that is exactly how most organisations think. Past investment is used as justification for future spending – even though it is irrelevant.
On top of that comes the fear of the big rewrite. "If we rewrite the system, it will take two years and cost a million." That may be true – but the alternative is spending an additional £300,000 every year on maintenance while still getting slower.
What the Maths Actually Shows
A mid-sized company with a legacy system typically looks like this:
Direct maintenance costs: 2–3 developers primarily maintaining the old system. £200,000–400,000 per year.
Productivity loss: Features take 3x longer. For a team of 8 developers, that equates to the output loss of 5 developers. Hard to quantify, but real.
Talent costs: Higher salaries needed to attract developers to legacy work. Higher turnover. Longer onboarding. £50,000–100,000 in additional costs per year.
Missed opportunities: Not quantifiable, but often the largest item. The feature that was not built. The market that was not entered. The integration that was not possible.
The Pragmatic Way Out
A big-bang rewrite is rarely the answer. It is risky, expensive, and fails more often than it succeeds. An incremental approach works instead:
Strangler fig pattern: New features are built in a modern architecture. Old code is replaced piece by piece with new implementations. The system remains functional throughout.
Introduce an API layer: A clean API between the legacy system and the outside world creates an abstraction that enables gradual modernisation without touching everything at once.
Critical paths first: Not everything needs modernising. The admin panel used by three employees can stay legacy. The customer-facing checkout processing thousands of transactions daily cannot.
AI as an accelerator: Tools like Claude Code can analyse, document, and incrementally refactor legacy code. What once required months of manual work can now be accomplished significantly faster.
What This Means for Decision-Makers
Legacy code is not a technical decision – it is a business one. The question is not "should we keep the old code?" but "what does it cost us to keep it – and what would we do with the freed resources instead?"
At nh labs, we help businesses make exactly this calculation. The result is often surprising: modernisation pays for itself faster than expected – not because it is cheap, but because the cost of the status quo is higher than assumed.
Conclusion
Legacy code is like a mortgage with a rising interest rate. The longer you wait, the more expensive it gets. The businesses that invest in incremental modernisation today will be faster, more secure, and more attractive to talent in two years. Those that wait will find that their technical debt accrues not just interest, but compound interest.