Four of the Eleven

1. At a Glance

Issue study · From the public record. None of the bodies named here was an IOanyT client, and IOanyT had no part in the events described. All are national governments or a national agency, far larger than the departments, municipal bodies, utilities and boards we write for. We found no public record of an Indian public body, or of a body of our readers’ size, on this issue. Each case is reported as the public record gives it, without judgement on any government, body or official.

Organisation type	The US federal government’s most critical legacy systems, as its national auditor reported them, set beside the position of a mid-size public body whose applications keep old machines in service
Size band	The cases: national. Our reader: a state department or directorate, a municipal corporation or council, a public utility, a board or authority, or a public-sector undertaking
Region	The cases: US and UK. The reader: anywhere
The decision at stake	What to do about applications that keep unsupported machines in service: buy more extended support, upgrade the platform in place, move the application as it is, or rebuild the application in stages onto supported technology
The public outcome	Of the 11 most critical US federal legacy systems, “about 23 to 60 years old”, four have unsupported hardware or software and seven have known security weaknesses; three of the eleven had complete plans to modernise them, six had incomplete plans and two had none
Why it matters to a mid-size public body	If the most critical systems of a national government stand on unsupported platforms without complete plans, a smaller body is unlikely to have a better list. Without one it cannot plan, budget or tender the exit

2. The Business Problem, in the Buyer’s Words

“We are asked every year how much of the department runs on systems nobody fixes, and every year we answer with a spreadsheet of servers. I know there is a machine under the tax application that we cannot upgrade, and a database under the licence register that nobody dares touch. I do not know how many more there are, what each application does, or what it would take to move them. The proposal to replace everything has been deferred three times. Meanwhile we pay for cover and second-hand parts.”

These words are imagined. They describe the decision as the research shows it, not a real conversation.

The body is caught between machines it cannot keep safe and applications it cannot move, because nobody has written down what those applications do or what they need.

3. What We Found

Method. We went through the public record on unsupported systems in government: the US national auditor’s July 2025 report on the most critical federal legacy systems and its September 2024 report on the aviation agency’s systems, the UK government’s own review of its digital services (January 2025), statements by the UK digital department to Parliament (reported in June 2026), the UK government’s statements on the Legal Aid Agency (May and September 2025), published support dates for widely used server software, and two rules on public-sector software published in 2026. The sector research behind this study holds no Indian public body and no body of our readers’ size on this issue.

The most critical systems, on unsupported platforms. In a July 2025 report, the US national auditor looked at the 11 most critical federal legacy systems. They are “about 23 to 60 years old” and cost about 754 million US dollars a year to run. Eight use outdated languages, four have unsupported hardware or software, and seven have known security weaknesses. Three of the eleven had complete plans to modernise them, six had incomplete plans and two had none. About 80% of the more than 100 billion US dollars the federal government spends on IT each year goes on running existing systems. Some of these systems are written in languages and run on machines that are not IOanyT’s kind of work.

A government that counted. The UK government’s own review, published in January 2025, found that about 28% of central government department systems were legacy in 2024, up from 26%, by its own definition: “based on an end-of-life product, out of support from the supplier, impossible to update, no longer cost-effective, or considered to be otherwise above the acceptable risk threshold”. Of those, 22% were “red-rated”, and “28% of red-rated legacy systems lack remediation funding”. In the same review’s survey of more than 500 public-sector leaders across 120 organisations, “around 15% of survey respondents could not even estimate the size of their legacy estate”. In a letter reported in June 2026, the permanent secretary of the UK’s central digital department wrote to a parliamentary committee that the existing “data is incomplete and uneven in coverage” on the government’s old systems.

When the parts run out. In a September 2024 report, the US national auditor recorded that the US aviation agency found “51 of its 138 systems are unsustainable, citing outdated functionality, a lack of spare parts, and more”. These are air traffic control systems, which are not IOanyT’s kind of work; we use the finding only to show that a machine can outlive the supply of parts for it.

When the money arrives. A hack of the UK Legal Aid Agency’s online services was discovered on 23 April 2025, and its digital services were taken offline. In a written answer to Parliament in September 2025, a justice minister said the breach “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”. The record does not say the agency’s systems were unsupported, and we do not say so. We note only the order of events: funding came after the failure.

The dates. Support for widely used server software ends on published dates. Paid security updates for Windows Server 2012 and 2012 R2 run only to 13 October 2026; Windows Server 2016 ends on 12 January 2027; extended support for SQL Server 2016 ended on 14 July 2026. These dates are cross-sector; the research does not record which products public bodies run.

New rules on public software. In India, draft rules published on 16 July 2026 under the disability rights law propose that “no government establishment shall, directly or indirectly, procure, deploy, upgrade, or renew” the items they cover unless those items comply with the accessibility standards. They are a draft, not yet in force. In the US, a federal rule of 20 April 2026 extended the compliance dates for the accessibility of the web content and apps that state and local governments “provide or make available, directly or through contractual, licensing, or other arrangements”: to 26 April 2027 for those with a total population of 50,000 or more, and to 26 April 2028 for smaller ones. The dates have been extended once.

Our reading of why the machines stay. These four are our reasoning from the record above. None is a finding of any source.

1. Nobody has the count. Systems were commissioned one at a time, and no single list records which application runs on which platform.
2. The application holds the machine. An old server cannot be upgraded because the application on it was built for that platform, and nobody knows what an upgrade would break.
3. The supplier and the knowledge have gone. The firm that built the application is no longer under contract, and nothing written says what it does.
4. The fix is framed as one programme. It is too large for one budget year and too vague to tender, so it is deferred until something fails.

4. The Options a Body in This Position Had

Option	When it fits	What it risks	Our view
Buy extended support and keep the machines	The applications will be retired soon anyway, and cover is available	Buys time, not an exit; spending continues and parts may run out	Right only as a bridge to a dated exit
Upgrade the operating system and database in place	The application runs on the newer platform after testing	Often the step that breaks the application; the body’s own team’s or vendor’s work	Right where testing shows it works; not our kind of work
Move each application as it is to newer machines or a virtual server	The application runs on a supported platform without change	The old code moves with its limits; no help where the application needs the old platform	Right for applications that turn out to be portable
Specify each application, rank them by exposure, and rebuild those that need it one module at a time onto supported technology	The applications keep the machines, and they must keep changing	Costs money before machines can go; the body’s team runs the old machines until each last module moves	Our recommendation

5. Our Recommendation, and the Decision It Asks of the Board

For the applications a body built or had built (licence and permit registers, property tax and utility billing, citizen portals, grievance and case-management systems): count by application, not by machine. Read each application, write down what it does and what it needs from the platform under it, and rank the applications by exposure: public service, money and known flaws. Where an application can move as it is, move it. Where it cannot, rebuild it one module at a time onto supported technology, beside the old application, with a traceability matrix to prove each module does what the old one did. The old application keeps working until each module is accepted, and the body’s own team switches each machine off when its last application has left. How each stage is bought is the body’s own decision under its own rules.

6. Benchmark: Where You Are Now, and Where You Should Be

These are targets, not results. In an engagement the starting points are replaced by the body’s own figures, taken in the first review.

Measure	Typical starting point	Where it should be	How it is checked
Applications on unsupported platforms	Counted by machine, or not counted	Each application named, with the platform it needs and its end-of-support date	The map of the system as it stands and the risk register
What each application does	Known to a few people or to a supplier who has left	Written down and confirmed by the body’s own experts	The specification
Exceptions for unsupported machines	Renewed each year, with no owner	Each tied to the application that keeps it, with a planned end	The risk register and the staged plan
The exit as a budget request	One programme, deferred	Stages ranked by exposure, each with a fixed quote	The staged plan
Proof that a stage is done	A go-live date	Each module accepted, every old function linked to its replacement	The traceability matrix
Unsupported machines left	Not counted	Fewer after each stage; the body’s team switches each one off	The risk register, updated after each module

7. How IOanyT Would Work

1. We listen: a free Reliability Review. A first conversation about the applications the body relies on, the machines under them and what has been tried. 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 study 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.
4. If you approve, we build. We replace a system one module at a time while the old one keeps running, onto technology that is still supported. We never do a single cutover. A traceability matrix links every old function to its replacement. 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.

8. What the Client Would Own

• The map and the specification: each application, what it does and what it needs from the platform under it, in writing. The body can show it to any supplier, subject to its own contract with its present supplier.
• The risk register: each unsupported machine tied to the application that keeps it, ranked by exposure.
• The traceability matrix: for every module IOanyT rebuilds, every old function linked to its replacement, with how it was checked.
• The code: the rebuilt modules are the body’s. No runtime or platform fee.
• The filled-in benchmark: each measure, where it started and where it stands.

Switching off each old machine is the body’s own team’s step.

9. What This Approach Does Not Cover

• IOanyT does not upgrade operating systems, replace servers, supply hardware or spare parts, apply patches or sell extended support.
• IOanyT does not keep the old machines running or secure while applications move; the body’s own team or vendor does. It supplies no security controls or monitoring.
• IOanyT does not claim that its work prevents an attack or a data breach. It removes one cause of exposure at a time: an application tied to a platform nobody fixes.
• IOanyT does not work in COBOL or assembly language or on mainframes, and does not work on air traffic control, defence or other safety systems.
• IOanyT does not audit or certify accessibility and gives no legal advice on what any rule requires of a body.
• IOanyT does not say it is empanelled, registered or approved as a supplier to any government, or that it meets the conditions of any tender. It gives no advice on budget or procurement rules.
• IOanyT has not stated that it delivers AI on a government cloud or on a body’s own servers.
• This study does not say IOanyT would have prevented the events described. IOanyT has no published case of this work for a public body.

About this study: IOanyT did not work on this case. It is drawn from published findings, cited below.

10. Sources

Source	Used for
US Government Accountability Office, GAO-25-107795, 17 July 2025	The 11 most critical federal legacy systems; plans; running costs; the 80%
US Government Accountability Office, GAO-24-107001, 23 September 2024	The aviation agency’s 51 of 138 systems
UK State of Digital Government Review, 21 January 2025	The 28%, the definition, red-rated systems and funding, the survey’s 15%
PublicTechnology, 12 June 2026	”Incomplete and uneven in coverage”
Ministry of Justice and Legal Aid Agency, 19 May 2025	The Legal Aid Agency: the attack and the services taken offline
UK Parliament written answer 71864, 8 September 2025	The Legal Aid Agency: the minister’s statement
endoflife.date/windows-server; Microsoft, SQL Server 2016 lifecycle	Support dates
India, draft rules under the disability rights law, 16 July 2026	The proposed procurement condition
US Department of Justice, interim final rule, 20 April 2026	The US accessibility dates

IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. We count your systems by application, move the ones that keep old machines in service, and leave the switching-off to your own team on a date you choose.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →