The Fix for Your Old Systems Is Too Big to Fund as One Project. Here Is the Benchmark We Would Set.

The proposal is back on the table for the third year. Its title has not changed: replacement of legacy systems, all sections, five years.

Finance returns it with the same note as before. Defer. Resubmit with a detailed scope and a firm cost. Nobody argues, because nobody can supply either.

The next item on the agenda is an emergency sanction. A server failed last week and a public counter was closed for four days. The money is approved in ten minutes.

What We Found

For this article we went through the public record on how governments fund the exit from old systems: the US national auditor’s 2025 report on the most critical federal legacy systems, the UK government’s own review of its digital services, published in January 2025, and reporting in 2025 on the funding a UK agency received after a breach of its systems.

First, what we did not find: no Indian public body’s budget for old systems, and no figure for what a public body of our readers’ size spends on keeping or replacing them. The bodies below are national governments and one national agency.

Most of the money goes on running what exists. The US national auditor reported that about 80% of the more than 100 billion US dollars the federal government spends on IT each year goes on running existing systems.

Systems known to be at risk go unfunded. The UK government’s own review found that 22% of its legacy systems were “red-rated”, and that “28% of red-rated legacy systems lack remediation funding”.

Plans are often incomplete. Of the 11 most critical US federal legacy systems, the auditor found three with complete plans to modernise them, six with incomplete plans and two with none.

Money arrives after the event. The Legal Aid Agency, part of the UK justice ministry, is far larger than the bodies we write for, though smaller than the national departments above. After a criminal attack, it took its digital services offline. In a written answer to Parliament on 21 July 2025, the justice ministry said the attack “was enabled by the fragility of the LAA’s IT systems”, and cited “over £20 million in extra funding this year to stabilise and transform the Legal Aid Agency digital services”. We make no comment on the agency or on anyone’s decisions; we use the record for one point only: funding came after the event.

Our reading: the exit from old systems is usually put forward as one programme, too large for one year’s budget and too vague to tender. It is deferred until something fails, and then the money goes on the failure.

What a Stage-by-Stage Exit Opens Up

The usual view is that old systems need one large programme, and that nothing can start until it is approved. Our reading is that a stage the budget can carry opens up three things the large programme cannot.

A start this year. One application, one stage, inside one budget year, needs a smaller sanction than a five-year programme.

A scope a tender can describe. A stage with a named application and a written specification can be priced. A programme called “legacy systems” cannot.

Evidence before the next stage. Each stage ends with something the body can check: a module accepted, a machine closer to retirement. The next request for money rests on that, not on a promise.

This is our reading of the evidence. It is not a measured market figure.

Four Ways to Fund the Exit, Weighed

There are four real options. Each one is right for somebody.

Option	When it fits	What it risks
One large programme for all old systems	Funding for several years is assured, and the scope can be written in full	It is too large for one budget year and too vague to tender, so it is deferred
Fund failures as they come	The old systems are few and close to retirement	Money goes to the failure, not the cause, and services stop meanwhile
Upgrade platforms one machine at a time	Each application runs on the newer platform after testing	Where an application needs the old platform, the upgrade breaks it; this is the body’s own team’s or vendor’s work
Stages, most exposed application first, each specified, priced and accepted before the next	The body must show progress within each budget year and buy in steps	The first step is an assessment that costs money before anything moves, and later stages must still be sanctioned one by one

Where You Are Now, and Where You Should Be

Before any work begins we set a benchmark: a few measures taken from your own systems, each with a target. For this issue it would look like this.

Measure	Typical starting point	Where it should be	How it is checked
The exit as a budget request	One programme, “all sections, five years”	A staged plan, each stage within one budget year	The staged plan
Order of the stages	Not set, or whatever failed last	Ranked by exposure: public service, money, known flaws	The risk register
Price of each stage	”To be assessed”	A fixed quote for each stage, after the system has been read	The staged plan with its fixed quote
Proof that a stage is done	A go-live date	Each module accepted, with a traceability matrix showing each old function and its replacement	The traceability matrix
Unsupported machines left	Not counted	Fewer after each stage; each remaining one with a planned end	The risk register, updated after each module

The starting points above are what we expect to find; in an engagement they are replaced by your own figures, taken in the first review. The targets are what we would work towards with you. They are not results we have already achieved for a public body.

How We Work With You

1. We listen: a free Reliability Review. A first conversation about the old systems, the last budget request and what failed. You leave with a short written note of what we found. You can start with a conversation about the system; we ask for read-only code access only when the assessment begins.
2. We research. We research your sector, the regulator’s position and what the public record says about firms in your situation. This article is an example of that work.
3. We read the system and propose: the Legacy System Specification Assessment. Here the system is the set of applications that keep unsupported machines in service. It produces a map of the system as it stands, a written specification of what it does, a risk register, a cost comparison between keeping and replacing the system, and a staged plan with a fixed quote. AI does a first pass, our senior engineers review it and trace it to the code, and your own experts confirm it. Code access is read-only and logged, never used for training, and deleted within 30 days of the evaluation ending unless we engage. You get the options and our recommendation.
4. If you approve, we build. We replace a system one module at a time while the old one keeps running. We never do a single cutover. Each module has a traceability matrix. The work is billed by milestone, each milestone tied to a module you accept, and you can pause after any accepted module.
5. We review against the benchmark. Before work starts we set the benchmark. After each module we show you where each measure stands, and the filled-in benchmark is yours at the end.

The Review is free. Every paid step is fixed price, agreed at scoping. Stop after any step. The findings are yours. The assessment fee is credited in full against the first build stage if it starts within 90 days of the report.

What we do not do: we do not upgrade operating systems, replace servers, supply parts or sell extended support, and we do not keep the old machines running or secure while applications move. We do not claim that our work prevents an attack or a breach. We do not work in COBOL or assembly language or on mainframes. We do not say we are empanelled with any government, we give no advice on budget or procurement rules, and we do not say a body’s budget year will fit any of our terms. We have no published case of this work for a public body.

What changes for the business:

Role	What they gain
Head of department	A start can be made this financial year on the systems citizens rely on most, without waiting for a programme too large to approve.
Head of procurement	The work can be bought one stage at a time, on a written specification the department owns and any bidder can price.
Head of IT	The riskiest machines lose their applications first, and each stage is small enough to finish.
Head of finance	Money is asked for one stage at a time, each small enough to be sanctioned on its own evidence.
Head of information security	Findings are closed in order of exposure, not accepted again each year.

The cases in this article, and what IOanyT does about that kind of problem:

The case	What IOanyT does
The Legal Aid Agency: in a written answer to Parliament (21 July 2025), the attack “was enabled by the fragility of the LAA’s IT systems”; over £20 million in extra funding that year.	We make no comment on the agency, and our part is far narrower: we do not secure systems or respond to breaches. For a body’s own applications, we specify them and plan their move in stages a budget can carry.
The US federal government: about 80% of its IT spending on running existing systems; three of its 11 most critical legacy systems with complete plans.	Those systems include languages and machines we do not work on. For applications on technology we read, we produce the staged, priced plan and build only the stages a body approves.
The UK government’s own review: 28% of red-rated legacy systems without remediation funding.	We make no comment on any government’s choices. We give a body a first stage it can price and fund, with a benchmark to show what it achieved.

IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. We turn one programme nobody can fund into stages a budget can carry, each measured before the next.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →