One Go-Live Day, and What It Stakes

1. At a Glance

Issue study · From the public record. None of the bodies named here was an IOanyT client, and IOanyT had no part in the events described. The main case is a very large UK council replacing its finance system with a packaged product, which is not IOanyT’s kind of work; the others are national governments and one Indian board, through a press report of an audit. We found no public record of a body of our readers’ size with a failed or overrun replacement. Each case is reported as the public record gives it, without judgement on any government, council, board or official.

Organisation type	A large UK council that replaced its old finance system, an Indian board whose new system’s core modules went unused, and US federal agencies with long modernisations, set beside the position of a mid-size public body that must replace an application it built or had built
Size band	The cases: a very large council, a board under a central department, national agencies. Our reader: a state department or directorate, a municipal corporation or council, a public utility, a board or authority, or a public-sector undertaking
Region	The cases: UK, India and US. The reader: anywhere
The decision at stake	How to replace an old system: in one project with a single go-live, by deferring and keeping the old one, by moving to a packaged product, or one module at a time with the old one running
The public outcome	A large UK council replaced its finance system with a packaged product; custom changes included a reconciliation function that failed, and the council could not produce auditable accounts. Its forecast cost is many times its initial estimate. At the Heavy Water Board, as India’s national auditor reported in December 2025, core modules “remained unused for more than two years after the system went live”
Why it matters to a mid-size public body	A replacement that goes wrong in public is examined by the auditor, the legislature and the press, and the service cannot stop while it is put right. So the decision is deferred, and the old system ages. A way to replace without staking the service on one day is what lets the decision be taken

2. The Business Problem, in the Buyer’s Words

“Everyone agrees the old billing system has to go. Nobody fully understands it any more, and the people who built it have left. But I have read what happened elsewhere: a council whose new finance system could not produce auditable accounts, a board whose new modules sat unused for two years. Our proposal has one go-live date, the first of April, and a figure the finance department will hold me to. If April goes wrong, the counters stop and the accounts are in question. So we have deferred it twice, and the old system is a year older each time.”

These words are imagined. They describe the decision as the research shows it, not a real conversation.

The body is caught between an old system it cannot keep forever and a replacement plan that stakes the service and the accounts on one day, priced before anyone has read what the old system does.

3. What We Found

Method. We went through the public record on public replacements: reporting in 2026 on a large UK council’s new finance system, a press report of 2 January 2026 on India’s national audit report tabled on 18 December 2025, and the US national auditor’s reports of September 2024 on the aviation agency and of July 2025 on the most critical federal legacy systems. The sector research behind this study holds no body of our readers’ size with a failed or overrun replacement.

A replacement that went live and could not produce auditable accounts. A large UK council replaced its finance system with a packaged product. Custom changes included a reconciliation function that failed, and the council could not produce auditable accounts. The press reported a forecast cost for the programme many times its initial estimate; it is a forecast, not a final cost. Savings in the tens of millions of pounds that the council had expected were written off.

A system that went live and was not used. 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, including plant status reporting and maintenance management, “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 gives a cause: the committees overseeing the rollout did not review progress or address gaps in user requirements, application controls and information security. No cost is given.

Replacements a decade 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.” These are air traffic control systems, which are not IOanyT’s kind of work. In July 2025 it 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. Of the 11 most critical federal legacy systems, three had complete plans to modernise them, six had incomplete plans and two had none, and about 80% of the more than 100 billion US dollars the federal government spends on IT each year goes on running existing systems.

Our reading of why replacements go wrong. These four are our reasoning from the record above. Only the Heavy Water Board’s cause and the council’s custom changes are findings of the sources; the rest is ours.

1. Nobody has a written record of what the old system does. The new one is specified from manuals and memory, and the gaps appear after go-live.
2. Everything changes at once. A single go-live, often at the start of a financial year, leaves no way to stop part-way or to go back.
3. The price is set before the system has been read. The first estimate rests on a list of modules, and each discovery arrives as a revision.
4. Go-live is treated as the finish. The project is complete when the system is switched on; whether the people who do the work can use it is found out later.

4. The Options a Body in This Position Had

Option	When it fits	What it risks	Our view
Replace it in one project, with a single go-live	The system is small and fully documented, and the body can absorb a hard first month	The price is set before the system is read, and every gap arrives on one day, with the old system closed	Right only for a small, well-documented system
Defer, and keep the old system running	The system is stable, its platform still supported, and its retirement near anyway	It keeps ageing: the people who know it leave, changes pile up, and the eventual replacement grows larger	Right as a dated pause, not as a standing answer
Move to a packaged product	The body’s work matches what the product does as it comes	Fitting the product to the body’s ways means custom changes, which carry their own risk	The body’s decision; not our kind of work
Read the application first, then replace it one module at a time, each accepted by the people who use it, with the old one running	The application is the body’s own, the service cannot stop, and the body wants to decide stage by stage	Costs money to read the system before anything is built; two systems run side by side for a time; some staff use both	Our recommendation

5. Our Recommendation, and the Decision It Asks of the Board

For an application a body built or had built (a billing, licence, case-management, payroll or grievance application): read it first and write down what it does, including the registers and manual steps staff keep beside it where they point to them. List the unknowns before the price. Set the cost of keeping it beside the cost of replacing it. Then replace it one module at a time, with the old system running, a traceability matrix linking every old function to its replacement, and each module accepted by the section that uses it before the next begins. Where a packaged product fits the body’s work better, that is the body’s decision, and not work we do. How the assessment and each stage are bought is the body’s own decision under its own rules.

6. Benchmark: Where You Are Now, and Where You Should Be

These are targets, not results. In an engagement the starting points are replaced by the body’s own figures, taken in the first review.

Measure	Typical starting point	Where it should be	How it is checked
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
Old functions listed and traced	No list; tests written from the requirements document	Every old function listed and linked to its replacement	The traceability matrix
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
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

7. How IOanyT Would Work

1. We listen: a free Reliability Review. A first conversation about the system to be replaced, the plan and estimates it has had, and what its users keep beside 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.
2. We research. We research your sector, the regulator’s position and what the public record says about firms in your situation. This study is an example of that work.
3. We read the system and propose: the Legacy System Specification Assessment. Here the system is the application the body wants to replace. 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.
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. A traceability matrix links every old function to its replacement. 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.

8. What the Client Would Own

• The map and the specification: what the application does, in writing, confirmed by the body’s own experts. The body can show it to any supplier.
• The risk register: what is uncertain about the replacement, listed before the price.
• The cost comparison and the staged plan: the cost of keeping the application beside the cost of replacing it, and a fixed quote for each stage.
• The traceability matrix: for every module IOanyT rebuilds, every old function linked to its replacement, with how it was checked.
• The code: the rebuilt modules are the body’s. No runtime or platform fee.
• The filled-in benchmark: each measure, where it started and where it stands.

Accepting each module, and switching off the old system when the last module has moved, are the body’s own steps.

9. What This Approach Does Not Cover

• IOanyT does not replace or implement packaged finance or ERP products, which is what the main named case involved. Its work is on applications a public body built or had built.
• IOanyT does not keep the old system running or secure while it is replaced; the body’s own team or supplier does.
• IOanyT does not train a body’s staff or manage the change in how they work as a stated service. Whether a system is taken up also depends on the body’s own leadership.
• IOanyT is not an auditor and gives no opinion on accounts.
• IOanyT does not work in COBOL or assembly language or on mainframes, and does not work on air traffic control, defence or other safety systems.
• The assessment will not remove every unknown; it says which ones remain.
• IOanyT does not say it is empanelled, registered or approved as a supplier to any government, or that it meets the conditions of any tender. It gives no advice on financial, contract or procurement rules.
• This study does not say IOanyT would have prevented the events described. IOanyT has no published case of this work for a public body.

About this study: IOanyT did not work on this case. It is drawn from published findings, cited below.

10. Sources

Source	Used for
Trade press, 2026	A large UK council: custom changes and the reconciliation function, auditable accounts, the estimate and the forecast, savings written off
Moneylife, 2 January 2026	The Heavy Water Board: unused modules, manual processes, the audit’s cause
US Government Accountability Office, GAO-24-107001, 23 September 2024	The aviation agency’s 10 to 13 years
US Government Accountability Office, GAO-25-107795, 17 July 2025	The health department’s 2035 date; plans for the 11 most critical systems; the 80%

IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. We read the system before we price it, replace it one module at a time with the old one running, and count a module done only when the people who use it accept it.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →