Public Replacements Overrun, Fail at Go-Live or Go Unused. Here Is What the Public Record Shows.
We went through the public record on public bodies that replaced a system: a council that could not produce auditable accounts, a board whose new modules went unused, national projects a decade from done. Here is what we found, the options, and the benchmark we would set.
The go-live date has been fixed. The department’s new system will start on the first of April, with the financial year. The old one will be closed on the thirty-first of March.
At the last review, an officer from accounts asks a question. What happens if the bank reconciliation does not work in April?
Nobody has an answer. The old system will be closed and its data moved. There is no plan for going back.
The paradox: The date was chosen because it is the cleanest moment to change, and it is also the moment the department can least afford a failure.
What We Found
For this article we went through the public record on public bodies that replaced a system: reporting in 2026 on a large UK council’s finance system, a press report of an Indian audit tabled in December 2025, and the US national auditor’s reports of September 2024 and July 2025.
First, what we did not find: no named public body of our readers’ size whose replacement overran or failed at go-live, and nothing from the Middle East. The other bodies are a very large council and national governments.
A go-live can leave a body without accounts it can audit. 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.
The first estimate can be a small part of the forecast. The same report set the programme’s forecast cost at many times its initial estimate; it is a forecast, not a final cost. Expected savings in the tens of millions of pounds were written off.
A system can go live and stay unused. In India, the national auditor’s report tabled on 18 December 2025 found, as the press reported it, 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 board “continued to rely on manual processes and legacy systems”. The audit, as reported, gives a cause: the committees overseeing the rollout did not review progress or address gaps in user requirements, application controls and information security.
Some replacements are a decade or more from done. The US national auditor reported in September 2024 that, at the US aviation agency, “Some system modernization projects won’t be complete for another 10-13 years.” Air traffic control is not our kind of work. In July 2025 the same auditor reported that the modernisation of one US health department system is now expected in fiscal year 2035, five years later than the original plan, which officials put down to funding.
Our reading: in these records the hard part is the move, not the new technology: a product meant to be used as it came was customised, gaps in what users needed stayed open, and modules went live that nobody used. Found on one day, such gaps are found by everyone at once.
What our review does not show: We found no public body of our readers’ size with a failed or overrun replacement, and nothing from the Middle East. That case is a packaged finance product at a very large council, not our kind of work, and its cost figure is a forecast. The Heavy Water Board record is a press report of an audit we did not read ourselves; it concerns new modules left unused, not an old system failing. The US systems are national, some in air traffic control. That a single go-live gathers the risk into one day is our reasoning, not a finding of any source. We make no comment on any council, board, agency or official.
What Waits Behind One Go-Live Day
Our reading is that a body deferring a replacement is often being asked to stake a public service on one morning.
The decision is all or nothing. The whole replacement is approved before any part of it has been seen to work.
There is no way back. Once the old system is closed, returning to it is a second migration, done under pressure.
The gaps arrive together. What nobody wrote down shows itself at the first month-end, in every section at once.
The service cannot pause. Salaries and certificates fall due on their dates, whatever state the new system is in.
The gap we see: most public bodies we write for have a replacement plan, or a proposal, built around a single go-live. Few have a plan in which each module is checked against what the old system did and accepted by the people who use it, while the old system still runs. A body with that plan can start, because no single day decides the outcome.
This is our reading of the evidence. It is not a measured market figure.
Four Ways to Plan the Switch, Weighed
There are four real options. Each one is right for somebody.
| Option | When it fits | What it risks |
|---|---|---|
| One go-live date for the whole system, often the start of a financial year | The system is small, everything it does is written down, and the body can absorb a difficult first month | Every gap is found at once, with the old system already closed |
| A pilot in one office, then the whole system everywhere | Offices work the same way, and the pilot office is typical | The pilot proves one office; the later switch is still one day for the rest |
| The whole new system run beside the old one for a period, then the old one closed | Staff can enter everything twice for a time | Double entry is heavy, and the period is often cut short when the cost rises |
| One module at a time, each checked and accepted, with the old system running for the rest | The service cannot stop, and the body wants to decide stage by stage | It takes longer on the calendar, two systems run side by side for a time, and some staff use both |
Our recommendation: replace in stages. Read the old system first and write down what it does. Move one module at a time, starting with one that is useful but not critical, with the old system running for everything else. Check each module against what the old one did, and let the section that uses it accept it before the next begins. We do not implement packaged finance or ERP products, and we do not keep the old system running or secure in the meantime; the body’s own team or supplier does.
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 |
|---|---|---|---|
| How the change reaches the sections | Every section on one go-live date | One module at a time, with the old system running for the rest | The staged plan |
| What the old system does | Known to a few people, or written from manuals | Written down from the system itself and confirmed by the body’s own experts | The specification |
| A way back if a module is not ready | None once the old system is closed | The old system still running until each module is accepted | The staged plan |
| Proof that a module does what the old one did | A go-live date | Every old function linked to its replacement | The traceability matrix |
| Known risks | Found after go-live | Listed before the price is set | 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
- We listen: a free Reliability Review. A first conversation about the system to be replaced and the plan for replacing it. 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 an application the body built or had built, such as a billing or licence 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.
What we do not do: 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 do not train staff or manage change as a service; whether a system is taken up also depends on the body’s own leadership. We are not auditors. 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 financial or procurement rules: how an assessment and the stages after it are bought 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 | The replacement that has been deferred for years can begin, because no single day puts a public service or the department’s accounts at stake. |
| Head of procurement | Work that is checked and accepted part by part, not signed off on one completion certificate. |
| Head of IT | A part that is not ready stays switched off, and the old system is still there. Nobody repairs a live system in front of the public. |
| Head of finance | Money is released stage by stage, and a stage that disappoints can be paused without writing off the whole programme. |
| Head of service delivery | Sections change one at a time, and the counters stay open throughout. |
The cases in this article, and what IOanyT does about that kind of problem:
| The case | What IOanyT does |
|---|---|
| A large UK council: a packaged finance system with custom changes; a reconciliation function failed; no auditable accounts; a forecast cost many times the initial estimate. | We make no comment on the council, and our part is far narrower: we do not implement packaged finance products. For applications a public body built or had built, we replace one module at a time with the old system still running, each with a traceability matrix. |
| The Heavy Water Board (India, Department of Atomic Energy), in an audit report tabled in December 2025: core modules “remained unused for more than two years after the system went live”. | We make no comment on the board, and we do not train staff. For applications we replace, we write down what the old system does, and each module is accepted before the next. |
| The US national auditor (September 2024 and July 2025): some aviation modernisation projects 10 to 13 years from completion; one health department system now expected in fiscal year 2035. | National systems, some in air traffic control, which is not our kind of work. For applications on technology we read, we produce a staged plan with a fixed quote and build only the stages a body approves. |
IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. We replace a public body’s application in stages, so that no single morning decides whether the replacement worked.
Sources
In this issue
Replacement fails or overruns
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.
Research note 3
"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. We weigh four ways to decide a replacement is done and set out the benchmark we would agree.
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