Every Document About Your System Goes Out of Date. Here Is the Benchmark We Would Set.

Two years ago the department commissioned a documentation exercise. Consultants interviewed the staff for three months and delivered four volumes.

Today the head of IT opens volume two to check a rule. The rule in the volume is not the rule in the system. It was changed last year. Nobody altered the volume, because that was nobody’s job.

On the same desk is a proposal for a fresh documentation exercise. Three more months, and four more volumes.

What We Found

For this article we went through the public record on how long public systems stay in service and how well what is written matches what runs: reporting in 2025 on one long-lived UK public system, the UK digital department’s statements to Parliament, reported in June 2026, and, from outside government, one vendor’s survey of technology leaders and one engineer’s reply in a developers’ forum.

First, what we did not find: no public figure, in any country, for how quickly a system’s documentation goes out of date, or for what a documentation exercise costs a public body, and nothing on this issue from India or the Middle East. The public bodies named below are far larger than the bodies we write for.

Public systems stay in service for decades. 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. Over a working life that long, a document made in any one year describes only a moment. We use the case only for how long a system stays in service, not for its documents.

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.

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. These are a civil servant’s words about data on the estate as a whole, not the documents of one system.

A new document is only as good as its check. One engineer, replying in a developers’ forum thread, maintains “the legacy code base, which I’ll need to maintain for years”. Of documentation that teammates had produced with AI tools, the engineer wrote: “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 a fresh description, however it is drafted, must be reviewed against the code.

Our reading: a record goes stale because it is separate from the work. A change is made in the code, by one person, under pressure. The document is somewhere else, and changing it is a different task that belongs to nobody. Nothing fails when a page is wrong, so nobody is sent to fix it. A fresh exercise built from interviews starts the cycle again, without the parts nobody remembered.

What a Dated, Traced Record Opens Up

The usual view is that documentation is a project: commissioned, delivered, filed, and commissioned again when it no longer helps. Our reading is that a record dated and traced to the code opens up three things a set of volumes cannot.

A wrong page can be found. When each part of the record says when it was confirmed and where in the code it comes from, anyone can check whether it still holds. A volume built from interviews gives no way to tell.

A known starting point for every change. A change request can name the part of the record it alters, and the department knows which version of the system it is changing.

An end to buying the same description twice. The department starts from a record it can keep, instead of commissioning a new one every few years. Keeping it is the department’s own work, with its own team or its supplier.

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

Four Ways to Keep the Record True, Weighed

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

Option	When it fits	What it risks
A fresh documentation exercise every few years	The system changes rarely, and a full write-up is needed for a fixed occasion	Built from interviews, so the parts nobody remembers are missing; out of date with the next change; paid for again and again
Leave the record to the supplier as a contract deliverable	The supplier makes every change and the contract runs for years	The record is accepted because it exists, and the department cannot tell whether it is right; it stays with the supplier’s knowledge
The department’s own team updates the existing documents with each change	The documents are still close to the system, and the team has time and an owner	It starts from documents that may already be wrong, and nothing shows which pages are
Start from a specification dated and traced to the code, then keep it current with each change	The record will be used for decisions over many years	It costs money and officers’ time before anything changes; keeping it current is the department’s own work and needs a named owner; checks that bind the record to the system are the body’s own team’s choice

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
Date on the description	Undated, or the year the system went live	Each part dated, so its age is known	The specification
Where each statement comes from	Interviews, or the original design	Traced to the code	The specification
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	The filled-in benchmark at handover
When the record is updated	At the next documentation exercise	With each change, by the department’s own team or supplier	The record’s dates set against the changes made
Proof that a rebuilt module does what the old one did	Not recorded	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

1. We listen: a free Reliability Review. A first conversation about the system and the documentation the department has bought. 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 the application whose record the department will keep, such as a billing application, a register or a case-management system. 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 record can stop after step 3. The specification belongs to the body, and it can show it to any supplier.

What we do not do: we do not maintain the system or its record after we hand it back; keeping the record current is the department’s own task, with its own team or its supplier. We do not write user manuals or training material, and we do not train officers. 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	The department’s knowledge of its system carries a date, and does not have to be bought again at the next review.
Head of procurement	A change request names the part of a dated record it alters, so the department knows which version of the system it is buying a change to.
Head of IT	Each change starts from a record the team can date and trace, and the team knows which part to update.
Head of finance	The department stops paying to rediscover its own system.
Head of audit and vigilance	Each part of the description shows when it was last confirmed against the code, so audit knows which version of the system it describes.

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

The case	What IOanyT does
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 a specification traced to the code, which the department can keep current for as long as the application runs.
The UK’s central digital department, in a letter reported in June 2026: the existing data on old systems is “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 hand over a specification and a filled-in benchmark, and the body keeps them.

IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. We give the department one record to start from, traced to the code, which it then keeps.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →