Your System's Manual Describes a System That No Longer Exists. Here Is What the Public Record Shows.

A change is needed to the department’s main system. The head of IT goes to the almirah and takes down the documentation.

It is a bound volume, signed off in the year the system went live. It describes nine modules. The system now has fourteen. Half the screens pictured in it no longer exist.

A developer glances at it and says what the whole section knows. Nobody uses that. We read the code.

What We Found

For this article 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), the UK digital department’s statements 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 and one engineer’s reply in a developers’ forum.

First, what we did not find: no figure, in any country, for how many public systems lack documentation or have documents that no longer match them, and nothing from India or the Middle East on this issue. Every public body named below is far larger than the departments, municipal bodies and boards we write for.

Even the centre’s own data is partial. In a letter to a parliamentary committee, reported in June 2026, the permanent secretary of the UK’s central digital department wrote that the existing “data is incomplete and uneven in coverage” on the government’s old systems. The words are a civil servant’s, about data on the estate as a whole, not the documents of one system.

Many people cannot say how big their old estate is. 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.

Even plans are 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 modernise their most critical legacy systems. That is about plans, not the systems. We use it for one point: the written record can be thin even at the top.

Systems outlive the papers written at the start. 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, not for its documents.

Outside government, what is built and what is written down part company. 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, not about public bodies, and it measures how systems are built against written standards, not systems against their manuals.

A fast draft can be a wrong one. 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.” It 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: the documents stop being true because of how they were made. They were written once, by the supplier, so that the system could be accepted. After that, every change went into the code and none into the volume, and nothing fails when a page is wrong. Over decades, the volume comes to describe a system that no longer exists.

What Waits While the Manual Is Wrong

A department with an out-of-date manual is not careless. Our reading is that several things it must do rest on a description it lacks.

A change cannot be estimated with confidence. Each supplier must first find out what the system does today, and prices that discovery into every quote.

A tender cannot carry a true description. The volume from the first year cannot be attached, because bidders would price a system that no longer exists.

An audit finds a gap the department cannot close. When auditors ask for the system’s documentation, what is produced describes a different system.

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

Four Ways to Get a True Description, Weighed

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

Option	When it fits	What it risks
Keep the 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 still true, and memory leaves on transfer
Ask the IT team to write it up between changes	The team knows the system well and has time set aside for it	Changes are urgent and the write-up is not; it is written from memory, not checked against the code
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, the draft can be wrong and still read well, and a wrong document that looks authoritative is worse than none
A specification taken from the code, reviewed by engineers and confirmed by the body’s own experts	The description will be used to change, tender for or audit the system	It costs money and officers’ time before anything changes; it is true on the day it is finished, and keeping it true is the body’s own task

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 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, or someone’s memory	Traced to the code	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
The parts nobody sees on a screen	Not written down	Overnight jobs, database rules and links to other systems written down	The specification
What is fragile or uncertain	Known to a few people	Written down and ranked, with gaps marked as gaps	The risk register

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

1. We listen: a free Reliability Review. A first conversation about the system and the documents that exist. 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. Here the system is an application whose documents date from the year it went live, such as a licence register or a billing application. 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.
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. 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.
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 department that wants only the description can stop after step 3. The specification belongs to the body, and it can show it to any supplier. The older technologies we read include VB6, Delphi, AngularJS, PHP 4 to 8, Java 8, .NET Framework and classic ASP.

What we do not do: we do not write user manuals or training material, and we do not train officers. We do not maintain the system or its record after we hand it back; keeping the record current is the department’s own task. We do not work in COBOL or assembly language or on mainframes. We do not say we are empanelled with any government, and we give no advice on procurement, contract or service rules. We have no published case of this work for a public body.

What changes for the business:

Role	What they gain
Head of department	Decisions about the system are taken on what it does today, not on a description from the year it went live.
Head of procurement	A tender or a change request is written from a current description, so bidders price the real system.
Head of IT	A document the team trusts, because it was taken from the code and traced to it.
Head of finance	Estimates for changes rest on what is there, so fewer are padded for discovery.
Head of audit and vigilance	When audit asks for the system’s documentation, what is produced describes the system being audited.

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

The case	What IOanyT does
The UK government’s own review of January 2025 (around 15% of survey respondents could not estimate the size of their legacy estate) and its central digital department (in a letter reported in June 2026: existing data “incomplete and uneven in coverage”).	We make no comment on any government’s choices, and our part is far narrower than a national estate. For one body’s application, we write a specification taken from the code, which the body keeps.
Press coverage of the US national auditor’s July 2025 report: many agencies “have only partially documented their plans”.	The remark is about plans for national systems, some in languages we do not work on. For a public body’s own application, our assessment writes down what it does and sets out a staged plan with a fixed quote.
A large UK public body: a supplier-built system, more than 25 years old, which the trade press reported in 2025 may now run into the 2030s.	We make no claim about that system or its documents. For an application on technology we read, we write down what it does today, however long ago it was built.

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 system does today, from the system itself.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →