A New Officer Takes Charge of Your System With Nothing to Read. Three Ways to Change That, Weighed.
Officers in charge of a public system change, and each new one inherits nothing to read about it. We weigh three ways to change that: a documentation exercise, the supplier's knowledge, or a specification the body owns.
An officer is being relieved on transfer after three years in charge of a section. The handing-over note is ready for signature.
It lists the files, the furniture, the cash balance and the pending cases. Near the end there is one line about the system through which the section does all its work. Computer system: in working order.
The successor signs. In the first week a proposal arrives from the supplier for a change to that system, with a price. The new officer has to decide, and has nothing to read that would help.
The paradox: The officer in charge is responsible for the system from the first day, and has nothing to read about it on any day.
What We Found
For this article we went through the public record on how much governments have written down about their old systems: 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.
First, what we did not find: no figure for how often officers in charge of a public system change, none for how many take charge without a written record, and nothing on this issue from India or the Middle East. Every body named below is far larger than the departments, municipal bodies and boards we write for.
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.
Many leaders 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 complete the modernisation of their most critical legacy systems. That is about plans, not the systems. We use it for one point: what is written down can be thin even where the stakes are highest.
A system can outlast many officers. 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, many people take charge of a system in turn. We use the case only for how long a system stays in service, not for how it was handed over.
Our reading: knowledge of a public system is carried by the person, not by the post. What documents exist were written for programmers, or for acceptance in the first year. An outgoing officer explains what they can in an afternoon, and the one party present throughout is often the supplier.
What our review does not show: We found no evidence on transfers, charge notes or handovers in any country, and nothing from India or the Middle East. The UK facts are about not knowing an old estate in general, and the US fact is about plans; none is about what an incoming officer is given. How public bodies hand over charge is our reasoning from how such bodies commonly work, not a finding of any source, and the service rules that govern it were not researched. We make no comment on any officer, government or service rule.
What Waits While Each Officer Starts From Nothing
This is not a comment on any officer. Anyone placed in that chair would be in the same position. Our reading is that several things wait while the department holds nothing an officer can read.
Decisions come before understanding. The officer must approve changes, renewals and budgets in the months when they know least about the system.
The supplier becomes the memory. With nobody in the department who knows the history, the supplier’s account is the one that stays. That is a common position, not a criticism of suppliers, but the department cannot check what it is told.
The same questions are asked every few years. Each new officer asks them again, and they are answered again from memory.
Nothing accumulates. After twenty years and several officers, the department may know no more about its system than it did at the start.
The gap we see: most public bodies we write for hand over a system with a line in the charge note. Few hold a record of what the system does that belongs to the department rather than to a person or a supplier, taken from the system itself and confirmed by the officers who run the work. A body that holds one can hand it over with the charge, and each new officer starts by reading. One that does not starts again at every transfer.
This is our reading of the evidence. It is not a measured market figure.
Three Ways to Give the Next Officer Something to Read, Weighed
There are three real options. Each one is right for somebody.
| Option | When it fits | What it risks |
|---|---|---|
| A documentation exercise: consultants interview staff and deliver volumes | The body needs a full write-up quickly, and the people who know the system are still in post | It is built from what people remember, so the parts nobody remembers are missing; it is often written for programmers; and it goes out of date with the next change |
| Rely on the supplier’s knowledge: the supplier briefs each new officer | The supplier has been there throughout, and the contract has years to run | The department’s understanding is the supplier’s account, which the officer cannot check; it leaves when the contract ends |
| A specification taken from the code, reviewed by engineers and confirmed by the body’s own experts, owned by the body | The body wants a record that stays with the post and that it can show to any supplier | It costs money and officers’ time before anything changes; it is written to build from, so what an officer who is not an engineer needs from it should be agreed at scoping; and keeping it current afterwards is the body’s own task |
Our recommendation: the specification. Take the record from the system as it stands, have engineers review each item and trace it to the code, and have the officers who run the work confirm it. The record then belongs to the body, not to an officer and not to a supplier, and it can be shown to any supplier. Whether it forms part of the handing-over of charge is for the department to decide; we give no advice on service rules. We do not write user manuals or training material, and we do not train officers. If the body wants a shorter account for officers who are not engineers, it should raise it at scoping; we have not published one as part of the assessment.
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 an incoming officer is given about the system | One line in the charge note | The department’s own record of what the system does, the rules it applies and what is fragile | The specification and the risk register |
| Who holds what the system does | The officer in post, and the supplier | The department, in a record it owns and can show to any supplier | The specification |
| How the rules are stated | In the code, or in a design written for programmers | Written down, traced to the code and confirmed by the officers who run the work | The specification, with their confirmation recorded |
| What is fragile or undecided | Known to whoever is in post | Written down and ranked | The risk register |
| What survives a transfer | A briefing of an afternoon | The record, handed over with the charge in the way the department decides | The department’s handing-over note |
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 system and what an officer taking charge of it is given today. 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 the application each new officer takes charge of, such as a grievance system or a property tax 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.
- 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.
A department that wants only the record can stop after step 3. The specification and the risk register belong to the body, and stay with it when officers, staff and suppliers change.
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 give no advice on service rules, on how charge is handed over, or on procurement or contract rules, and we do not say we are empanelled with any government. We do not work in COBOL or assembly language or on mainframes. We have no published case of this work for a public body.
What changes for the business:
| Role | What they gain |
|---|---|
| Head of department | An officer taking charge has the department’s own record of the system to start from, and what the department knows survives a transfer. |
| Head of procurement | The committee that evaluates a bid can set it against the department’s own description of the system being changed. |
| Head of IT | Fewer questions reach the IT section that the department’s own record already answers. |
| Head of finance | The rules behind the figures the system reports are written down, and finance can ask to see them. |
| Head of audit and vigilance | Audit can test the system against a written description the department owns, not one engineer’s account. |
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 record of what it does, which stays with the body when people change. |
| 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 produces a written specification, a risk register and 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 how it was handed over. For an application on technology we read, we write down what it does, so that each person who takes charge of it has something to read. |
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 as a record the department keeps when people change.
Sources
In this issue
Thin or missing documentation
Research note 1
Your System's Manual Describes a System That No Longer Exists. Here Is What the Public Record Shows.
Many public systems run on documents from the year they went live. What the record shows, four ways to get a true description, the benchmark we would set.
Research note 3
Every Document About Your System Goes Out of Date. Here Is the Benchmark We Would Set.
Documentation exercises go stale. We weigh four ways to keep a public system's record true and set out the benchmark: a record dated and traced to the code.
Issue study
Incomplete and Uneven
A study of thin and out-of-date documentation of public systems: what the record shows and cannot show, the options, what we would avoid, and our benchmark.
More from Government and public sector
Replacement fails or overruns
A Deferred Replacement Is Still a Decision. Four Ways to Replace an Old System, Weighed.
Wrong outputs trusted as correct
Every Figure Your System Produces Should Trace to a Written Rule. Here Is the Benchmark We Would Set.
Upkeep absorbs the budget