The Application Your Wards Rely On Most Is Often the Oldest. Four Ways to Answer That, Weighed.

The technology head keeps a private list. It is not on any register. It is the list of systems that keep them awake.

At the top is the application the wards use for medicines. It is the oldest thing the hospital runs. It sits on one server, on software its maker stopped fixing years ago. One person understands it.

It has never been replaced, for a simple reason. It is the one system nobody dares to disturb.

What We Found

We went through the public record on old software under health organisations’ systems, looking for two things: how long such software stays in use, and what is known about which systems care leans on.

We say one thing first, because it shapes everything below. Nothing we do will stop a system failing or being attacked. We do not keep the old system running, patch it or protect it while work goes on, and we do not decide what is clinically safe. What follows is about what a hospital can choose to change, and in what order.

Unsupported software stays under a health service for years. After the ransomware attack on one European national health service in 2021, reporting of the review that followed records that tens of thousands of its machines were running an operating system that was out of support. The same reporting gives other causes too: a phishing email, warnings that were not acted on, patching that was not effective, protection software not kept up to date, and nobody with overall responsibility for cybersecurity. We do not say the old operating system caused the attack. This is an older case, from an organisation far larger than most of our readers.

The paid years run out too. 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. Extended support for SQL Server 2016 ended on 14 July 2026; Microsoft sells paid security updates for it until July 2029. Paying for more time is possible for a while, and the maker sets when it stops.

Much of a health system’s technology is old, and it is not consistently measured. In January 2025 the UK government’s State of Digital Government Review reported, from survey responses, that around 10% to 50% of NHS trusts’ technology estates are classified as legacy, a definition that includes systems out of support from the supplier. The review says the scale of legacy “is not consistently measured”.

No record ranks systems by what care leans on. We found no public record that says which applications care depends on most, or whether those are the oldest. That is the question this article turns on, and the answer below is our reasoning as engineers: the functions closest to care were usually the first to be put on a computer, everything newer was built around them, and the easy systems are renewed first because they are safe to start.

What a Hospital Cannot Do While Its Most Relied-On Application Is Its Most Fragile

An old application is usually treated as a technology risk. Our reading is that the larger cost is three things a hospital cannot do while the application care leans on hardest is also the one nobody understands.

It cannot rank. Without a map of what each part of care rests on, the hospital cannot say which application matters most, so renewal follows convenience. The simple, separate systems are replaced, and the central one is left for later.

It cannot agree an order of return. When systems come back after a failure, someone decides what comes first. Without a ranking its clinicians have agreed, that order is argued on the day. Agreeing it is the hospital’s own work; a ranking drawn up beforehand is what it would start from.

It cannot rebuild from a record. Where nothing is written down, what the old application does lives in one person’s memory. Replacing it, or explaining it, waits on that person.

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

Four Ways to Answer a Fragile, Relied-On Application, Weighed

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

Option	When it fits	What it risks
Patch and extend support in place, done by your own team or the application’s vendor	The application is sound, and its software can still be upgraded or paid support bought	Paid support ends on the maker’s date. The application stays as hard to understand and as hard to change. It buys time, not a way out
Replace the whole system in one switch-over	The system is small and separate, and the hospital’s clinicians have judged that care can manage without it for a day	Everything care depends on in that system changes on one day. Anything missed is met by every department at once
Write the systems down only: a map and a specification, no replacement	You want to know what you have before deciding, or plan to keep the system for some years	The application stays on the same software, and as fragile. A record is not a replacement
Map the applications, have your clinicians rank them by how much care depends on each, then replace the most relied-on, most fragile first, one module at a time while the old one keeps running	The hospital runs older applications of its own that care leans on, and nobody has drawn the picture	It starts with the hardest system, so the first stage is slower and more careful than an easy project. Until a part has moved, it is as fragile as before. It needs clinicians’ time to rank and to accept

Where You Are Now, and Where You Should Be

Before the next renewal plan is approved, we would set a benchmark for it.

Measure	Typical starting point	Where it should be	How it is checked
Share of applications mapped, with their links (overnight feeds included) and an owner	None	Every application in use	The map and the risk register
Share of care-critical applications ranked by your own clinicians	None; ranked, if at all, by size or cost	Every care-critical application	The ranking, with the names of the clinicians who made it
Share of care-critical applications with a written specification you hold	None	Every care-critical application	The specification, and who confirmed each part
Care-critical applications running on software out of support	Not counted	Falling at each review	The map, checked against the makers’ published support dates, and signed acceptance for each replaced 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 healthcare organisation.

How We Work With You

1. We listen: a free Reliability Review. A first conversation about the application your wards rely on most, what it runs on, and who understands it. 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 your applications as they stand, a written specification of what each does, a risk register, a cost comparison between keeping and replacing each fragile application, and a staged plan with a fixed quote. For each application on software that gets no more fixes, it sets out what an upgrade, paid support or a rebuild would involve, and gives our recommendation; you decide. AI does a first pass, our senior engineers review it and trace it to the code, and your own experts confirm it. Here, your own experts include your clinicians, who rank the applications by how much care depends on each. 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, starting with the applications your clinicians rank highest and the map shows to be most fragile. We never do a single cutover. Your own team or vendor keeps the old system running throughout; we do not. A traceability matrix links each 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. 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.

What you need to bring, and what stays yours: senior clinicians with time to rank the applications and to accept each module; read-only access to the applications once the assessment begins; and your own team or vendor keeping the old application running, supported and protected throughout. Until a part has moved, it is exactly as fragile as before, and we do not protect it in the meantime. We do not write or judge the procedures your staff fall back on, and we make no claim about patient safety. We do not work on packaged health record products, medical devices or pharma plant control systems.

What changes for the business:

Role	What they gain
CEO	The applications care leans on most stop being the oldest ones in the building.
CTO or CIO	The applications that matter most to the wards are the first onto technology that is still supported.
COO	Departments change one at a time, and the ones most at risk are dealt with first.
Medical head	Which applications are replaced first follows the clinicians’ own ranking of what care depends on, not technical convenience.
Risk and compliance	The number of care-critical applications on software nobody fixes falls at each review.

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

The case	What IOanyT does
After the 2021 attack on one European national health service, reporting of the review records that tens of thousands of its machines were running an operating system that was out of support.	Our part is much narrower than this case. We cannot stop an attack, and we do not upgrade, patch or replace machines. We replace, in stages, the applications that keep old software in use, so the organisation’s own team can retire it.
The UK government’s review reported that around 10% to 50% of NHS trusts’ technology estates are classified as legacy.	We do not work on packaged health record products. For the applications a health organisation built or had built for it, we map which run on software out of support and replace the most relied-on first.

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 where care leans hardest, in stages, and leave the clinical judgement with your clinicians.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →