When Replacing the Old System Is the Riskiest Thing a Hospital Can Do

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 government health department replacing a record system more than 30 years old with a packaged product, set beside a vendor’s account of an old healthcare system’s size and India’s digital-health requirements
Size band	The department: very large. Our reader: a mid-size hospital group, laboratory chain or pharma company
Region	The department: the United States. The digital-health requirements: India
The decision at stake	How to replace an old system that a working hospital depends on every day, when nobody has a full record of what it does
The public outcome	GAO reported in February 2025 that VA announced in April 2023 it would halt deployments to further sites, after five sites; that VA identified 14 critical patient safety issues requiring development or enhancement work; and that VA obligated about 12.71 billion dollars from fiscal 2018 to the third quarter of fiscal 2024.
Why it matters to a mid-size health organisation	Our reading, not a measured finding, is that replacement is deferred because no single go-live day can be found in a hospital that never closes. The question is whether the replacement can be planned so that no single day carries the whole changeover.

2. The Business Problem, in the Buyer’s Words

“Everyone on the committee agrees the old system has to go. It is slow, two people understand it, and its maker stopped fixing what it runs on years ago. But every time we get close, someone asks which day we would switch over, and nobody can name one. The emergency department never closes. The estimate has been revised twice. And meanwhile the digital team’s plan for connected records waits, because it needs the old system to change.”

These words are imagined. They describe the decision as the research shows it, not a real conversation.

The organisation is caught between a system it cannot keep and a replacement it cannot see a way through. Deferring looks cheaper every year, and the work that depends on the replacement waits.

3. What We Found

Method. We went through the public record on replacing old health systems: a US government audit of a national record-system replacement, a vendor’s account of an old healthcare system’s size, a survey of frontline healthcare staff, and India’s digital-health direction and incentive, from 2025 and 2026.

One national replacement, halted part-way. The US Department of Veterans Affairs is replacing its health record system with a packaged product.

What	Public record (GAO-25-108091, February 2025)
The old system	”has been in operation for more than 30 years, is costly to maintain”
The halt	April 2023: VA announced it would halt deployments to further sites, after five sites
Issues identified	VA “identified 14 critical patient safety issues requiring development or enhancement work”
Money obligated	About 12.71 billion dollars, fiscal 2018 to the third quarter of fiscal 2024

How large an old system can be. One US healthcare organisation’s old administration system, described in a vendor’s case study, was built on thousands of old terminal screens, many unchanged for decades. An earlier, conventional modernisation effort had converted only a small share of its applications. IOanyT does not work in COBOL; the figure is used only for the scale.

Staying has its own cost. In a vendor-sponsored 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.

What waits on the old system 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)” in their hospitals, and published lists of non-compliant medical colleges. 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.

Our reading of why replacements stall. These four are our reasoning from the record above. None is the auditor’s or a regulator’s finding.

1. Nobody has a written record of what the old system does, so the new one is specified from memory.
2. Everything changes on one date, and a hospital has no quiet day on which to absorb it.
3. The price is set before the system has been read, so each discovery arrives as a revised estimate.
4. Nobody can show, function by function, that the new system does what the old one did.

4. The Options a Firm in This Position Had

Option	When it fits	What it risks	Our view
Defer, and keep paying to run the old system	The system is stable and a firm replacement date is set	Knowledge leaves, running costs continue, and the new work waits	Right only with a date to end it
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; gaps are found while the hospital is open	We would advise against this for an old, undocumented system that a working hospital uses every day
Wrap the old system: new screens or connections around an untouched core	The core is sound and only the outside needs to change	The core still ages, and each new piece depends on it	Can buy time for one connection; not a replacement
Write down what the system does, then replace it one module at a time with the old system still running	The system was built for the organisation, changed for years, and used every day	Two systems side by side for a time; a longer calendar; hours from clinicians	Our recommendation

5. Our Recommendation, and the Decision It Asks of the Board

For the applications a health organisation built or had built for it (registration, billing, laboratory and pharmacy applications, portals, reporting and in-house record systems): write down what the old system does, from the system itself, before any price is set. Then replace it one module at a time while the old system keeps running, starting with the modules the planned digital-health work needs first. Each module is checked function by function and accepted by named people; where it touches clinical work, by the organisation’s own clinicians. The old system stays in the hands of the organisation’s own team or vendor until its last module has moved. For a packaged health record product, the choice is different, and implementing one is not IOanyT’s work.

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
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
Functions linked and compared	Tests against an incomplete document	Every old function linked to its replacement and compared	The traceability matrix for each module
Modules accepted	One sign-off for the whole system	Each module accepted by named people; where it touches clinical work, by the organisation’s clinicians	Signed acceptance for each module
Share of the old system still running	All of it until go-live, then none	Falling module by module, with the old system there until each module is accepted	Reported at every review

7. How IOanyT Would Work

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 study 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.
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. 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.
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.

8. What the Client Would Own

• The map and the specification: what the old system 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 replace or implement packaged health record products, which is what the named case involved. Its part is far narrower: applications an organisation built or had built.
• IOanyT does not work on medical devices or their software, or pharma plant control systems, and does not claim COBOL, RPG, MUMPS or mainframe skills.
• IOanyT does not keep the old system running or secure while it is being replaced. The client’s own team or vendor does that.
• IOanyT is not a clinical safety assessor. Clinical acceptance of any module, and every decision on a clinical rule, is the organisation’s own, made by its clinicians.
• Nothing here is a promise that a replacement will go without problems, or that IOanyT’s work protects patients or keeps care running.
• 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.
• 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
GAO-25-108091, 24 February 2025	US Department of Veterans Affairs: the old system, the halt, the 14 issues, money obligated
A vendor’s case study	The unnamed organisation with thousands of screens
News report of a vendor’s survey, 2025	Frontline staff survey
Medical Dialogues, 18 July 2026	The National Medical Commission’s direction
PIB backgrounder, 6 July 2026	The Digital Health Incentive Scheme

IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. We plan a replacement so that no single day carries the hospital, and every module is accepted before the next begins.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →