Your Oldest Server Stays Because One Application Cannot Leave It. Four Ways Out, Weighed.
An old server is usually kept for one application that will not run anywhere else. We weigh four ways out, say what each one risks, and explain what waits while the machine stays, including new rules on public software.
In the server room of a municipal office there is a machine with a note taped to it. The note says: do not restart.
The machine was installed fourteen years ago, under the property tax application. Its maker stopped fixing its operating system some years ago. Last month a disk failed, and the replacement was found second-hand through a dealer.
The head of IT has been told twice to upgrade it, and has not. The tax application will not run on anything newer, and the firm that wrote it left when its contract ended.
The paradox: The machine cannot be kept safe and cannot be switched off, because the application it carries can live nowhere else.
What We Found
For this article we went through the public record on platforms that have reached the end of their support: the published support dates of widely used server operating systems and databases, the US national auditor’s September 2024 report on the aviation agency’s systems, and two rules on public-sector software published in 2026, one proposed in India and one in force in the US.
First, what we did not find: no record of which operating systems and databases Indian public bodies run, and no figure for what extended support, second-hand parts or specialist visits cost a public body. The support dates below are cross-sector; they say nothing about how common any product is in government.
Support ends on a published date. Paid security updates for one widely used server operating system, Windows Server 2012 and 2012 R2, run only to 13 October 2026; its standard support ended on 10 October 2023. The next version, Windows Server 2016, ends on 12 January 2027. Extended support for SQL Server 2016, a widely used database, ended on 14 July 2026. After such a date, a newly found flaw stays open.
Spare parts run out too. The US national auditor reported in September 2024 that the US aviation agency found “51 of its 138 systems are unsustainable, citing outdated functionality, a lack of spare parts, and more”. Those are air traffic control systems, which are not our kind of work, and we use the finding for one point only: a machine can outlive the supply of parts for it.
New rules on public software are arriving while old applications wait. 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 such items comply with the accessibility standards”, and that every government establishment review and revise its tender documents and contracts “within a period of ninety days from the date of publication of these rules”. 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: the machine stays because of the application, not because of the machine. An application written years ago for one operating system, often by a supplier whose contract has ended, cannot simply be moved, and nobody knows what would break if the platform under it were changed. The same application is then hard to change for anything else, including a new rule.
What our review does not show: We found no Indian public body on record with this problem, no figure for what keeping an old machine costs, and nothing from the Middle East on this issue. The support dates are cross-sector. The aviation finding concerns air traffic control. The Indian rules are a draft; the US rule binds US state and local governments only, and its dates have changed once already. Neither rule mentions old systems: that an old application makes them harder to meet is our reading, not the rules’ own words.
What Waits While the Old Machine Stays
The usual view is that an old machine is a risk to manage until the budget allows. Our reading is that it also holds back everything that depends on the application it carries.
The platform cannot be upgraded. The operating system and database stay as they are, because the application needs them.
The spending has no end. Extended cover, second-hand parts and specialist visits are bought each year for a machine nobody plans to keep.
The application cannot take on new duties. A change the department wants, or one a new rule asks for, such as meeting an accessibility standard, has to be made in code that few people can change safely.
New purchases are held up. Where a rule says nothing may be upgraded or renewed unless it meets a standard, as India’s draft rules of 16 July 2026 propose, an old application that cannot be changed may turn every renewal into a question.
The gap we see: most bodies we write for know which machines are old. Few know which application keeps each machine, what that application does, and what it would take to move it. A body that knows can retire machines on dates it chooses, and meet new rules on applications it can change.
This is our reading of the evidence. It is not a measured market figure.
Four Ways Out, Weighed
There are four real options. Each one is right for somebody.
| Option | When it fits | What it risks |
|---|---|---|
| Buy extended support and keep the machine running | The application will be retired soon anyway, and cover is available | It buys time, not an exit; spending continues and parts may run out |
| Upgrade the operating system and database in place | The application turns out to run on the newer platform after testing | It is often the step that breaks the application; nobody knows until it is tried. This is work for the body’s own team or vendor, not ours |
| Move the application as it is to newer machines or a virtual server | The application can run on a supported platform without change | The old code moves with it, with the same limits on change; it does not help where the application needs the old platform |
| Rebuild the application, one module at a time, onto supported technology, with the old one still running | The application is what keeps the machine, and it must keep changing | It costs money before the machine can go, and the body’s team still runs the old machine until the last module moves |
Our recommendation: find out first what the application does and what it needs from the platform under it. If it can move as it is, move it. If it cannot, rebuild it in stages, starting with the parts the public or the money depend on, so the machine can be switched off by the department’s own team when the last module leaves. We do not upgrade operating systems, replace servers, supply parts or sell extended support, and we do not keep the old machine secure in the meantime.
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 |
|---|---|---|---|
| Why each old machine is kept | ”It runs something important” | The application named, with what it needs from the operating system and database | The map of the system as it stands |
| What the 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 |
| Whether the application can move as it is | Unknown until someone tries | Answered, with the reason | The risk register |
| Cost of keeping the machine against cost of moving the application | Not compared | Set side by side | The cost comparison |
| Date the machine can be switched off | None | Set by the staged plan; the department’s team switches it off | 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 machine, the application it carries 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.
- 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 the application that keeps the old machine 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.
- 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 machine running or secure while the application is moved; the body’s own team or vendor does. We do not audit or certify accessibility and give no legal advice on what any rule requires of a body. We do not work in COBOL or assembly language or on mainframes, or 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. We have no published case of this work for a public body.
What changes for the business:
| Role | What they gain |
|---|---|
| Head of department | Services to citizens stop resting on a machine its maker has walked away from, and the department leaves it on a date it chose. |
| Head of procurement | Purchases made only to keep the old platform alive have an end in sight. |
| Head of IT | Applications move onto technology that is still supported and that people can be hired for, and the team switches the old machine off itself. |
| Head of finance | The cost of staying is set beside the cost of leaving, and spending on the old platform comes to an end. |
| Head of information security | Fewer machines nobody fixes after each application moves, and fewer exceptions to renew. |
The cases in this article, and what IOanyT does about that kind of problem:
| The case | What IOanyT does |
|---|---|
| The US aviation agency, as the US national auditor reported in September 2024, found 51 of its 138 systems unsustainable, citing outdated functionality and a lack of spare parts, among other reasons. | Air traffic control is not our kind of work, and we make no comment on the agency. For an application a public body built, we write down what it needs from the machine under it and plan its move, so the machine can be retired. |
IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. We move the application, so your own team can switch the old machine off.
Sources
In this issue
Unsupported hardware and software
Research note 1
Nobody Can Say How Much of Your Department Runs on Unsupported Systems. Here Is What the Public Record Shows.
Two national governments have counted their unsupported systems; most public bodies cannot. What the public record shows, the options, and our benchmark.
Research note 3
The Fix for Your Old Systems Is Too Big to Fund as One Project. Here Is the Benchmark We Would Set.
Money comes at once for a failure, rarely for removing its cause. Four ways to fund the exit from old systems, weighed, and the benchmark we would agree first.
Issue study
Four of the Eleven
Unsupported platforms in government from the public record: critical systems, an internal review, funding after a breach, the options and our benchmark.
More from Government and public sector
Replacement fails or overruns
A Deferred Replacement Is Still a Decision. Four Ways to Replace an Old System, Weighed.
Thin or missing documentation
A New Officer Takes Charge of Your System With Nothing to Read. Three Ways to Change That, Weighed.
Wrong outputs trusted as correct