Data a New Tool Cannot Read Is Not Ready. Here Is the Benchmark for Ready.

The hospital has bought a reporting tool. The demonstration was impressive: admissions by month, length of stay by department, ten-year trends at the press of a button.

Six weeks after it was installed, the dashboards show two years of data. That is all the new system holds. The other thirteen years are in the old system, which the tool cannot connect to.

The supplier asks for the old data as a spreadsheet. The technology head asks IT. The old system has no export. It has screens.

What We Found

We looked at what newer tools say they can read, and at what the public record says about old data and the fear of moving it. As in the rest of this series, we found no healthcare evidence on this issue itself, and no figure for how many reporting or AI projects stall on old data. We give none.

Newer tools publish what they 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. None of that is unreasonable. It simply assumes data that has already been brought out into a standard form.

Some old data has no way out but a screen. One vendor’s case study describes a US healthcare organisation whose administration system was built on thousands of old terminal screens, many unchanged for decades. A tool cannot read a screen built for one person to look up one record.

Moving old data is feared. In one survey of about five hundred US IT professionals across industries, about a third named data migration concerns as a reason their organisations had not modernised old systems. The survey was vendor-run.

The date for India’s data protection rules is drawing near. One adviser’s timeline, published on 11 May 2026, says that 13-14 May 2027 “is widely regarded as the ‘hard enforcement’ date” for India’s data protection rules. We give the date only. We do not say what the rules require of old records or of new tools.

What Ready Data Opens Up

The reporting tool is usually seen as the project. Our reading is that the project is the data, and that getting it ready frees more than one tool.

• Every tool reads the same data. Once the old data sits in a current, documented form, a reporting tool, an analyst and an AI assistant can all use it. The next tool needs no special extract.
• Charts can be trusted. A column of codes charted without its meaning gives confident nonsense. With every code written down, and old codes matched to present ones, a ten-year trend is a trend in the work, not in how things were typed.
• The organisation knows what it holds before it shares it. With every table and field described, the people responsible can decide, field by field, what any new tool may be given.

This is our reading. It is not a measured market figure.

Three Ways to Feed a New Tool Old Data, Weighed

Option	When it fits	What it risks
Use the tool on recent data only	The questions really are about recent years	The tool never shows the history it was bought for, and the old system still cannot be switched off
Make a one-off extract by hand for each request	Requests are rare and simple	Each extract is out of date the day it is made, codes arrive unexplained, and the next question needs another
Describe the old data, bring it out in stages into a current, documented form, then point any tool at it	The old data is still asked for, by clinicians, finance or the board	It is slower than buying a tool, and for a while there is nothing new to show. Some old data will prove too incomplete to use

Where You Are Now, and Where You Should Be

This is the benchmark we would set before the first module moves, and fill in as each module is accepted.

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; each lookup needs the old system and its keeper	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 begins	Set in the benchmark, signed off by your 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 your own team, checked against the old record
What was moved, what was left, and why	Not recorded	A list beside the staged plan	Reviewed with your records and compliance staff

The starting points above are what we expect to find. In an engagement they are replaced by your own position, 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.

A small part of the finished data record might look like this.

Old data	Stage that moves it	Status
Outpatient visits, with visit-type codes explained	Stage 1: appointments module	Moved and checked; old screens retired
Laboratory results, with old test codes matched to present ones	Stage 2: laboratory module	Described; moves at stage 2
Billing history, with charge codes; two years marked incomplete	Stage 3: billing module	Described; limits stated

The rows above are an illustration, not taken from a real system.

How We Work With You, and What You Are Left With

1. We listen: a free Reliability Review. A first conversation about the old system, the data in it, and the tools that are waiting for 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.
3. We read the system and propose: the Legacy System Specification Assessment. It produces a written specification of what the system 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 above. As each module is accepted 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.

This has a price. It is slower than buying a tool. Some old records will prove incomplete or wrong, and moving them does not mend them. Some codes will have no explanation anyone can recover. The traceability matrix shows that each function moved; it does not by itself show that every record arrived, which is why the record check is its own line in the benchmark. We have not stated that we deliver AI that runs entirely on a hospital’s own servers. And we give no advice on how long records must be kept, who may see them, or what any data protection rule requires; we do not offer a compliance or legal service.

At the end you hold the specification, the matrix and the filled-in benchmark, with the old data’s limits written down. Switching the old system off is your team’s decision.

What changes for the business:

Role	What they gain
CEO	Plans for reporting, analysis and AI start from the organisation’s own history, not from a blank.
CTO or CIO	Data in a documented, standard form that new tools can be pointed at, without a one-off extraction each time.
CFO	Money spent on a new tool is not wasted on one that has nothing to read.
Medical head	Clinical audit and research can draw on years of the hospital’s own records.
Risk and compliance	The organisation knows what personal data the old records hold before any of it is given to a new tool.

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

The case	What IOanyT does
An unnamed US healthcare organisation’s administration system was built on thousands of screens, many unchanged for decades.	We do not work on COBOL or mainframes. For an organisation’s own applications in the technologies we read, we write down what the system does and stage its replacement, so its data can be brought out.

IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. The next tool you buy should have your whole history to read, with its limits written beside it.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →