Hospitals Keep Unsupported Servers for One Reason. It Is Rarely the Server.

The infrastructure team has a plan to retire every server that its maker no longer fixes. There are nineteen on the list.

Eighteen have a date. The nineteenth has a note beside it: do not touch. It runs the billing application, written fourteen years ago by a firm that has since closed.

Somebody once moved it to a newer server over a weekend. On Monday the insurance claims would not print, and the old server went back on. Nobody has tried since.

What We Found

Before we suggest anything to a hospital group, a laboratory chain or a pharma company, we study its sector. For this article we went through the public record on unsupported operating systems in healthcare: reporting of one national health service’s ransomware attack, UK government and staff-survey figures, and the maker’s published support dates, from 2020 to 2026.

Four findings stand out.

A health service can carry tens of thousands of machines past the date. In 2021 one European national health service was hit by ransomware. The reporting of the review that followed records that tens of thousands of its machines were running Windows 7, out of support since January 2020. This is an older case, from an organisation far larger than most of our readers.

Old technology is common. The UK government’s review of January 2025 records that around 10% to 50% of NHS trusts’ technology is classed as legacy. In one survey of over a thousand frontline healthcare staff, fewer than two in three in the US and only about a third in the UK said they work with modern systems.

The dates are published years ahead, and they keep arriving. Support for Windows Server 2012 and 2012 R2 ended on 10 October 2023, and the paid security updates sold after that ran to 13 October 2026. Windows Server 2016 follows on 12 January 2027. Nothing stops working on the day; the fixes stop coming.

The oldest machines also lose the ability to connect safely. The maker’s own table lists the current standard for encrypted connections, TLS 1.2, as “Not supported” on Windows Server 2008 without its second service pack, and “Disabled” by default on Windows Server 2008 R2.

The record does not explain why the machines stay. Our reading is that they rarely stay out of neglect. They stay because an application on them will not run on anything newer, and nobody can say what it needs.

What Waits on the Machine Nobody Can Change

Unsupported servers are usually discussed as a security problem. Our reading is that they also hold the organisation in place.

The first cost is the exception. A machine that cannot be upgraded is recorded as a security exception and renewed every year. Renewing takes a signature. Ending it takes a project, so the signature wins.

The second cost is knowledge. Each year the application stays, more of the people who understood it leave.

The third is what cannot be built. A new patient portal, a connection to a laboratory partner or an insurer: each has to reach the application on the old machine, the part nobody can change.

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

Four Ways Forward, Weighed

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

Option	When it fits	What it risks
Pay for extended support and keep the machine	The maker sells it, and a date to leave is already set	It buys time and nothing else, and ends when the maker ends it
Upgrade the operating system in place	The application is known to run on the newer version	Old applications often stop on a newer version. The upgrade is tried and rolled back
Replace every old application at once	The applications are few, small and well understood	One date carries all the risk, for every department, and nobody yet knows what the old applications do
Write down what each application does, then move it module by module onto supported technology	The applications are old, undocumented and used every day	It runs over several stages. Reading the application will turn up things nobody can explain

Where You Are Now, and Where You Should Be

A recommendation is only useful if you can tell later whether it worked. So before any work begins we set a benchmark: a few measures taken from your own systems, each with a target.

For this issue, the benchmark would look like this.

Measure	Typical starting point	Where it should be	How it is checked
Machines kept old only because of an application	A list of servers, with no reason given	Each machine listed with the application that keeps it there	The record is compared with the servers and the applications
What each of those applications does and needs	Known to a few people	Written down, including what it needs from the machine under it	The specification
A plan against each machine	”Upgrade planned” or “exception renewed”	A stage, in order, against the application on it	The staged plan
The exception list	Renewed each year, never shorter	Each exception tied to the stage that ends it, and shrinking	The list beside the staged plan
The count over time	Rebuilt when an auditor or a scan asks	Falling with each stage	Reported at every review

The starting points above are what the public cases show and 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 healthcare organisation.

How We Work With You

1. We listen: a free Reliability Review. A first conversation about the old machines, the applications on them, and what is waiting on the answer. 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. 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, 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. Where a module touches clinical work, accepting it is your clinicians’ decision.
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.

When the last module has moved, switching the old machine off is your team’s decision. The older technologies we read include VB6, Delphi, AngularJS, PHP 4 to 8, Java 8, .NET Framework and classic ASP. We do not work on packaged health record products, medical devices or plant control systems.

What changes for the business:

Role	What they gain
CEO	The board sees which services rest on machines nobody fixes, with a plan beside each, before an incident shows it.
CTO or CIO	A written record of what each old application does and what it needs from the machine under it. Moving it stops being a gamble.
CFO	The old-server problem becomes a list of named applications, each one something that can be priced.
COO	Operations knows which desks and departments lean on each old machine, and can plan around a move.
CISO	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
One European national health service had tens of thousands of machines on an operating system that was out of support.	Our part is narrower than this case. We do not upgrade or replace machines, and we do not secure them. We write down and rebuild the applications that keep such machines in use, so the organisation’s own team can retire them.

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 with the application, because that is what keeps the old machine in the room.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →