The Scarce Skill in an Old Hospital System Is Reading It. That Can Be Done Once.

The hospital’s system was written nineteen years ago by a young member of the IT department. It began as a billing program. Over the years it grew to cover registration, the wards, the pharmacy and the stores.

The same person still looks after it. Every change in nineteen years has gone through those hands. When a department head wants something new, they walk to that desk and ask.

Last week that person mentioned, in passing, a plan to retire in March.

What We Found

Before we suggest anything to a hospital group, a laboratory chain or a pharma company, we study its sector. For this article we went through the public record on scarce skills for old systems: two industry surveys of large enterprises, the maker’s support statement for one of the most common development tools of its day, a US government audit of a health record system, and a vendor’s description of an unnamed health organisation’s old system, most of it from 2025 and 2026.

Skills for old technology are hard to find, even for large enterprises. In a survey of several hundred senior leaders at enterprises that run mainframes, more than two in three said they had had difficulties finding the right skills. In another survey, about a third reported gaps in skills for older programming languages such as COBOL, RPG and CICS. Both are cross-sector, and both are about mainframes, a technology IOanyT does not work on. We cite them because they are the nearest evidence there is.

The tools of many in-house systems were retired long ago. The maker of VB6, one of the most common development tools of its day, stopped supporting it on 8 April 2008. Its support statement says it “strongly recommends that you replace your applications with modern technology”. Programs built with it still run on current Windows; what stopped is support for building and changing them.

Health record systems stay in service for decades. In a February 2025 report, the US government’s auditor describes the record system the US Department of Veterans Affairs relies on as one that “has been in operation for more than 30 years, is costly to maintain”. The department is replacing it. This is a national system, far larger than anything our readers run.

And old health systems hold a great deal. One US healthcare organisation, described in a vendor’s case study, had an administration system built in COBOL on thousands of old terminal screens, many unchanged for decades. IOanyT does not work in COBOL. We cite it to show how much an old health system can contain.

Our reading of these four findings: the scarce skill is not changing an old system. The scarce skill is reading it: code in a technology few people now learn, written in one person’s style, with no notes. That is why a hospital’s own system comes to rest on one person. We think the same pattern holds for the VB6 and Delphi programs found in many in-house systems, though no source we found measures it.

What Waits While Only One Person Can Read It

Scarce skills are usually discussed as a hiring problem. Our reading is that the larger cost is what queues behind the one person who can read the system.

Changes wait. A department’s request joins a list that only one person can work through. When that person is on leave, it waits longer.

Answers wait. How a charge is worked out, or why the system did something, can be found only by asking.

New joiners wait. With nothing to read, they learn by sitting beside the expert, and the expert’s own work slows while they do.

And succession waits. The organisation knows who the expert is. It does not know what that person knows.

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

Three Ways to Hold On to What One Person Knows, Weighed

There are three real options. Each one is right for somebody.

Option	When it fits	What it risks
A handover in the notice period	The system is small, or is due to be switched off soon after the person leaves	Weeks are not enough to pass on years. What gets covered is the daily routine, not why the system is as it is
Ask the expert to write it all down	The expert has protected time and wants to do it	The expert is also the only person keeping the system running. Much of what they know is no longer conscious, and comes back only when a particular question is asked
Have others read the system and write down what it does, the expert confirms each part and explains why, then move it module by module to technology people can be hired for	The system is old, built in-house, used every day, and its expert is still there	It asks for the expert’s time now, not later. Reading the system will turn up things nobody can explain. The move runs over several stages

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

For this issue, the benchmark would look like this.

Measure	Typical starting point	Where it should be	How it is checked
People who can explain each part of the system	One, for most of it	More than one for every part in use, working from a written record	Who confirmed each part of the specification
Share of the system written down and confirmed	None, or old notes nobody trusts	Every part in use, each confirmed by your own experts	The specification
Time left with the expert when the record is finished	None planned; the notice period	Months, not weeks	The staged plan beside the expert’s own plans
Modules on technology you can hire for	None	Rising with each accepted module	Signed acceptance for each module

The starting points above are what the public record suggests 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 system, the people who understand it, and what is 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.
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. Here, your own experts include the person who knows the system best. 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, onto technology in wide use that your organisation can hire for. 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.

While the modules move, your own expert and team keep the old system running, as they do today. The older technologies we read include VB6, Delphi, AngularJS, PHP 4 to 8, Java 8, .NET Framework and classic ASP. We do not claim COBOL, RPG, MUMPS or mainframe skills, and we do not work on packaged health record products.

What changes for the business:

Role	What they gain
CEO	The hospital’s main system no longer rests on one named person, and a retirement becomes a handover.
CTO or CIO	A written record to work from, made while there is still someone to ask why.
CFO	A planned piece of work replaces an emergency that would have come on the day someone left.
COO	Departments are not exposed each time the one expert is on leave.
CHRO	Succession for the system’s experts becomes possible, and they can retire or take leave without the hospital holding its breath.

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

The case	What IOanyT does
The US government’s auditor reported in February 2025 that the US Department of Veterans Affairs relies on a record system that has been in operation for more than 30 years and is costly to maintain.	Our part is far smaller than this case, and we do not work on health record systems of that kind or in their technology. For the applications a health organisation built or had built for it, in the technologies we read, we write down what the system does and move it module by module.

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 by writing down what one person knows, while that person is still there to confirm it.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →