Every New Service Waits Because the Budget Is Already Spent on the Old Ones. Four Ways to Make Room, Weighed.
Upkeep is provided for first, and new services wait for a year with room in it. We went through the public record, weigh four ways to make room, and explain why we would start with a keep-versus-replace cost comparison for each application, highest upkeep first.
Six months ago an online service was announced. People would be able to apply for a certificate without visiting an office.
The head of department asks when it will be ready. The head of IT explains. The service needs changes to the old system, and those are costly. This year’s budget went on upkeep. A proposal has been put into next year’s estimates.
The head of department has heard this before. It was the answer last year, about a different service.
The paradox: The old systems must be kept running, and keeping them running is what stops the department building anything better.
What We Found
For this article we went through the public record on how upkeep and new work compete for the same money: the UK government’s own review of the state of its digital services, published in January 2025, an elected councillor’s account of local councils published in 2025, and an answer given in India’s Parliament in December 2025 on the e-services offered by the states and union territories.
First, what we did not find: no figure for what any Indian public body spends on upkeep, and no record of a new service held back by an old system in India, at any level of government. Nothing from the Middle East. The upkeep figures below describe UK public bodies, which are larger than most bodies we write for.
Upkeep can take almost the whole budget. The UK government’s own review found that some bodies spend as much as 70% to 85% of their technology budgets on upkeep. Whatever new work a body wants is paid from what is left.
Those who run councils say the same. An elected member of an English council, writing anonymously in 2025, said that budget pressures and competing priorities leave many councils struggling to modernise outdated systems or to recruit skilled security staff. That is one councillor’s account, not a survey, and it is about the UK.
Meanwhile, the number of services offered online keeps rising. In India, the government told Parliament in December 2025 that “between April 2023 and October 2025, the number of e-services offered by States/UTs increased from 11,614 to 23,919, which is over 105 % growth.” The figures come from the states’ and union territories’ own reports. The answer says nothing about the systems behind those services, or about what they cost to keep.
Our reading: the demand for new services is not waiting. In India the count of e-services offered by states more than doubled in two and a half years. Every one of them has to be joined to, or built beside, the systems a body already runs, and every one of them is paid from the part of the budget that upkeep has not already taken. Where upkeep comes first and takes most of the money, a new service waits for a year with room in it, and that year does not come unless something is taken out. That link between upkeep and new services is our reading; neither the review, the councillor nor the parliamentary answer makes it.
What our review does not show: We found no upkeep figure for any public body of our readers’ size and nothing from the Middle East. The 70% to 85% is from the UK government’s own review and describes “some bodies”, not most. The councillor’s words are one person’s view of UK councils. The Indian figures are a count of e-services reported by states and union territories; they say nothing about which systems are old, what upkeep costs, or whether any service was delayed, and we do not say so. We found no figure for what any body saved by replacing a system. We make no comment on any government’s choices; we report what its own reviews and answers published.
What Waits While Upkeep Comes First
The usual view is that new services wait for money, and that money will come in a better year. Our reading is that they wait for room, and that room has to be made.
The new service is costly because of the old system. A change that should be small is large, because the old application was not built to be extended and few people know it well.
The proposal moves to next year, and next year begins the same way. Upkeep is treated as committed and provided for first. No future year has more room in it unless something comes out.
A workaround is built instead. A small portal, a spreadsheet or a manual step beside the old system answers part of the need. Each one is reasonable at the time, and each one becomes one more thing to keep running.
The old system is never the subject. Every proposal is about the new service. The thing that makes it costly is not costed, so it is never weighed.
The gap we see: most bodies we write for can list the new services they have been asked for. Few can say which old application makes each one costly, what that application costs to keep, and what leaving it would cost. A body that knows can make room one application at a time, starting where upkeep is highest, and plan new services on what has moved. A body that does not waits for next year.
This is our reading of the evidence. It is not a measured market figure.
Four Ways to Make Room, Weighed
There are four real options. Each one is right for somebody.
| Option | When it fits | What it risks |
|---|---|---|
| Keep paying upkeep in full and wait for a larger budget | The old systems are close to retirement anyway, or a larger allocation is already promised | New services keep waiting, and the share taken by upkeep does not change by itself |
| Cut maintenance contracts to free money for new work | Some contracts cover systems nobody uses, or cover more than is needed | Cutting cover on a system still in use moves the risk to the public counter; the money often returns as an emergency purchase |
| Build workarounds beside the old systems | A need is urgent and small, and changing the old system is out of reach this year | Each workaround is one more thing to keep running, so upkeep grows and the old system stays the reason |
| A keep-versus-replace cost comparison for each application, highest upkeep first, then a staged plan | The body must make lasting room and show what it costs to keep and to leave each system | It costs money before it frees any, for a time the body pays for old and new together, and the comparison may show that keeping is cheaper |
Our recommendation: start with a cost comparison between keeping and replacing each application, beginning with the ones that cost most to keep. Where keeping is cheaper, keep it, and stop waiting for it to change. Where replacing is cheaper over the life of the service, replace it in stages, so that the body’s own team can switch the old platform off when the last module moves, and build new services on what has moved. Room is made only when something is switched off. We do not maintain or run old systems, and we promise no saving.
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 each waiting service depends on | ”Next year’s budget” | The old application that makes it costly, named, with what changing it would take | The specification and the cost comparison |
| Applications by upkeep | Not ranked | Ranked, highest upkeep first, with keep or replace set out for each | The cost comparison |
| Workarounds beside old systems | Not listed | Each listed with the application it works around | The map of the system as it stands |
| The plan to make room | One programme, or none | Stages, highest upkeep first, each with a fixed quote | The staged plan |
| Old platforms switched off | None planned | For each stage, the platform the body’s own team switches off when its last module moves | The staged plan and the filled-in benchmark |
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 services that are waiting, the applications behind them and what each one costs to keep. 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 that makes new services costly and takes the largest share of upkeep. 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 maintain, monitor, patch or run old systems, and we do not take over their upkeep. We promise no saving and give none as a figure; for a time the body pays for old and new together, and upkeep of an old platform stops only when the body’s own team switches it off. We are not accountants or auditors: the figures for what a body spends today come from its own finance section. We do not build the workarounds weighed above, and we do not supply staff. We do not say we are empanelled with any government, and we give no advice on budget 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 | New services for citizens stop waiting behind the cost of the old ones. Room is made one application at a time. |
| Head of procurement | Fewer old licences, covers and maintenance contracts come up for renewal each year. |
| Head of IT | After each application moves, there is one less old platform to look after. |
| Head of finance | Part of the budget that was committed before the year began becomes open to choice. |
| Head of service delivery | Improvements citizens have asked for can be scheduled, because there is room to pay for them. |
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 (January 2025): some bodies spend as much as 70% to 85% of their technology budgets on upkeep. | We make no comment on any government’s choices, and we promise no saving. For a body’s own applications, we set the cost of keeping each beside the cost of replacing it, highest upkeep first, and price the stages. |
| UK councils, in one elected councillor’s account (2025): budget pressures and competing priorities leave many councils struggling to modernise outdated systems or to recruit skilled security staff. | Our part is narrower: we do not recruit or supply staff, and we do not supply security. For an application a council built or had built, on technology we read, we write the specification and a staged plan to replace it while the old one keeps running. |
IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. We find where upkeep is highest, set keeping beside leaving, and make room one application at a time.
Sources
In this issue
Upkeep absorbs the budget
Research note 1
The Largest Line in Your Technology Budget Is the One Nobody Can Explain. Here Is What the Public Record Shows.
Where the total is known, upkeep takes most of a public IT budget, yet its parts rarely are. What we found, four ways to open the line, our benchmark.
Research note 3
Your Team Spends Its Year Keeping the Old System Alive. Here Is the Benchmark We Would Set.
Invoices are only part of what an old system costs; the rest is staff time nobody counts. Four ways to lighten the year, and the benchmark we would agree.
Issue study
Eighty Per Cent on Standing Still
How upkeep of old systems takes most of a public technology budget, from the public record: the options, what we would advise against, 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.
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