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, and the fear of revision keeps the old system running for another year. We weigh four ways to replace it, say what each one risks, and explain what waits while the decision is deferred.
The file has come back to the finance section. Its subject line reads: revised cost estimate. It is the third revision.
The first figure was sanctioned two years ago, on a list of modules and a presentation. The second followed when the supplier opened the old system and found reports nobody had mentioned. The third follows the discovery that the fee rules live in the database, not in the application.
Nobody believes this is the last. Each revision needs fresh sanction, and brings the same question: why was this not known at the start?
The paradox: The money was sanctioned for a known amount of work, and the amount of work was the one thing nobody knew.
What We Found
For this article we went through the public record on what happens to the cost and the timetable of a public replacement: reporting in 2026 on a large UK council’s new finance system, and the US national auditor’s reports of September 2024 and July 2025 on federal systems.
First, what we did not find: no figure for how often public replacements overrun, no Indian public body or body of our readers’ size with an overrun on the record, and nothing from the Middle East. The bodies below are a very large council and national governments.
A first estimate can be a small part of the forecast. A large UK council replaced its finance system with a packaged product. 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.
The record names what went wrong in the build. The council made custom changes, including a reconciliation function that failed, and it could not produce auditable accounts.
Timetables move as well as figures. 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.” Those are air traffic control systems, which are not our 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.
Meanwhile the old systems keep running, and keep costing. The same July 2025 report found that about 80% of the more than 100 billion US dollars the federal government spends on IT each year goes on running existing systems. Of the 11 most critical federal legacy systems, three had complete plans to modernise them, six had incomplete plans and two had none.
Our reading: an estimate made from a list of modules and a presentation is a forecast of work nobody has described. What is inside the old system arrives later, as revisions. Each public revision makes the next replacement look riskier, and the old system is kept for another year.
What our review does not show: We found no figure for how often replacements overrun, no Indian or mid-size case of an overrun, and nothing from the Middle East. That case is a packaged finance product at a very large council, which is not our kind of work, and its cost figure is a forecast, not a final cost. The US systems are national, some in air traffic control; the health department’s delay is put down to funding, not to the estimate. That estimates rise because the old system was not read first is our reasoning, not a finding of any source. We make no comment on any council, agency or official.
What Waits While the Replacement Is Deferred
The usual view is that deferring a replacement keeps every option open. Our reading is that deferral is a decision too, and the old system keeps ageing while it is taken.
The old system grows harder to read. The officers and suppliers who know it move on, and each year less of what it does is known to anyone.
Every change made meanwhile is one more thing to carry over. A new report, a new fee rule, a new link to another department: each is added to the old system and becomes another function the replacement must match.
The running cost continues. Money goes on keeping the old system, not on leaving it, and none of it moves the body closer to the exit.
The next estimate starts from even less. When the proposal returns, it rests on the same list of modules, now older, and the same uncertainty is priced in again.
The gap we see: most public bodies we write for know that an old system must go, and have seen an estimate for replacing it. Few have a price built from reading the system first, with the unknowns listed and the work split into stages. A body that has one can decide one stage at a time, on evidence, in place of deferring the whole decision for another year.
This is our reading of the evidence. It is not a measured market figure.
Four Ways to Replace an Old System, Weighed
There are four real options. Each one is right for somebody.
| Option | When it fits | What it risks |
|---|---|---|
| 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 |
| Defer, and keep the old system running | The system is stable, its platform is still supported, and its retirement is near anyway | It keeps ageing: the people who know it leave, changes pile up, and the eventual replacement grows larger |
| Move to a packaged product | The body’s work matches what the product does as it comes, and the body would rather buy a product than own an application | Fitting the product to the body’s ways means custom changes, which carry their own risk. This is not our kind of work; the choice is the body’s |
| Replace it one module at a time, each module accepted by the people who use it, with the old system running | The application is the body’s own, the service cannot stop, and the body wants to decide stage by stage | It costs money to read the system before anything is built, the full price may be higher than a first guess, and two systems run side by side for a time |
Our recommendation: for an application the body built or had built, replace it in stages. Read it first and write down what it does. List the unknowns before the price, and price each stage on what was found. Then replace one module at a time with the old system running, and let the people who use each module accept it before the next begins. Where a packaged product fits better, that is the body’s decision, and it is not work we do. We do not keep the old system running or secure while it is replaced.
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 |
|---|---|---|---|
| Basis of the estimate | A list of modules and a presentation | The system read first and what it does written down | The specification |
| Unknowns | Found after work begins, as change requests | Listed before the price is set | The risk register |
| Cost of staying against cost of replacing | Not compared | Set side by side | The cost comparison |
| Price | One figure for the whole replacement | A fixed quote for each stage, after the system has been read | The staged plan with its fixed quote |
| Points of decision | One, at the start | After each accepted module, with the freedom to pause | The staged plan |
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, the estimates it has had and what each revision found. 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. 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. The assessment will not remove every unknown; it says which ones remain. 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 each stage are sanctioned and 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 | A figure that can be defended before the finance department and the legislature, decided one stage at a time. |
| Head of procurement | Bidders price a written specification, so bids can be compared and change requests are fewer. |
| Head of IT | An estimate built from what is in the system. Nobody has to own a guess. |
| Head of finance | A fixed price for each stage, set after the system has been read, in place of a revised estimate every year. |
| Head of service delivery | Running old and new side by side stays in the plan, because the price was set after the system was read, not cut back to meet an overrun. |
The cases in this article, and what IOanyT does about that kind of problem:
| The case | What IOanyT does |
|---|---|
| A large UK council: a forecast cost many times its initial estimate; expected savings in the tens of millions of pounds written off. | 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 read the system before we price it, list the unknowns in a risk register and give a fixed quote for each stage. |
| 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 business applications, the staged plan sets out each stage before the body commits to any of them. |
| The US national auditor (July 2025): about 80% of federal IT spending on running existing systems. | We make no comment on any government’s choices. We set the cost of keeping a body’s application beside the cost of replacing it, so a decision to defer rests on evidence. |
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, so the figure a body sanctions rests on what is there.
Sources
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 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