When the Application Keeps the Old Machine
A study of unsupported operating systems in healthcare from the public record: a national health service's tens of thousands of old machines, the published dates, what India's digital-health programme now asks, the options, what we would advise against, and the benchmark we would set.
1. At a Glance
Issue study · From the public record. None of the organisations named here was an IOanyT client, and IOanyT had no part in the events described. Everything about them comes from the public record.
| Organisation type | A national health service that carried tens of thousands of machines past their maker’s support date, set beside published support dates and India’s digital-health requirements |
| Size band | The health service: very large. Our reader: a mid-size hospital group, laboratory chain or pharma company |
| Region | The health service: Europe. The digital-health requirements: India |
| The decision at stake | What to do with machines whose maker no longer fixes them, when an application on each will not run on anything newer |
| The public outcome | Tens of thousands of machines were on an unsupported operating system when ransomware struck in 2021. More than half of its acute hospitals cancelled services, and restoring almost all of its applications took months. An older case |
| Why it matters to a mid-size health organisation | Most run a few machines past the date for the same reason. The question is whether the applications on them move on a plan, or stay until something forces the issue |
2. The Business Problem, in the Buyer’s Words
“Every year the security team brings me the same exceptions: servers we cannot upgrade, because the billing and laboratory applications only run on the old versions. We tried once and the claims stopped printing. Now the digital team wants connected records and faster insurer claims, and both need those same applications to change. I know the machines have to go. I just cannot see where to start.”
These words are imagined. They describe the decision as the research shows it, not a real conversation.
The organisation is caught between machines nobody fixes and applications nobody dares to move. Renewing the exception looks cheaper every year, and the new work waits.
3. What We Found
Method. We went through the public record on unsupported operating systems in healthcare: reporting of one national health service’s ransomware attack and the review that followed, a journal article on an Indian hospital’s attack, the maker’s published support dates, India’s digital-health direction and incentive, the insurance regulator’s time limits, and a US government audit of a record-system replacement, from 2020 to 2026.
Tens of thousands of machines past the date. In 2021 one European national health service was hit by ransomware.
| What | Public record |
|---|---|
| Machines on an unsupported operating system | Tens of thousands of machines running Windows 7, out of support since January 2020 |
| How the systems were described | Older systems with known security weaknesses |
| How much was affected | Most of the IT estate |
| Effect on services | More than half of its acute hospitals cancelled services |
| Recovery | Several months to decrypt all servers and restore almost all applications |
| Cost | Reported as likely to reach hundreds of millions of euros |
Recovery in India is also measured in weeks. The attack on a large public hospital in India in 2022 took dozens of its servers out of use, left its hospital information system unavailable for weeks, and sent staff back to paper records. An older case; the record does not say what the servers ran.
The dates are published, and the paid years end 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. Windows Server 2016 follows on 12 January 2027. On Windows Server 2008 without its second service pack, the current standard for encrypted connections is “Not supported”.
What waits on the old applications in India. On 17 July 2026 the National Medical Commission directed medical colleges to implement an “Ayushman Bharat Digital Mission (ABDM)-compliant Health Management Information System (HMIS)” “immediately”, and published lists of colleges that had not complied. Under the Digital Health Incentive Scheme, hospitals “earn cash incentives for creating interoperable digital health records”, and the scheme had paid hospitals more than 107 crore rupees by 18 June 2026. The insurance regulator requires insurers to “decide on cashless authorisation requests within one hour”.
Why replacing everything at once is feared. A US Government Accountability Office report of February 2025 found that the US Department of Veterans Affairs is replacing a record system that “has been in operation for more than 30 years”. It paused the roll-out in April 2023 after five sites, with about 12.71 billion dollars committed by mid-2024.
Our reading of why the machines stay. These four are our reasoning from the cases above. None is a review’s or a regulator’s finding.
- The application was built for one version of the operating system, and stops on anything newer.
- Nobody has a written record of what the application does or needs, so nobody can predict what a move would break.
- The only move anyone attempts is all at once, and when it fails the conclusion is that it cannot be done.
- Renewing the exception takes a signature; removing the machine takes a project.
What this record does not show. The national health service record does not say the old machines caused the attack, and it is a very large organisation, not a mid-size one. The Indian hospital’s record does not say what its servers ran. The National Medical Commission’s direction binds medical colleges and is about connected records, not unsupported software; the incentive is a reward, not a penalty; the insurers’ time limits bind insurers. No Indian regulator was found to have ordered hospitals to remove unsupported software. We found no public case of a mid-size hospital, diagnostic chain or pharma company with this problem, and no published figure for what extended support costs.
4. The Options a Firm in This Position Had
| Option | When it fits | What it risks | Our view |
|---|---|---|---|
| Pay for extended support and keep the machine | The maker sells it, and a date to leave is set | Buys time and nothing else; ends on the maker’s date | Right only as a bridge with an end date |
| Upgrade the operating system in place | The application is known to run on the newer version | Old applications often stop; the upgrade is rolled back | Worth checking first; often not possible |
| Replace every old application at once | The applications are few, small and well understood | Every department changes on one date, with no record of what the old applications do | We would advise against this for old, undocumented applications used every day |
| Write down each application, then move it module by module onto supported technology, most exposed machines first | The applications are old, undocumented and used every day | Several stages; two systems side by side for a time | Our recommendation |
What we would have advised against: for an organisation in this position, renewing the same exceptions year after year with no date to end them, and answering an end-of-support date with a single weekend move of the whole application.
5. Our Recommendation, and the Decision It Asks of the Board
For the applications a health organisation built or had built for it (billing, registration, laboratory and pharmacy applications, portals and reporting): write down what each one does and what it needs from the machine under it, then move it module by module onto technology that is still supported, starting with the applications on the most exposed machines and those the planned digital-health work needs first. The old application keeps running until each module is accepted. Extended support, where it is sold, is a bridge with an end date. The old machines stay protected by the organisation’s own team or vendor until their applications have moved.
The decision it asks of the board: approve a fixed-price assessment now, separately from the next renewal. Then approve each stage on its own evidence, with the freedom to pause after any accepted module. The board stops renewing the same exceptions each year and starts approving a plan with dates the organisation has set.
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 organisation’s own figures, taken in the first review.
| 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 |
| A plan against each machine | ”Upgrade planned” or “exception renewed” | A stage, in order, against the application on it | The staged plan |
| Exceptions with an end date | None; each has only a next review date | Every one tied to the stage that removes it | The exception list beside the staged plan |
| The exception list | The same length, or longer, each year | Shrinking after every accepted module | Reported at every review |
| The digital-health work waiting on the old stack | Not linked to any server | Each planned piece of work listed against the application it needs | The staged plan |
| The count over time | Rebuilt when an auditor or a scan asks | Falling with each stage | Reported at every review |
7. How IOanyT Would Work
- We listen: a free Reliability Review. A first conversation about the old machines, the applications on them, and the exceptions renewed each year. 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 study is an example of that work.
- 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.
- 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. Where a module touches clinical work, accepting it is your clinicians’ decision.
- 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: what each application does, in writing and portable to any supplier.
- The risk register: what the assessment found, listed before any price is set.
- The traceability matrix: every old function linked to its replacement, with how it was checked.
- The code: the new modules are the client’s. No runtime or platform fee.
- The filled-in benchmark: each measure, where it started and where it stands.
9. What This Approach Does Not Cover
- IOanyT does not upgrade operating systems, replace servers or desktops, apply patches or sell extended support.
- IOanyT does not keep the old machines protected or running while their applications wait to move, and does not supply security controls or monitoring. The client’s own team or vendor does that. Until an application has moved, the machine under it is as exposed as before.
- Nothing here is a promise that an attack will not happen, or that IOanyT’s work protects patients or keeps care running.
- IOanyT does not work on packaged health record products, medical devices or their software, or pharma plant control systems.
- IOanyT does not offer a compliance, audit or legal service. Meeting the National Medical Commission’s direction, or any other rule, is the organisation’s own work.
- Clinical acceptance of any module is the organisation’s own decision, made by its clinicians.
- This study does not say IOanyT would have prevented the events described, or that IOanyT has done this work for a healthcare organisation.
About this study: IOanyT did not work on this case. It is drawn from published findings, cited below.
10. Sources
| Source | Used for |
|---|---|
| A technology news report, 2022 | A national health service: machines on Windows 7, share of estate affected, hospitals cancelling services |
| A healthcare security news report, 2021 | A national health service: attack date, how its systems were described, recovery, cost |
| A medical journal article, 2026 | A large public hospital in India |
| endoflife.date, Windows Server | Windows Server support dates |
| Microsoft, TLS protocol support | Encrypted connections on Windows Server 2008 |
| Medical Dialogues, 18 July 2026 | The National Medical Commission’s direction |
| PIB backgrounder, 6 July 2026 | The Digital Health Incentive Scheme |
| The Tribune, 31 May 2024 | Insurers’ time limits for cashless claims |
| GAO-25-108091, 24 February 2025 | US Department of Veterans Affairs |
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.
Read the research notes on this issue
Unsupported operating systems and servers
Research note 1
Hospitals Keep Unsupported Servers for One Reason. It Is Rarely the Server.
Hospitals keep unsupported servers because of the applications on them, not the machines. What the public record shows, four ways forward and our benchmark.
Research note 2
New Digital-Health Work Is Waiting on Servers Nobody Can Change.
Digital health records, incentives and faster insurer decisions all reach a hospital's oldest servers. What waits, four ways to answer, and our benchmark.
Research note 3
An Exception List That Only Grows Is Not a Plan. One That Shrinks Is.
On an unsupported server, a newly found flaw stays open. The benchmark we would set so a hospital's exception list shrinks, and which applications move first.