Nobody Can Say How Much of Your Department Runs on Unsupported Systems. Here Is What the Public Record Shows.
We went through the public record on unsupported systems in government. Two national governments have counted; most public bodies cannot. Here is what we found, the options, and the benchmark we would set before any money is asked for.
A question has arrived for the department. It asks for a list of every system that runs on software its maker no longer supports, and the plan for each. The reply is due in ten days.
The head of IT opens the only list there is. It is a spreadsheet, last updated five years ago. It names servers, not the applications on them. Two of the offices on it have since merged.
A circular goes to every section. Three sections reply with three totals, and none of them matches the spreadsheet.
The paradox: The department answers for every system it runs, and cannot say what those systems run on.
What We Found
For this article we went through the public record on unsupported systems in government: the US national auditor’s 2025 report on the most critical federal legacy systems, the UK government’s own review of the state of its digital services, published in January 2025, and the UK digital department’s statements to Parliament in 2026.
First, what we did not find: no count of unsupported systems for any Indian public body, state department, municipal body or public utility, and nothing from the Middle East. Every body named below is a national government, far larger than the departments and boards we write for.
When a government counts, the share is large. The UK government’s own review found that about 28% of central government department systems were legacy in 2024, up from 26%. By the review’s own definition a system is legacy if it is “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 legacy systems, 22% were “red-rated”, meaning high risk.
The riskiest systems are often the ones nobody has funded. The same review found that “28% of red-rated legacy systems lack remediation funding”. A system can be known to be at risk and still have no money set against it.
Even the most critical systems run on unsupported platforms. The US national auditor looked at the 11 most critical federal legacy systems. They are “about 23 to 60 years old”. Four have unsupported hardware or software. Seven have known security weaknesses. Only three of the eleven had complete plans to modernise them; six had incomplete plans and two had none.
Many people cannot say how big the problem is. In the UK government’s own 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”.
Even the centre’s own record is partial. In 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.
Our reading: the count is missing because lists are kept by machine, by contract or by budget head, and the question that matters is asked by application. An unsupported server matters because of the application that runs on it, and the application is what nobody has written down.
What our review does not show: We found no count of unsupported systems for any public body of our readers’ size, and nothing from India or the Middle East on this issue. The figures describe US federal agencies and UK central government. The 15% is of the people who answered a survey, not of public bodies. That the missing link is between the machine and the application is our reasoning, not a finding of any source. We make no comment on any government’s choices; we report what its own auditors and reviews published.
What Waits on a Count Nobody Has
A department without the count is not careless. Our reading is that several things it needs to do cannot start until the count exists.
A plan cannot be written. A plan for unsupported systems starts from a list of them. Without one, every plan is a request for a study.
A budget cannot be asked for. Finance asks what the money is for. “Legacy systems” is not an answer it can sanction.
A tender cannot be scoped. A tender for “modernisation of legacy systems” with no named applications cannot be priced, and bidders price the uncertainty.
Exceptions are renewed without an owner. Each unsupported machine stays on an exception list, renewed every year, because nobody can say which application keeps it there or when that will change.
The gap we see: most public bodies we write for could say that some of their systems are old. Few could name each application, the platform under it, the date its maker stopped fixing that platform, and what each application does. A body that holds that list can plan, budget and tender for the exit. A body that does not repeats the same question every year.
This is our reading of the evidence. It is not a measured market figure.
Four Ways to Get the Count, Weighed
There are four real options. Each one is right for somebody.
| Option | When it fits | What it risks |
|---|---|---|
| A circular asking each section to list its systems | A first view is needed quickly, and sections know their systems | Sections list servers or contracts, not applications; totals disagree, as in the scene |
| A hardware and software inventory by the IT team or a vendor | The body wants to know what machines and licences it has | It shows what is installed, not which application depends on it or what each one does |
| A one-off documentation exercise for each system | The body has budget and time for a full write-up | It describes each system in isolation, and goes out of date as soon as the systems change |
| An assessment that reads the applications, records the platform each one needs and what each one does, and ranks them by exposure | The count must lead to a plan, a budget and a tender | It costs money before anything is moved, and it shows problems the body may then have to fund |
Our recommendation: count by application, not by machine. Start with the applications that serve the public or handle money, read what each one does and what it needs from the platform under it, and rank them by exposure. The inventory and the circular are useful inputs; on their own they do not produce a plan. We do not upgrade operating systems, replace servers or keep the old machines secure while this is done; the body’s own team or vendor does.
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 |
|---|---|---|---|
| Applications on unsupported platforms | Counted by machine, or not counted | Each application named, with the platform it needs | The map of the system as it stands |
| End-of-support date under each application | Not recorded | Recorded for the operating system and database under each one | The risk register |
| What each application does | Known to a few people | Written down and confirmed by the body’s own experts | The specification |
| Unsupported machines on the exception list | Renewed every year, with no owner | Each tied to the application that keeps it there, with a planned end | The risk register and the staged plan |
| Order of work | Whatever failed last | Ranked by exposure: public service, money, known flaws | The staged plan |
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
- We listen: a free Reliability Review. A first conversation about the applications the body relies on and what it knows about them. 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.
- 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.
- We read the system and propose: the Legacy System Specification Assessment. Here the system is an application the body built or had built, such as a licence register, a billing or property tax application or a citizen portal. 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.
- 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. 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.
- 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 are moved. We do not supply security controls or monitoring, and we do not claim that our work prevents an attack. We do not work in COBOL or assembly language or on mainframes, and we do not work on air traffic control or other safety systems. We do not say we are empanelled with any government, and we give no advice on procurement rules: how an assessment and the stages after it are bought is the body’s own decision. We have no published case of this work for a public body.
What changes for the business:
| Role | What they gain |
|---|---|
| Head of department | When the minister, the auditor or the legislature asks how much of the department runs on systems nobody fixes, there is an answer, with a plan beside each item. |
| Head of procurement | A tender can be written from a list of named applications and what each one does, not from a general wish to modernise. |
| Head of IT | A written record of what each old application does and what it needs from the platform under it. Moving it stops being a gamble. |
| Head of finance | ”Old systems” stops being one unbudgeted worry and becomes a list of named items, each of which can be costed. |
| Head of information security | Every unsupported machine is tied to the application that keeps it there, so each exception has an owner and an end. |
The cases in this article, and what IOanyT does about that kind of problem:
| The case | What IOanyT does |
|---|---|
| The UK government’s own review: about 28% of central government department systems legacy, 22% of those red-rated, and 28% of red-rated systems without remediation funding. | We make no comment on any government’s choices, and our part is far narrower than a national estate. For a body’s own applications, we record what each one does and the platform it needs, and rank them by exposure. |
| The US national auditor: four of the 11 most critical federal legacy systems on unsupported hardware or software; three of eleven with complete plans. | Those systems include languages and machines we do not work on. For an application a body built on technology we read, we write the specification and a staged, priced plan to move it. |
IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. We start by counting your systems the way the question is asked: by application, with what each one does and what it stands on.
Sources
In this issue
Unsupported hardware and software