The People Who Understand Your Oldest System Are Retiring. Here Is What the Public Record Shows.
We went through the public record on scarce skills for old government systems. The language is not the whole problem: what the last experts know is written nowhere. Here is what we found, the options, and the benchmark we would set.
The establishment section has circulated the retirement list for the year. The third name on it belongs to the officer who has looked after the pension application since the day it was commissioned.
That was twenty-two years ago. One other person understands the application: a contractor whose agreement ends in June.
The head of IT reads the list twice. Pensions run every month. Nobody has asked who will know what to do if the July run fails.
The paradox: Everyone knows the date these people leave, and nobody has a plan for what leaves with them.
What We Found
For this article we went through the public record on scarce skills for old government systems: the US national auditor’s 2025 report on the most critical federal legacy systems and press coverage of it, the UK government’s own review of its digital services (January 2025), trade-press reporting in 2025 on the UK tax authority, two vendors’ surveys of large enterprises that run mainframes, and one maker’s support statement for an older development tool.
First, two limits. Every public case we found concerns COBOL and assembly language in national bodies. IOanyT does not read COBOL or assembly language, and we do not work on mainframes: a body whose system is written in those needs another firm for that system. We use the cases for what they show about knowledge held by a few people. And we found no Indian public body, and no body of our readers’ size, on this issue.
The auditor counts the people, not only the code. Press coverage of the US national auditor’s 2025 report quoted it on selected Treasury systems, which use “Common Business Oriented Language, or COBOL, and Assembly Language Code”: “programming languages that have a dwindling number of people available with the skills needed to support them”. The same coverage reported that, of the 10 most critical legacy systems the auditor had named in 2019, three modernisations had been completed six years later.
Old languages are common among the most critical systems. The auditor’s own report found that 8 of the 11 most critical federal legacy systems, “about 23 to 60 years old”, use outdated languages.
Where the skill is scarce, a government buys it from outside. The UK government’s own review says that its tax authority “relies heavily on costly third-party services to maintain outdated systems”. The review gives no figure, and neither do we. We make no comment on the authority or on any contractor: the people who still hold these skills are why such systems still work.
The shortage is wider than government. In one vendor’s survey of 500 senior leaders at large enterprises that run mainframes, “Seventy percent of respondents have had difficulties finding the right skills”; the skills meant include cloud, security and AI. Another vendor’s article reports that “One-third said they were lacking skills in programming languages such as Cobol, RPG and CICS”, with no sample size. None of those languages is one we read.
The tools age too, including in technologies we do read. The maker of VB6 has not supported its development tool since 8 April 2008, and “strongly recommends that you replace your applications with modern technology”. Programs written in VB6 still run, on a runtime the maker still supports on current Windows.
Our reading: the language is not the whole problem. An engineer who knows a language still does not know a particular application, its rules and why each was made. That knowledge sits with a few people, written nowhere, because they were always there to ask.
What our review does not show: We found no Indian public body and no body of our readers’ size with this problem on the record, and nothing from the Middle East. Both government cases are national bodies in the US and the UK, and both concern COBOL and assembly language, which we do not read. The two surveys cover large enterprises that run mainframes, not public bodies. We found no figure for officers’ ages, retirements, contractor rates or the time it takes to fill a post or train a successor; every such number in the scene is imagined. That the scarce thing is the knowledge of one application is our reasoning, not a finding of any source. We make no comment on any government’s or contractor’s choices.
What Leaves With the Last People Who Know
A body with one or two people who understand a system is not careless; those people are why it still works. Our reading is that the body is exposed in four ways no report shows.
A public service rests on a date. The retirement, the transfer or the end of the contract is known years ahead. The plan for what leaves with that person is not.
Answers are given, and not kept. A question is answered at a desk in a minute, and nobody writes the answer down.
Every newcomer starts from nothing. Each transferred officer’s successor learns from the same one or two people.
Nothing can be decided about the system’s future. Keeping, rebuilding or handing the work on each needs a description of what the system does, and it lives in one memory.
The gap we see: most bodies we write for know who understands their oldest applications, and when those people leave. Few have what those people know in writing, checked by them and owned by the body. A body that has it can let people retire on time. A body that does not asks the same people to stay, every year.
This is our reading of the evidence. It is not a measured market figure.
Four Ways to Keep What They Know, Weighed
There are four real options. Each one is right for somebody.
| Option | When it fits | What it risks |
|---|---|---|
| Ask the expert to stay: an extension of service, or re-engagement after retirement | The system will be retired soon, and the expert is willing | It buys a year, not a plan, and rests on one person’s goodwill. The rules on it are the body’s own; we give no advice on them |
| Pair a successor with the expert | The body has an officer to spare, and the expert has time to teach | Months of the expert’s time; the knowledge moves from one head to another, still unwritten |
| Ask the expert to write a handover note | Time is short, and the expert is willing to write | Written from memory, under pressure; it covers what the writer remembers, not all the system does |
| An assessment that reads the application, writes down what it does, and has the expert confirm it while in post | The application is in a technology the assessor can read, and the expert has some hours to review | It costs money and the expert’s hours before anything changes, and it turns up rules nobody can explain |
Our recommendation: write the application down while the people who know it are still in post. Read what it does from the system itself, then ask the experts to confirm each rule and say why it exists; reviewing a draft takes less of their time than teaching. Then decide, on paper, whether to keep, rebuild or hand the work on. For an application in COBOL or assembly language, or on a mainframe, this is work for another firm. We supply no staff, contractors or training, and the body’s own people or its present contractor keep the system running meanwhile.
Where You Are Now, and Where You Should Be
Before any work begins we set a benchmark: a few measures taken from your own systems, each with a target. For this issue it would look like this.
| Measure | Typical starting point | Where it should be | How it is checked |
|---|---|---|---|
| What the application does | Known to one or two people | Written down, rule by rule, and confirmed by the body’s own experts | The specification |
| Why each rule exists | In the experts’ memory | Recorded beside the rule, in the experts’ own words | The specification |
| Applications that depend on one person | Not recorded | Each one listed, with the date that person leaves | The risk register |
| Rules nobody can explain | Unknown until something fails | Listed, each with an owner and a decision | The risk register |
| Who owns the record | Nobody, or a supplier | The body, which can show it to any supplier | The specification, handed over |
The starting points above are 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 public body.
How We Work With You
- We listen: a free Reliability Review. A first conversation about the application, the people who know it and when they leave. 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 article is an example of that work.
- We read the system and propose: the Legacy System Specification Assessment. Here the system is an application in a technology we read: VB6, Delphi, AngularJS, PHP 4 to 8, Java 8, or .NET Framework and classic ASP. It is not a COBOL or assembly language system, or a mainframe. 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.
- If you approve, we build. We replace a system one module at a time while the old one keeps running, onto technology that is still supported. 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.
- 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.
What we do not do: we do not read or work in COBOL or assembly language, and we do not work on mainframes; a body whose system is written in those needs another firm for that system. We supply no staff or contractors, we do not replace a retiring officer, and we offer no training as a service. We do not keep the old system running; the body’s own people or its present contractor do. We give no advice on service, recruitment or procurement rules, and we do not say we are empanelled with any government. We have no published case of this work for a public body.
What changes for the business:
| Role | What they gain |
|---|---|
| Head of department | A retirement or a transfer stops being a risk to a public service. The department holds the knowledge, not one officer. |
| Head of procurement | The handover file for the next contract already exists, and it belongs to the department. |
| Head of IT | What the team knows stops being lost with each departure. It is written down and kept. |
| Head of finance | Less chance of paying for emergency help on the day someone leaves. |
| Head of personnel | Retirements and transfers from these posts can be planned like any others. Nobody has to be asked to stay on. |
The cases in this article, and what IOanyT does about that kind of problem:
| The case | What IOanyT does |
|---|---|
| The US national auditor: Treasury systems in COBOL and assembly language, with “a dwindling number of people available with the skills needed to support them”; 8 of the 11 most critical systems in outdated languages. | We do not read those languages; a body with such a system needs another firm for it. For an application in a technology we read, we write down what it does while the body’s own experts can confirm it. |
| The UK government’s own review: its tax authority “relies heavily on costly third-party services to maintain outdated systems”. | We make no comment on the authority or its contractors, and we supply no contractors. For a body’s own applications, we produce a specification the body owns. |
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 your last experts know, while they are still there to say it is right.
Sources
In this issue
Scarce skills for cobol and assembly
Research note 2
A Public Service Should Not Rest on a Retirement Date. Four Ways Forward, Weighed.
You cannot tender for a skill nobody has. Four ways forward weighed, from extensions of service to writing the system down while its experts are still in post.
Research note 3
Every Question About Your Old System Waits for One Person. Here Is the Benchmark We Would Set.
In many public bodies every question about an old system goes to one person. Four ways to answer them, weighed, and the benchmark we would agree first.
Issue study
A Dwindling Number of People
An issue study from the public record: the US auditor's critical systems, the UK's review of its tax authority, a public body's options and our benchmark.