When the Old System Is the Only Way Into the Archive
A study of hospital records held in a form only an old system can read: what the thin public record shows, what India's digital-health programme now rewards, 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 | No named hospital, laboratory or pharma company with this problem appears in the public record. This study sets the few public facts that bear on it (a decades-old government record system, an organisation whose data sits behind screens, a supplier’s old migration servers, the published needs of newer tools) beside India’s digital-health direction and incentive |
| Size band | The organisations in the record: very large. Our reader: a mid-size hospital group, laboratory chain or pharma company |
| Region | The record: mostly the US. The digital-health direction and incentive: India |
| The decision at stake | What to do with years of records held in a form only the old system can read, when the old system is kept running only to reach them |
| The public outcome | No public outcome exists for this issue in healthcare. The nearest public facts: a record system “in operation for more than 30 years”; an administration system built on thousands of screens; old migration servers reached by an attacker before they were moved |
| Why it matters to a mid-size health organisation | Most that have replaced a system still keep the old one for its records. The question is whether those records are made readable and moved on a plan, or stay locked until the old machine fails |
2. The Business Problem, in the Buyer’s Words
“We moved to the new system six years ago and brought two years of history across. The rest is still in the old one. It runs on a server nobody wants to touch, and one person in IT knows how to find things in it. Now the digital team wants connected records, a reporting tool and maybe an AI assistant, and every one of them wants our history. Each year someone proposes moving it and switching the old system off, and each year someone asks what happens if something is lost.”
These words are imagined. They describe the decision as the research shows it, not a real conversation.
The organisation has kept every record it made and cannot use most of them. The old system cannot go, because it is the only way in, and the new work waits.
3. What We Found
Method. We went through the public record on health data held in formats only an old system can read: a US government audit of a record system, a vendor’s case study of a healthcare administration system, a trade-press account of an attack on a health record supplier, a cross-sector survey on why old systems stay, a cloud provider’s documentation of the data its AI service reads, the maker’s database support dates, India’s digital-health direction and incentive, and an adviser’s timeline for India’s data protection rules, from 2022 to 2026.
The first finding is what is missing. We found no healthcare evidence on data locked in old formats: no named case, no survey and no figure. The facts below are cross-sector or come from other parts of healthcare, and each is used for one narrow point.
| What | Public record |
|---|---|
| How long one health record system can run | The record system the US Department of Veterans Affairs relies on “has been in operation for more than 30 years” |
| Data reachable only through screens | An unnamed US healthcare organisation’s administration system was built on thousands of old terminal screens, many unchanged for decades |
| Why old systems stay | In a survey of about five hundred US IT professionals across industries, half said the current system still works and about a third named data migration concerns |
| The store under the records | SQL Server 2012: extended support ended 12 July 2022, paid updates ended 8 July 2025. SQL Server 2016: extended support ended 14 July 2026 |
| Old stores left running | At a large health record supplier, an attacker used stolen login details to reach old migration servers that had not yet been moved |
| What newer tools read | One widely used cloud service for building AI assistants lists its supported source files as plain text, Markdown, web pages, Word documents, CSV, Excel and PDF files, each within a size limit; structured data stores are reached through a query engine |
What waits on the old records 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 medical colleges, including colleges “still not using ABDM-enabled HMIS software”. A government backgrounder of 6 July 2026 says that 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. One adviser’s timeline, published on 11 May 2026, says 13-14 May 2027 “is widely regarded as the ‘hard enforcement’ date” for India’s data protection rules; we give the date only.
Our reading of why the records stay locked. These four are our reasoning from the facts above. None is a regulator’s or an audit’s finding.
- Nobody has written down what the old data means. The data is in the database; its meaning is in the old program’s code and a few people’s memory.
- The old system is kept as the only way in, on an ageing database and machine.
- Moving the data is feared, and the fear is never tested, because nobody has a way to check a move.
- New tools are chosen before the data is looked at, and then cannot read it.
What this record does not show. No named healthcare organisation appears with this problem, and none of the facts is about a mid-size hospital. The screens figure is from a vendor’s undated case study; the supplier case is one vendor-written article with no year and no impact figure; the survey is cross-sector, US-only and vendor-run. The file formats are one provider’s list on the day we read it. The Commission’s direction is addressed to medical colleges, not to every hospital, and is about connected record systems, not old records; the incentive is a reward, not a penalty. No source ties either to a hospital’s old archive. We found no figure for what an archive system costs, how long an old record takes to find, or how often a migration loses data. We did not research how long medical records must be kept, who may see them, or what India’s data protection rules require, and this study says nothing about them.
4. The Options a Firm in This Position Had
| Option | When it fits | What it risks | Our view |
|---|---|---|---|
| Keep the old system running as an archive | Lookups are rare and the archive has a firm end date | The database goes out of support, the people who understand it leave, and no new tool can reach the history | Right only with an end date |
| Dump the old tables to files and switch the system off | The data is simple and its codes are already written down | Files of codes with no meaning attached; nobody can show the dump is complete | Rarely enough on its own for coded records still in use |
| Move every old record into the new system at once | The old data is small, recent and well understood | One date carries every mismatch, decided under pressure, with no way to show what arrived | We would advise against this for old, coded records still asked for |
| Write down what the old data means, then move it with each module and check each stage | The records are old, coded, and still needed | Two systems side by side for a time; clinicians and records staff must decide mismatches; some codes have no recoverable meaning | Our recommendation |
What we would have advised against: for an organisation in this position, leaving the old system running “for reference” with no end date, and buying a reporting or AI tool before anyone has looked at what the old data holds and means.
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 and reporting): write down what the old data means as part of the specification, each table, field and code, confirmed by the staff who used it, with a list of what nobody can explain. Then move the data module by module as the system is replaced, starting with what the planned work needs first, and check each stage before the next begins. Clinicians and records staff decide how old entries appear in the new record. The old system keeps running until the last stage is accepted. Only then are new tools pointed at the data, with its limits stated.
The decision it asks of the board: approve a fixed-price assessment now, separately from the next year’s archive costs and from any tool purchase. Then approve each stage on its own evidence, with the freedom to pause after any accepted module. The board stops renewing an archive with no end and starts approving a plan with a date 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 |
|---|---|---|---|
| What the old system holds, documented | Known to a few people | Each table, field and code written down, with what could not be explained listed | The specification |
| Records reachable without the old program | None | Every record in scope, in its new home | Sample lookups by records staff, old and new side by side |
| The check on each stage | ”Something might be lost” | Counts compared and samples read side by side before the next stage | Set in the benchmark, signed off by records staff after each module |
| The archive’s end date | None; “kept for reference” | A date, tied to the last stage | The staged plan |
| Data ready for a new tool | The tool shows the years since go-live | Old and new data in one documented, standard form, with its limits stated | A trial query by the organisation’s own team |
| What was moved, what was left, and why | Not recorded | A list beside the staged plan | Reviewed with records and compliance staff |
7. How IOanyT Would Work
- We listen: a free Reliability Review. A first conversation about the old system, the records it holds, and the work waiting on them. 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. 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 the 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. It shows what the system does, not that every record arrived; the record check is a line in the benchmark.
- 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 keep the old system running as an archive, and does not secure it. The client’s own team or vendor does that until the last stage is accepted.
- IOanyT gives no advice on how long records must be kept, who may see them, or what India’s data protection rules or any other rule require. It does not offer a compliance, audit or legal service. Meeting the National Medical Commission’s direction is the organisation’s own work.
- IOanyT’s published code-access terms cover code, not patient records. Who may see any real record is for the organisation and its advisers to decide.
- Moving records does not correct records that were incomplete or wrong in the old system, and some old codes have no meaning anyone can recover.
- IOanyT does not sell a reporting tool or an AI product, and has not stated that it delivers AI that runs entirely on an organisation’s own servers.
- IOanyT does not work on packaged health record products or their own data formats, medical devices or their software, or pharma plant control systems, and does not claim COBOL, RPG, MUMPS or mainframe skills.
- Clinical acceptance of any module is the organisation’s own decision, made by its clinicians. Nothing here says IOanyT’s work protects patients or keeps care running.
- This study does not say IOanyT would have prevented any event 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: age of the record system it relies on |
| A vendor’s case study | The unnamed organisation whose administration system was built on thousands of screens |
| A vendor’s survey, 2025 | Reasons for not modernising |
| Microsoft, SQL Server 2012; SQL Server 2016 | Database support dates |
| Vendor-written article in trade press, 26 May 2026 | The health record supplier’s old migration servers |
| A cloud provider’s documentation; connectors page | The data an AI service lists as supported |
| Medical Dialogues, 18 July 2026 | The National Medical Commission’s direction |
| PIB backgrounder, 6 July 2026 | The Digital Health Incentive Scheme |
| A business advisory firm’s briefing, 11 May 2026 | The date for India’s data protection rules |
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 what the old data means, because the old system can only go once someone else can read its records.
Read the research notes on this issue
Data locked in old formats
Research note 1
Hospitals Keep Every Old Record. What Goes Missing Is What the Records Mean.
Old hospital records are kept, but their meaning goes out of reach. What the public record shows, why it happens, four ways forward and a benchmark.
Research note 2
New Digital-Health Work Is Waiting on Records Only an Old System Can Read.
An old system kept running only for its records holds back reporting, AI and connected records. Four ways to handle the archive and a benchmark.
Research note 3
Data a New Tool Cannot Read Is Not Ready. Here Is the Benchmark for Ready.
A new reporting or AI tool sees only the years it can reach. The benchmark we would set before old hospital data goes to any new tool, and the path.