Ten systems, six years, three finished
In 2019, the US Government named ten critical legacy systems as the ones most needing replacement. Six years later, by February 2025, three of them were done.
Six years. Three systems.
Money was never the problem. By the GAO’s own review, those ten systems cost about $337 million a year just to keep running, and the agencies responsible had every reason to move. What they lacked was a way to see what they were changing.
The oldest system still in federal service belongs to the Department of Defense. It is sixty years old. It is still taking traffic. Of the eleven systems the GAO now rates as most in need of modernisation, eight run on languages the market has largely stopped teaching. Seven carry known cybersecurity vulnerabilities.
Read that as the shape of an industry, not a government. A dated list, a slipped deadline, a system nobody can safely touch. The same story runs inside every large organisation living on software it no longer understands.
So this is not about AI making software faster. There is a quieter effect, and it keeps getting underplayed. Modernisation has always been gated on comprehension rather than conversion, and comprehension was always the expensive part. AI is the first tool that has made it cheap enough to pay for.
The industry, meanwhile, is selling the exit.
Legacy is a risk classification, not an age
That word, legacy, is the first thing worth fixing. Around most tables it still means old. Old is a trap, because the estate with the most urgent problems is rarely the oldest one.
The UK Government settled a working definition in August 2026, and it deliberately avoids age:
Legacy IT are systems whose continued use creates a persistent, unacceptable burden or risk and can no longer be supported or secured effectively or economically.
Under it, a system is legacy if it crosses the line on any one of seven criteria:
out of support
lapsed contracts
missing skills
an inability to meet the business’s needs
unsuitable hardware
failing minimum cyber security standards
reliance on another legacy system.
Two of those are worth circling. Missing skills is the criterion AI genuinely attacks, because it is the one about understanding. The other is dependency.
Legacy is contagious.
You inherit it through the systems you depend on, not only through the code you wrote.
The age framing survives because it feels true. McKinsey puts as much as 70% of Fortune 500 software at twenty or more years old. That is the number that makes age feel like the whole story. It is not. Half of the organisations Saritasa surveyed said they had not upgraded because the current system still works. A working system can be exactly the one you are least able to change.
The estate is not shrinking either. About 250 billion lines of COBOL are still running in daily production, on the Open Mainframe Project’s count. Nearly half of the practitioners Micro Focus surveyed expected their COBOL footprint to grow over the next year. At sixty years old, the oldest federal system is not the last of its kind.
You cannot modernise what you cannot read
Kyndryl asked 2,000 business and technology leaders across five continents how well they understood their own estate. Only 9% said they fully understand their applications’ dependencies. A quarter said they are carrying large numbers of applications that nobody has documented.
Nine in a hundred. The estate has grown past the point where an organisation can hold its own shape in its head, and every plan to change it stalls on the same step, whatever language the code happens to be written in.
It is also why the standard decision menu so often picks wrong. There are six moves on it:
Rehost. Lift and shift. Move the code, change nothing else. Fast, cheap, and it leaves every legacy problem exactly where it was.
Replatform. The smallest change that lands it on a managed platform. Someone still has to know what breaks in the move.
Refactor. Restructure what is inside, keep the behaviour outside. This one does not start without comprehension.
Rebuild. Rewrite it. Rational only once the cheaper moves have lost.
Replace. Buy the SaaS equivalent and retire the code.
Retire. Switch it off, which is the move nobody proposes, because nobody can prove what depends on it.
Rehost is the only entry that needs no understanding of the estate at all, and it is the one that changes nothing that matters. Every other move is gated on the same expensive step, and the step is expensive for one reason: comprehension, not conversion.
One large European bank was spending 70% of its IT capacity keeping legacy systems alive (McKinsey, Dec 2024). That is not a maintenance bill. It is a comprehension bill, and it comes due every year.
AI’s numbers are real, and task-specific
The tools come back in here, but only where they have been measured.
McKinsey’s December 2024 study is the benchmark. Generative AI delivered a 40-50% acceleration in modernisation timelines and about a 40% cut in technology-debt costs, with quality going up rather than down. In one banking example, migrating 20,000 lines of code to a Java, Angular and PostgreSQL target was estimated at 700 to 800 hours of manual work. The agent-assisted route cut that estimate by 40%. The relationship-mapping step fell from 30 to 40 hours to about five.
The pattern holds as the numbers get narrower. IBM’s work with Egypt’s National Organization for Social Insurance cut the time developers needed to understand complex COBOL applications by 79%, in places from 24 hours to about five (vendor-reported). Amazon’s Q Developer saves 42% on Java upgrades, roughly 24 hours per application.
None of that supports “AI makes software faster”. It supports something narrower and more useful: AI is good at the reading and the mapping, which is the part that made modernisation uneconomic in the first place.
The limit appears the moment you ask for conversion. IBM’s own researchers published the arithmetic. A program with ten paragraphs, each translated at 90% accuracy, has roughly a 34% chance of coming out fully correct. Ten chances to be wrong, multiplied. IBM still calls its mainframe tool the “Rosetta Stone for mainframes”, which is a fair name for a translator and a troubling one for a moderniser.
McKinsey puts the trap in a single line: “Converting old code into modern tech languages simply transports your tech debt from a legacy system into a modern one.” They call it the code and load problem. The program compiles, the old design survives, and you have paid to move the problem somewhere more expensive to keep.
Translation is the one thing the evidence says does not work. It is also the thing the market is selling.
