Incomplete and Uneven

1. At a Glance

Issue study · From the public record. None of the bodies named here was an IOanyT client, and IOanyT had no part in the events described. All are a national government or large national bodies, far larger than the departments, municipal bodies, utilities and boards we write for. We found no public record of an Indian public body, or of a body of our readers’ size, on this issue, and no source in any country that counts how many public systems lack documentation. Each case is reported as the public record gives it, without judgement on any government, body or official.

Organisation type	The UK government’s knowledge of its own old systems, as its own review and its central digital department described it, set beside the position of a mid-size public body whose system documents date from the year the system went live
Size band	The cases: national. Our reader: a state department or directorate, a municipal corporation or council, a public utility, a board or authority, or a public-sector undertaking
Region	The cases: UK and US. The reader: anywhere
The decision at stake	How to hold a record of what a system does that the body can trust and keep: go on with the old volume, commission a documentation exercise, rely on the supplier’s knowledge, let a tool draft one, or take a specification from the code, reviewed by engineers and confirmed by the body’s own experts
The public outcome	The UK digital department’s permanent secretary wrote, in a letter reported in June 2026, that the existing “data is incomplete and uneven in coverage” on the government’s old systems; in the government’s own survey of public-sector leaders, “around 15% of survey respondents could not even estimate the size of their legacy estate”
Why it matters to a mid-size public body	If a national government’s own data on its old systems is incomplete, a smaller body is unlikely to hold a better written account of what each of its systems does. Without one it changes, tenders for and audits its systems from documents that describe something else

2. The Business Problem, in the Buyer’s Words

“Our main system has a bound specification from the year it went live. Nobody trusts it, so nobody opens it. The team works from the code, and from what two people remember. Two years ago we paid for a documentation exercise; the volumes are already wrong. Every officer who takes charge of the section is given one line about the system in the handing-over note, and within weeks has to approve a change to it. Now there is a proposal for another exercise, and I do not know why this one would last longer than the last.”

These words are imagined. They describe the decision as the research shows it, not a real conversation.

The body is caught between documents it cannot trust and a system it cannot describe, because the record was written once and nobody was ever made responsible for keeping it true.

3. What We Found

Method. We went through the public record on how well governments know what their systems do: the UK government’s own review of its digital services (January 2025), statements by the UK digital department to Parliament (reported in June 2026), press coverage of the US national auditor’s July 2025 report on its most critical legacy systems, and 2025 reporting on one long-lived UK public system. From outside government we read one vendor’s survey of technology leaders and one engineer’s reply in a developers’ forum. The sector research behind this study holds no Indian public body and no body of our readers’ size on this issue.

A government that does not fully know its estate. In a letter to a parliamentary committee, reported in June 2026, the permanent secretary of the UK’s central digital department, a civil servant, wrote that the existing “data is incomplete and uneven in coverage” on the government’s old systems. In the UK government’s own survey of more than 500 public-sector leaders across 120 organisations, “around 15% of survey respondents could not even estimate the size of their legacy estate”. The 15% is of the people who answered, not of public bodies. Both facts are about knowing an estate as a whole, not about the documents of any one system.

Plans only partly written down. Press coverage of the US national auditor’s July 2025 report says that many agencies “have only partially documented their plans” to complete the modernisation of their most critical legacy systems. That is about plans, not about the systems, and “many”, not all. We use it only to show how thin the written record can be at the top.

Systems that outlast their documents. A large UK public body still runs a supplier-built system, more than 25 years old, which the trade press reported in 2025 may now run into the 2030s, later than its planned replacement. That is a possibility, not a fixed date. We use it only for how long a system can stay in service, and say nothing about its documents.

Outside government: what is built and what is written. In one vendor’s survey of several hundred technology leaders and practitioners, more than nine in ten reported negative business outcomes linked to a mismatch between the architecture they had built and their documented standards. It is cross-sector, and it measures how systems are built against written standards, not systems against their manuals.

Outside government: the risk in a fast draft. One engineer, replying in a developers’ forum thread, maintains “the legacy code base, which I’ll need to maintain for years”. Of documentation teammates wrote with AI tools, the engineer said: “The AI docs are simply wrong, 100% hallucinations.” and “Sometimes no doc is better than a bad doc.” That is one person’s account, and the reply does not say the documents were about the legacy code. We use it only as the reason engineers and the body’s own experts review whatever a tool drafts.

Our reading of why the documents stop being true. These four are our reasoning from the record above. None is a finding of any source.

1. It was written once. Documentation was a deliverable for acceptance. It recorded what the system was meant to do on that day, and nobody was asked to touch it again.
2. It is separate from the work. A change is made in the code by one person. Updating the document is a different task that belongs to nobody, and nothing fails when it is not done.
3. It was written for programmers. The officers responsible for the system cannot read it, so they have never been in a position to say it is wrong.
4. Knowledge travels with people. Officers in charge move on, and what each has learned leaves with them; the supplier’s account is often the one that stays.

4. The Options a Body in This Position Had

