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 the one person who can read it. We went through the public record, weigh four ways to answer those questions, and set out the benchmark we would agree before the reading starts.
A newly posted officer takes charge of the section that runs the registration application. On the first morning they ask for the manual.
There is no manual. They are told to ask the senior programmer, who knows everything about it.
The senior programmer has eleven change requests waiting, and a query from audit about how one fee is calculated. The query has been pending for six weeks. The new officer’s questions join the queue.
The paradox: The more people who need to understand the system, the less time the one person who does has to explain it.
What We Found
For this article we went through the public record on old systems and the people who can read them: the US national auditor’s 2025 report on the most critical federal legacy systems, one vendor’s 2025 survey of large enterprises that run mainframes, one maker’s support statement for an older development tool, and reporting in December 2025 on a letter from US lawmakers about AI and old code.
First, the limits. The government record on this issue 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 found no Indian public body, and no body of our readers’ size, on this issue.
The most critical systems are old, and so are their languages. The US national auditor found that 8 of the 11 most critical federal legacy systems use outdated languages. Those systems are “about 23 to 60 years old”. A system that old has outlived most of the people who built it.
Finding people who can read them is hard everywhere. 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, not only the old languages, and the survey is not about public bodies.
The tools stop before the programs do. The maker of VB6, a technology we do read, has not supported its development tool since 8 April 2008, and “strongly recommends that you replace your applications with modern technology”. VB6 programs still run on a supported runtime; it is the supported way to build and change them that has gone.
A tool alone is not trusted to do the reading. Reporting in December 2025 described a letter in which eleven US lawmakers questioned a plan to use AI on the old COBOL code of their national tax agency, citing “the many known limitations with AI conversion capabilities”. We take no side on that plan, and COBOL is not a language we read. We draw one point from it: what a tool drafts from old code must be reviewed by people who can check it.
Our reading: in a body of our readers’ size, the same pattern shows up as one desk. Everything about an old application goes through the one person who can read it. Each answer is given once and kept nowhere, and every transfer brings the same questions back.
What our review does not show: We found no Indian public body and no body of our readers’ size on the record, and nothing from the Middle East. The auditor’s figures describe US federal systems, including languages and machines we do not work on. The survey covers large enterprises that run mainframes. The lawmakers’ letter is about one national agency’s plan, and we use it only for the point that people must review what AI drafts. We found no figure for how many public systems lack a written record, or for how often officers in charge of one are transferred. That questions queue at one desk is our reasoning, not a finding of any source.
What a Written Record Opens Up
The usual view is that the expert is the record, and that the answer is to keep the expert. Our reading is that once the reading is done and written down, four things open up.
Questions are answered without a queue. A section officer, an auditor or a newcomer looks up the rule first, and asks the expert only what the record does not say.
Transfers stop resetting the clock. A newly posted officer starts from the record, not from months beside one colleague.
Changes start from what the system does now. A change request is written against a documented rule, and the expert reviews it rather than explaining from memory.
The body can decide the system’s future. Keep it, rebuild it in stages or hand the work on: each choice can be priced from the same written record.
The gap we see: most bodies we write for have one person, or two, through whom every question about an old application passes. Few have the reading done once, checked by that person, and owned by the body. A body that has it can measure where it stands against a benchmark, and show progress.
This is our reading of the evidence. It is not a measured market figure.
Four Ways to Answer Questions About an Old System, Weighed
There are four real options. Each one is right for somebody.
| Option | When it fits | What it risks |
|---|---|---|
| Keep asking the expert | Questions are few, and the expert is staying | The expert becomes a help desk; answers are kept nowhere, and the arrangement ends the day they leave |
| A notes file kept by the section, added to as questions come | The section has someone to keep it, and the application changes little | It grows from whatever was asked, not from what the system does, and nobody checks it against the code |
| A full manual written once, from memory, by the expert | The expert has months to spare | It takes the expert away from the work, and it records what they remember, not what the code does |
| A specification read from the code, confirmed by the expert, with every single-person dependency listed in a risk register | The application is in a technology the assessor can read, and the expert has hours to review | It costs money and the expert’s time before anything changes, and it turns up rules nobody can explain, each of which needs a decision |
Our recommendation: do the reading once, from the code, and have the expert confirm it. AI does a first pass, our senior engineers review it and trace it to the code, and your own experts confirm it. Nothing enters the record on a tool’s word alone. Then measure the body against the benchmark below. For a system written in COBOL or assembly language, or running on a mainframe, this is work for another firm: we do not read those. Keeping the record current as the system changes is the body’s own team’s work, or part of a later stage if the body chooses one.
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 |
|---|---|---|---|
| Rules written down | Few or none; held in one or two people’s memory | Each rule of the application written in plain language and confirmed by the body’s own experts | The specification |
| Single-person dependencies | Not recorded anywhere | Each one listed, with what depends on that person and when they leave | The risk register |
| Questions answerable without one desk | Every question waits for one person | A question about what the system does can be answered from the record; the expert is asked only what it does not say | The specification, checked against recent questions |
| Rules nobody can explain | Unknown | 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 |
| Each rebuilt module, if the body rebuilds | Not applicable until a stage is approved | Every old function linked to its replacement | The traceability matrix |
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, who answers questions about it and what waits. 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. 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, 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 have published no offer for AI run on a body’s own servers or on a government cloud. 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 question from the minister, the auditor or the public about how the system decides something is answered from a document, without waiting for one person. |
| Head of procurement | Every bidder is given the same written record, so their bids can be compared. |
| Head of IT | A change starts from a document. The expert reviews and decides, and no longer explains everything from memory. |
| Head of finance | One piece of work replaces a cost that came back with every new joiner and every new contractor. |
| Head of personnel | A new joiner or a transferred officer starts from a written record, not from months beside one colleague. |
The cases in this article, and what IOanyT does about that kind of problem:
| The case | What IOanyT does |
|---|---|
| The US national auditor: 8 of the 11 most critical federal legacy systems use outdated languages; the systems are “about 23 to 60 years old”. | Those systems include languages and machines we do not work on, and we make no comment on any agency. For an application in a technology we read, we do the reading once and write it in plain language the body owns. |
| Eleven US lawmakers questioned a plan to use AI on old COBOL code, citing “the many known limitations with AI conversion capabilities”. | We take no side, and COBOL is not a language we read. In our own work AI only drafts: our senior engineers review it and trace it to the code, and your own experts confirm it. |
IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. We do the reading once, have your expert confirm it, and measure the body against a benchmark set before we start.
Sources
In this issue
Scarce skills for cobol and assembly
Research note 1
The People Who Understand Your Oldest System Are Retiring. Here Is What the Public Record Shows.
The people who understand government's oldest systems are retiring, and what they know is written nowhere. What the public record shows, options, our benchmark.
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.
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.