"Live" Is Not "In Use". Here Is the Benchmark We Would Set for a Replacement.
A new public system can be declared live and still go unused, because it misses what the work needs. We went through the public record, weigh four ways to decide a replacement is done, and set out the benchmark we would agree with a public body before the first module.
Six months after the new system went live, an officer visits one of the section offices. The completion certificate was signed long ago, and the final payment has been made.
At the first desk a clerk enters an application on the new screen. Then the clerk opens a bound register and writes the same entry by hand.
The officer asks why. The register is what the section works from. The new system does not produce the monthly abstract that goes to the treasury, so the section keeps the register to prepare it.
The paradox: The project is complete on paper, and the work is still done on paper.
What We Found
For this article we went through the public record on new public systems that went live and did not do the work: a press report in January 2026 of an Indian national audit report tabled in December 2025, and reporting in 2026 on a large UK council’s new finance system.
First, what we did not find: no figure for how many public systems go live and stay unused, no public body of our readers’ size on the record with this problem, and nothing from the Middle East. Public evidence on this point is thin, and we say so.
A system can go live and stay unused for years. In India, the national auditor’s report tabled on 18 December 2025 found, as the press reported it on 2 January 2026, that core modules of a new integrated information system at the Heavy Water Board, under the Department of Atomic Energy, “remained unused for more than two years after the system went live”. The modules included plant status reporting and maintenance management. The board “continued to rely on manual processes and legacy systems”.
The audit gives a cause. As reported, the committees overseeing the rollout did not review progress or address gaps in user requirements, application controls and information security. The reported cause concerns oversight and what users needed; it does not mention the technology.
A system can go live and not do a basic job. A large UK council replaced its finance system with a packaged product. It made custom changes, and one of them, a reconciliation function, failed. The council could not produce auditable accounts. This is a packaged finance product, which is not our kind of work, and we use it for one point only: switching a system on and having it do the work are different events.
Our reading: in both records, “live” was a date, and “in use” was a different question that nobody had a way to answer before the date. A list of what the old system and its users do, matched function by function and accepted by the people who use it, is one way to answer it in advance.
What our review does not show: We found no figure for how often live systems go unused, no Indian or mid-size case beyond the one audit, and nothing from the Middle East. The Heavy Water Board record is a press report of an audit we did not read ourselves; it concerns new modules left unused, and it does not say what the new system replaced. That case is a packaged finance product at a very large council. That a matched, accepted list of functions would show a gap before go-live is our reasoning, not a finding of any source. We make no comment on any board, council or official.
What a Benchmark Opens Up
The usual view is that a replacement is done when the system is switched on and the certificate is signed. Our reading is that a benchmark agreed before the first module opens up four things a certificate cannot.
“Live” comes to mean “in use”. Each module is done when the people who use it accept it, not when it is switched on.
Gaps are found by a reader, not by a clerk. A missing abstract shows as an empty line in a table before go-live, not as a register reopened six months later.
The estimate has a history. Each revision after the system has been read points to an unknown that was listed in advance, so the finance section can see why it moved.
The work around the system is counted. Registers, spreadsheets and manual steps that staff keep beside the system are written down as part of what the replacement must do.
The gap we see: most public bodies we write for define a replacement as complete when it goes live. Few have a benchmark agreed in advance that lists every function of the old system, says who accepts each module and records what staff keep beside the system. A body with one can say, at each review, how much of the old way of working is no longer needed.
This is our reading of the evidence. It is not a measured market figure.
Four Ways to Decide a Replacement Is Done, Weighed
There are four real options. Each one is right for somebody.
| Option | When it fits | What it risks |
|---|---|---|
| A completion certificate when the system goes live | The system is small, and its users helped build it | Whether anyone uses it is found out after payment, when the project team has gone |
| Acceptance tests written from the requirements document | The requirements were written from the work, not only from manuals | Where the document is incomplete, the tests are incomplete in the same places |
| Sign-off by a steering committee after a trial period | The committee includes the people who do the work | A committee can sign for sections that were never asked |
| Each module matched function by function to the old system, and accepted by the section that uses it | The old system is still running, so results can be compared | It asks hours of busy section staff, and what lives only in a habit may be missed unless staff point to it |
Our recommendation: agree the benchmark before the first module. List every function of the old system and link each one to its replacement. Let the section that uses each module accept it, and compare the new module’s results with the old one’s before it takes over. Record the registers and manual steps staff keep beside the system, where they point to them. We do not train staff or manage the change in how they work; whether a system is taken up also depends on the body’s own leadership.
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 |
|---|---|---|---|
| Old functions listed and traced | No list; tests written from the requirements document | Every function of the old system listed and linked to its replacement | The traceability matrix |
| Who accepts each module | A committee signs one completion certificate | Each module accepted by the people who use it | The benchmark review after each module |
| Revisions to the estimate after the system has been read | Several, each needing fresh sanction | Few, each traced to an unknown listed in advance | The risk register and the staged plan with its fixed quote |
| Registers and manual steps around the system | Not recorded; found after go-live | Recorded where staff point to them, each with its own line | The specification |
| Results from each new module | Not compared with the old system | Reports and reconciliations compared with the old ones before the module takes over | 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 system, what its users keep beside it and how the body decides a replacement is done. 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 the body wants to replace, with its rules, reports and connections. 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 train staff or manage the change in how they work as a service. We do not replace or implement packaged finance or ERP products. We do not keep the old system running or secure while it is replaced; the body’s own team or supplier does. We are not auditors and give no opinion on accounts. We do not work in COBOL, assembly language, mainframes or air traffic control. We do not say we are empanelled with any government, and we give no advice on contract, financial or procurement rules: how acceptance is written into a contract is the body’s own decision. We have no published case of this work for a public body.
What changes for the business:
| Role | What they gain |
|---|---|
| Head of department | ”Live” means in use. The decision to switch each part on is made on evidence. |
| Head of procurement | Acceptance means a list of functions checked, not a general statement that the system is live. |
| Head of IT | A written record of everything the old system does, and proof for each function that the new one does it too. |
| Head of finance | Reconciliations and reports from each new part are checked against the old ones before it replaces them. |
| Head of service delivery | Staff find the reports, abstracts and steps they rely on in the new system, so nobody keeps the old register beside it. |
The cases in this article, and what IOanyT does about that kind of problem:
| The case | What IOanyT does |
|---|---|
| The Heavy Water Board (India, Department of Atomic Energy), in an audit report tabled in December 2025: core modules of a new system “remained unused for more than two years after the system went live”; the audit’s cause was oversight and gaps in user requirements. | We make no comment on the board, and we do not train staff or manage change. For applications we replace, each module has a traceability matrix and is accepted before the next begins. |
| A large UK council: a packaged finance system with custom changes; a reconciliation function failed; no auditable accounts. | Our part is far narrower: we do not implement packaged finance products, and we are not auditors. For applications a public body built, each old function is linked to its replacement before the module takes over. |
IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. We agree the benchmark before the first module, so “live” and “in use” mean the same thing when the work is done.
Sources
- Moneylife, 2 January 2026
- Trade press, 2026
In this issue
Replacement fails or overruns
Research note 1
Public Replacements Overrun, Fail at Go-Live or Go Unused. Here Is What the Public Record Shows.
Public replacements overrun, fail at go-live or go unused. What the public record shows, four ways to plan the switch, and the benchmark we would set.
Research note 2
A Deferred Replacement Is Still a Decision. Four Ways to Replace an Old System, Weighed.
Replacement estimates are revised because nobody read the old system first. We weigh four ways to replace it and say what waits while the decision is deferred.
Issue study
One Go-Live Day, and What It Stakes
A study of public replacements that overran, failed at go-live or went unused: what the record shows, the options, what we would advise against, our benchmark.
More from Government and public sector
Thin or missing documentation
A New Officer Takes Charge of Your System With Nothing to Read. Three Ways to Change That, 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