Option	When it fits	What it risks	Our view
Keep the old volume and fill the gaps from staff memory	The system has changed little, and the people who know it are still in post	Nobody can tell which pages are true; memory leaves on transfer	Right only for a system that has barely changed
Commission a documentation exercise: interviews, then volumes	A full write-up is needed for a fixed occasion, and the people who know the system are in post	Built from memory, so the parts nobody remembers are missing; out of date with the next change; paid for again	Right as a one-off, not as a way to keep a record
Rely on the supplier’s knowledge	The supplier has made every change, and the contract has years to run	The department’s understanding is the supplier’s account, which it cannot check; it leaves with the contract	Right as a source, not as the record
Have an AI tool draft a description of the code	A rough first map is needed quickly, and someone will check every line	Left unchecked, it can be wrong and still read well	Right only as a first pass that people review
Take a specification from the code, reviewed by engineers and confirmed by the body’s own experts, owned by the body, and then keep it current with each change	The record will be used to change, tender for, audit and hand over the system over many years	Costs money and officers’ time before anything changes; keeping it current is the body’s own work and needs an owner	Our recommendation

5. Our Recommendation, and the Decision It Asks of the Board

For the applications a body built or had built (licence and permit registers, property tax and utility billing, citizen portals, grievance and case-management systems): take the description once from the system itself. A tool may do a first pass; engineers review each item and trace it to the code; the officers who run the work confirm it. The result is a specification the body owns and can show to any supplier, with a risk register beside it. Then name a post in the department that owns the record, and update it in the same piece of work as each change. That upkeep is the body’s own work, with its own team or supplier; IOanyT does not stay on to do it. Whether the record forms part of the handing-over of charge, and what the body asks of its suppliers about it, are the body’s own decisions under its own rules.

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 body’s own figures, taken in the first review.

Measure	Typical starting point	Where it should be	How it is checked
What the system’s documents describe	The system in the year it went live	The system as it runs today	The map of the system as it stands
Where each statement comes from	The supplier’s design, interviews or memory	Traced to the code, and dated	The specification
Who has confirmed it	Nobody, since acceptance	The body’s own experts, for the work they run	The specification, with their confirmation recorded
What is fragile or uncertain	Known to a few people	Written down and ranked, with gaps marked as gaps	The risk register
What an officer taking charge is handed	One line in the charge note	A short handover pack drawn from the specification	The department’s handing-over note
Who keeps the record current	Nobody, until the next exercise	A named post in the department, updating it with each change	The filled-in benchmark at handover
Proof that a rebuilt module does what the old one did	Not recorded	Every old function linked to its replacement	The traceability matrix

7. How IOanyT Would Work

1. We listen: a free Reliability Review. A first conversation about the system, the documents that exist, what an officer taking charge is given and what the department has bought before. 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 study is an example of that work.
3. We read the system and propose: the Legacy System Specification Assessment. Here the system is the application whose documents no longer describe it. 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.
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.
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.

A body that wants only the record can stop after step 3.

8. What the Client Would Own

• The map and the specification: what the system does today, taken from the code and confirmed by the body’s own experts, in writing. The body can show it to any supplier.
• The risk register: what is fragile or uncertain in the system, ranked, with gaps marked.
• The traceability matrix: for every module IOanyT rebuilds, if the body goes on to a build, every old function linked to its replacement, with how it was checked.
• The code: any rebuilt modules are the body’s. No runtime or platform fee.
• The filled-in benchmark: each measure, where it started and where it stands.

Keeping the record current after the work is handed over is the body’s own team’s step.

9. What This Approach Does Not Cover

• IOanyT does not maintain the system or its record after the work is handed over. Keeping the record current is the body’s own task, with its own team or supplier.
• IOanyT does not write user manuals or training material, and does not train officers. It has not published a version of the specification written for officers who are not engineers.
• IOanyT does not keep the old system running while it is read or while modules are rebuilt; the body’s own team or supplier does.
• IOanyT does not work in COBOL or assembly language or on mainframes. The older technologies it reads include VB6, Delphi, AngularJS, PHP 4 to 8, Java 8, .NET Framework and classic ASP.
• IOanyT gives no advice on service rules, on how charge is handed over, or on procurement or contract rules. It does not say it is empanelled, registered or approved as a supplier to any government, or that it meets the conditions of any tender.
• The assessment needs read-only access to the code; only the first conversation starts without it.
• This study does not say IOanyT would have prevented or solved any named body’s problem. IOanyT has no published case of this work for a public body.

About this study: IOanyT did not work on this case. It is drawn from published findings, cited below.

10. Sources

Source	Used for
PublicTechnology, 12 June 2026	”Incomplete and uneven in coverage”
UK State of Digital Government Review, 21 January 2025	The survey’s 15%
FedScoop, 17 July 2025, on US Government Accountability Office, GAO-25-107795	Plans “only partially documented”
Trade press, 2025	A large UK public body’s system, more than 25 years old and possibly running into the 2030s
A vendor’s survey report, 2025	More than nine in ten (cross-sector)
Developers’ forum reply, 15 March 2026	One engineer’s account of AI-written documentation (cross-sector)

IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. We write down what your system does today, from the code, so that the department holds one record it can trust and keep.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →