The Real Cost of Keeping a System You Should Have Replaced
Eleven of the US federal government's oldest IT systems cost $754 million a year to maintain. None of that figure appears on a single line labelled 'cost of not modernising' — it is scattered across budgets that make delay look free.
Every year a modernisation decision is deferred, someone presents a business case that shows keeping the old system as the cheap option. The case is usually wrong, and it is wrong in a specific, findable way: it compares this year's visible maintenance cost against next year's visible project cost, and ignores everything that does not appear on either line.
What the visible cost actually is
The US Government Accountability Office's review of the federal government's most critical legacy systems found 11 systems, 23 to 60 years old, costing $754 million a year combined to operate and maintain. Eight of the eleven ran on outdated programming languages. Four ran on unsupported hardware. Seven had known cybersecurity vulnerabilities. (GAO-25-107795)
That $754 million is the visible number — the one that appears in a budget line called "operations and maintenance." It is not the full cost, and the GAO's own framing makes that clear: the criteria for calling these systems "critical" leaned heavily on the unsupported-hardware and known-vulnerability findings, not on the maintenance spend alone.
The costs that do not appear on any single line
Reduced ability to change anything. DORA's research on engineering performance found that even elite-performing teams report spending only about 50% of their time on new work, the rest going to unplanned work, rework, defects and support. (DORA) Ageing, poorly documented systems push that ratio further toward maintenance, and the effect compounds because every unaddressed issue increases the unplanned-work share for the issue after it.
Concentration risk in the people who understand it. A system with declining institutional knowledge is not measured in any accounting line, but it is measured the day the one person who understands it leaves and every change afterward takes measurably longer and carries measurably more risk.
Security exposure priced as a probability, not a certainty. IBM's Cost of a Data Breach research puts the global average cost of a breach at $4.99 million. An unsupported system with a known vulnerability is not a hypothetical exposure — the GAO explicitly found seven of eleven critical legacy systems already carry known vulnerabilities. The cost of that risk does not appear in the maintenance budget. It appears, suddenly and much larger, the day it is exploited. (IBM)
Technical debt as a standing tax on everything new. McKinsey's 2020 survey of 50 CIOs at financial services and technology firms above $1 billion in revenue found technical debt estimated at 20–40% of the entire technology estate's value before depreciation, with 10–20% of new-product budget diverted to servicing it rather than building anything new. (McKinsey)
Why the comparison is structurally unfair to modernisation
A modernisation project's cost is concentrated, visible, and appears as a single large number in a single budget cycle. The cost of not modernising is diffuse, spread across security risk, reduced velocity, and rising maintenance spend across many budget cycles, and it never appears as a single number anyone has to defend in a meeting.
This is not a coincidence of accounting. It is a structural bias that favours deferral every single year, because the visible number always looks smaller than the invisible one, right up until the invisible one becomes visible all at once — a breach, an unsupported vendor withdrawing support entirely, or a key person leaving with no handover.
Building an honest business case
Put a number on the diverted budget. If technical debt is consuming 10-20% of new development capacity, that is a real, calculable annual cost, not a vague drag.
Put a number on the security exposure. Not a prediction of whether a breach happens, but a statement of what it would cost if the known vulnerability were exploited, using published breach-cost data as a reference point rather than treating the risk as unquantifiable.
Put a number on lost velocity. If a comparable modern system would let a team ship a change in a fifth of the time, translate that time difference into cost across the volume of changes the business actually needs each year.
State the deferral cost explicitly, every year it is deferred. Not once, in the year the decision is made — every year afterward, so the accumulating cost is visible rather than reset to zero by the passage of time.
What we do
When we scope a modernisation project, we build the "do nothing" cost alongside the project cost, using the same rigour, so the comparison is actually fair. Most business cases we have reviewed do not do this, and most decisions to defer modernisation do not survive contact with an honest version of that comparison.
If you are trying to build a business case for or against modernising an old system, that is a conversation we are glad to have.
Kaizen Spark Tech designs and delivers software, AI, automation and digital infrastructure for businesses and institutions. Every statistic here is linked to its original published source, with sample size and limitations stated where they matter.