Legacy System Modernisation: A Practical Guide
The US federal government spends $754 million a year maintaining just eleven of its oldest systems, some running languages taught to almost nobody currently in the workforce. Here is how to decide what to do about the equivalent system in your own organisation.
Every organisation past a certain age has one. A system nobody would choose to build today, that nobody fully understands anymore, that everybody is afraid to touch, and that the business cannot run without. This guide is about deciding what to do with it.
How bad the oldest systems actually get
The US Government Accountability Office reviewed 69 federal legacy IT systems and identified 11 as most critical, ranging from 23 to 60 years old, with a combined $754 million in annual operations and maintenance cost. Of those eleven: 8 ran on outdated programming languages, 4 ran on hardware no longer supported by the vendor, and 7 had known cybersecurity vulnerabilities. (GAO-25-107795)
The IRS's Individual Master File, the system underlying individual tax processing, is now roughly 63 to 64 years old. It is a genuinely extreme example, not a typical one — but the direction it points in is not extreme at all. Systems that were merely "old" ten years ago are now old enough that the people who understand them are retiring faster than institutional knowledge can transfer.
One widely repeated example belongs in the past tense rather than the present. The US Department of Defense's Strategic Automated Command and Control System famously ran on 8-inch floppy disks — but this was replaced in June 2019. Anyone citing it as a current example is working from an outdated article. It remains useful as a case study in how long a critical system can outlive its intended era, just not as a live example of neglect.
Why "just replace it" is rarely the answer
The instinct, once a system's age becomes visible, is to schedule a full replacement. This is usually the most expensive and highest-risk option available, and it is worth being specific about why before choosing it.
Gartner's original 2011 framework for application modernisation options — since expanded by cloud vendors into longer lists, most notably AWS's seven-option version — identified five core strategies: Rehost (move as-is to new infrastructure), Refactor (restructure code without changing external behaviour), Revise (modify code to enable further migration), Rebuild (redesign the application while preserving scope), and Replace (discard and adopt or build something new). Note this is Gartner's five, sometimes confused online with AWS's separate seven-option list — check which framework a source is actually citing before quoting a number of "Rs."
Full replacement sits at one extreme of that list, and it carries a specific risk the data is clear about. The largest peer-reviewed study of IT project costs — 5,392 projects collected, 4,677 with usable cost data, 2002 to 2014 — found the median project lands on budget, but the mean overrun ratio is 1.8 because overruns follow a power-law distribution with a very long tail. Critically, the study found no statistically significant difference in that tail by project size (p = 0.863). A full-replacement programme does not become safer because it feels more thorough. (JMIS, 2022)
The decision framework
Start with what the system actually costs you, not what it feels like it costs. Direct maintenance spend is the visible number. The invisible ones are: how long a change now takes compared to a modern equivalent, how many people can safely make that change, what happens if one of them leaves, and what the security exposure actually is. The GAO's own criteria for "critical" weighted unsupported languages and hardware heavily — that is a reasonable model to borrow.
Rank by risk, not by age. A ten-year-old system running unsupported infrastructure with a single person who understands it is a higher priority than a thirty-year-old system that is stable, documented, and low-traffic. Age is a proxy for risk, not the risk itself.
Default to the smallest intervention that removes the actual risk. If the risk is unsupported hardware, rehosting may solve it entirely. If the risk is that nobody can safely change the code, refactoring addresses that without discarding decades of encoded business logic that a rebuild would have to rediscover from scratch, often imperfectly.
Treat full replacement as the option of last resort, chosen deliberately. Not because it is never right — sometimes the system's fundamental architecture cannot support what the business now needs, and no amount of refactoring changes that. But choose it because the other four options were genuinely evaluated and ruled out, not because it felt like the more serious response.
How these projects actually fail
Two patterns recur in the reporting on failed modernisation efforts, and neither is really about technology.
Data migration is treated as a technical afterthought instead of the central risk. We cover this in detail in a companion piece on data migration, but the short version is that legacy data is rarely as clean as anyone assumes, and discovering that mid-migration is far more expensive than discovering it during planning.
The cutover is treated as a single event rather than a managed transition. A big-bang replacement of a critical system, on a fixed date, with the old system switched off, concentrates an enormous amount of risk into a single moment. We cover the alternative in our piece on the strangler fig pattern.
What this costs, honestly
Technical debt is not a metaphor. McKinsey's 2020 survey of 50 CIOs at financial services and technology firms above $1 billion in revenue estimated technical debt at 20–40% of the value of the entire technology estate before depreciation, with 10–20% of new-product budget diverted to servicing it. (McKinsey) Small, sector-specific sample — but it is measuring the same thing the GAO found in a completely different context: an old system does not sit still and cost the same amount forever. It compounds.
What we do
We start by auditing the estate before recommending a strategy, because the honest answer is often "rehost this, refactor that, leave this alone for now" rather than one dramatic programme. If you are trying to work out what to do with a system nobody wants to touch, 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.