A Hospital Has No Quiet Weekend. What the Record Says About Replacing Old Systems.

The item has been on the management committee’s agenda for four years: replace the hospital’s old system.

Nobody defends the old one. It is slow, two people understand it, and it runs on technology its maker stopped fixing long ago.

Then someone asks the question that ends the discussion every year. On which day do we switch over? The emergency department does not close. Neither does the intensive care unit. There is no quiet weekend.

What We Found

Before we suggest anything to a health organisation, we study its sector. For this article we went through the public record on replacing old health systems: a US government audit of a national health record replacement (GAO, February 2025) and a survey of frontline healthcare staff reported in late 2025.

Four findings stand out.

Old health systems last a very long time, and they cost money to keep. The US Department of Veterans Affairs is replacing the record system it relies on. Its auditor describes that system as one that “has been in operation for more than 30 years, is costly to maintain”. It is far larger than anything our readers run.

A replacement can stop part-way. The US auditor (GAO, February 2025) records that in April 2023, after the new system had been deployed at five sites, VA announced it would halt deployments to further sites, and that VA “identified 14 critical patient safety issues requiring development or enhancement work”. The record we read does not say what those issues were, and we do not guess.

The sums committed were large. Its auditor (GAO, February 2025) records that from fiscal 2018 to the third quarter of fiscal 2024, VA reported that it obligated a total of about 12.71 billion dollars on the programme.

Staying is not free either. In one survey of more than a thousand frontline healthcare staff in the US, the UK and Ireland, reported in late 2025, almost all said inefficient technology was causing patient care and safety issues, and about a quarter named dependence on outdated and legacy systems among the main problems. The survey was paid for by a vendor.

The record does not explain why organisations defer. Our reading is that the fear is of the single day on which everything changes, in a place that never stops.

What Waits While the Replacement Is Deferred

A deferred replacement is usually counted as money not yet spent. Our reading is that it carries costs of its own.

The first is knowledge. Each year the old system stays, more of the people who understood it leave.

The second is the cost of keeping it. The old system takes budget every year and gives back nothing new.

The third is what cannot be built. A connected patient record, a link to a laboratory partner, a faster insurer claim: each has to pass through the old system nobody wants to touch while the replacement is “next year”.

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

Four Ways Forward, Weighed

A hospital in this position has four real options. Each one is right for somebody.

Option	When it fits	What it risks
Defer, and keep paying to run the old system	The system is stable and a firm date to replace it is already set	Knowledge leaves, running costs continue, and new work waits
Replace everything in one go, on one date	The system is small, well documented and used by few departments	Every department changes on one morning, and a gap is found while the hospital is open
Wrap the old system: build new screens or connections around it, core untouched	The core is sound and only the outside needs to change	The core still ages, and each new piece depends on it
Replace it in stages, one module at a time, with the old system still running	The system was built for the hospital, changed for years, and used every day	Two systems run side by side for a time, and the calendar is longer

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 system, each with a target.

Measure	Typical starting point	Where it should be	How it is checked
Functions written down before pricing	None; requirements are written from memory	Every function in scope has its own numbered line before any price is set	The specification is compared with the system
The basis for the estimate	A list of modules and a demonstration	A written specification and a risk register, with a price for each stage	The staged plan and quote
The largest single go-live	Every department, on one morning	One module	The staged plan
Modules accepted	One sign-off for the whole system, at go-live	Each module accepted on its own by named people; where it touches clinical work, by your clinicians	Signed acceptance for each module, with its traceability matrix
Share of the old system still running	All of it until go-live, then none of it	Falling module by module, with the old system still there until each module is accepted	Reported at every review, against the staged plan

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 system, the replacement that keeps being deferred, and what is waiting on 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 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. 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.

We do not keep the old system running or secure in the meantime; your own team or vendor does. We are not a clinical safety assessor: we give your clinicians the evidence for each module, and the judgement is theirs. 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 replacement deferred for years can begin, because no single day puts the hospital’s services at stake.
CTO or CIO	A module that is not ready is not switched on, and the old system is still there. Problems are fixed before a module goes live, not after.
CFO	Money is released stage by stage, and a stage that disappoints can be paused without writing off the whole programme.
COO	Departments change one at a time, at a time that suits them, with staffing planned around each.
Medical head	Clinicians meet one change at a time, and where a module touches clinical work, accepting it is their decision.

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

The case	What IOanyT does
According to its auditor (GAO, February 2025), the US Department of Veterans Affairs halted its new record system’s roll-out to further sites after five sites, identified 14 critical patient safety issues requiring development or enhancement work, and had obligated about 12.71 billion dollars by mid-2024.	Our part is far narrower. That programme put in a packaged health record product, which we do not implement. For applications an organisation built or had built, we write down what the old system does, then replace it one module at a time while it keeps running, and the organisation’s own people accept each module.

IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. A hospital never gets a quiet weekend, so we plan replacements that never need one.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →