Your Team Spends Its Year Keeping the Old System Alive. Here Is the Benchmark We Would Set.

It is eleven at night on the last working day of the month. Two members of the IT section are still in the office.

They are putting the month’s changes into the billing application. They work from a printed checklist of forty-one steps, amended over the years in pen. Last quarter one step was run out of order, and the counters opened two hours late.

They will finish at about two. None of this appears in any budget. It is simply what the system needs.

What We Found

For this article we went through the public record on what it takes to keep old systems going: the US national auditor’s July 2025 report on the most critical federal legacy systems, the UK government’s own review of the state of its digital services, published in January 2025.

First, what we did not find: no figure, for any public body in any country, for the time its own staff spend keeping old systems running. Nothing from India or the Middle East on this issue. The bodies below are a national government and a national authority, far larger than the departments, councils and boards we write for.

Upkeep is most of the money. The US national auditor reported that about 80% of the more than 100 billion US dollars the federal government spends on IT each year goes on running existing systems.

When upkeep is counted system by system, it can be stated. The same auditor put a figure on a named set of systems: the 11 most critical federal legacy systems together cost about 754 million US dollars a year to run. The figure comes from the agencies that run them, given for the auditor’s review.

Where a body cannot do the work itself, it buys it. The UK government’s own review says the UK tax authority “relies heavily on costly third-party services to maintain outdated systems”. We cite the authority for one point: keeping systems alive is a standing cost, and part of it is bought from outside.

Our reading: the invoice side of upkeep can be counted for named systems when someone asks, as the US auditor’s review shows. The people side is rarely counted. The month-end release done by hand, the fault fixed at night, the old screen explained to each newly posted officer are paid in salaries under no system’s name. So the systems that take most of a team’s year can look cheap on paper.

What a Counted Year Opens Up

The usual view is that a team busy with upkeep needs more people. Our reading is that a counted year opens up three things more hands do not.

The true cost of each system is on the page. When the nights, the faults and the explanations are set beside the invoices, the system that costs most to keep is named, and it may not be the one with the largest contract.

The first stage chooses itself. The application that takes the most of the team’s year, for what it does, goes first. The order rests on a figure the body made, not on whoever argued last.

Each stage ends with something switched off. When an application has moved, module by module, the body’s own team switches its old platform off. Its upkeep, and the nights spent on it, stop then and not before.

This is our reading of the evidence. It is not a measured market figure.

Four Ways to Lighten the Year, Weighed

There are four real options. Each one is right for somebody.

Option	When it fits	What it risks
Hire or contract more people for upkeep	The load is temporary, or a system will be retired soon	The cost grows with each person, and what they know of the system often leaves with them
Write down the manual steps and keep the system as it is	The system will be retired within a short time, and the steps are what fails	The work is safer but no smaller; the same night is spent every month
The body’s own team automates its releases and checks on the old system	The team has the skills, the system allows it, and the body means to keep it for years	Effort goes into a system the body may later leave, and few people can change it safely. This is the body’s own team’s work, not ours
Count the year’s work for each application, then move the costliest one in stages, so its old platform can be retired	The body wants the load to fall, not just to be carried better	It costs money before it frees any time, the body runs old and new together for a while, and the count of hours is an estimate

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
Upkeep of each application	One line, listed by contract and supplier	Itemised for each application, using figures from the body’s own finance section	The cost comparison
The body’s own staff time	Not counted	Estimated by the IT section for each application and set beside the invoices	The cost comparison
What each application does	Known to the two people who run the month-end	Written down and confirmed by the body’s own experts	The specification
Order of the stages	Whatever failed last	The application that costs most to keep, for what it does, goes first	The cost comparison and the staged plan
Old platforms retired	None planned	One old platform retired per stage, by the body’s own team, when its last module has moved	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

1. We listen: a free Reliability Review. A first conversation about where the team’s year goes and which applications take 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 article is an example of that work.
3. We read the system and propose: the Legacy System Specification Assessment. Here the system is the application that takes most of the team’s year to keep alive. 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.
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. 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.
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.

What we do not do: we do not maintain, monitor, patch or run old systems, run releases, take over upkeep or supply staff. We promise no saving of money or of time, and give none as a figure. We are not accountants or auditors: the upkeep figures come from the body’s own finance section and the staff time from its IT section; the comparison is an estimate built on them. Retiring an old platform is the body’s own team’s step; its upkeep stops only then. We do not work in COBOL or assembly language or on mainframes. We do not say we are empanelled with any government, we give no advice on budget or procurement rules, and we do not say a body’s budget year will fit any of our terms. 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 department can see where its IT team’s year goes, and each stage ends with one old platform fewer to keep alive.
Head of procurement	Maintenance work can be described plainly in a tender, because what each system does is written down, so more than one firm can quote.
Head of IT	The nights the team spends on each old system are counted, and the system that costs most in them goes first.
Head of finance	The staff time behind each old system is counted with its invoices, so the full cost of keeping it is on the page.
Head of service delivery	Service delivery knows which counters rest on systems kept alive by night work, and those systems are first in line to move.

The cases in this article, and what IOanyT does about that kind of problem:

The case	What IOanyT does
The US national auditor (July 2025): about 80% of federal IT spending goes on running existing systems; the 11 most critical legacy systems together cost about 754 million US dollars a year to run.	We make no comment on any government’s choices, and our part is far smaller. For one body’s applications, we set the cost of keeping each beside the cost of replacing it, and plan stages so that one old platform can be retired at a time.
The UK tax authority, in the government’s own review of January 2025: it “relies heavily on costly third-party services to maintain outdated systems”.	We make no comment on the authority, and we do not take over upkeep or supply staff. For applications on technology we read, we write down what each one does, and replace it in stages 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 count where your team’s year goes, and plan the stages so that each one ends with an old platform your own team can switch off.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →