Leaving Your Supplier Does Not Have to Be One Handover Day. Here Is the Benchmark We Would Set.

The steering committee has the transition plan in front of it. After twelve years, the department is to move its licensing system from the present supplier to a new one.

One line in the plan draws every eye. Transition: one weekend in April. The old contract ends on the Friday. The new system starts on the Monday.

The head of IT pictures that Monday. A fault appears in the fee calculation. The old supplier’s team has moved to other work. The new supplier has known the system for five months. The committee defers the decision, and the old contract is extended.

What We Found

For this article we went through the public record on how long it takes public bodies to move off old systems: the US national auditor’s July 2025 report on the most critical federal legacy systems and press coverage of it, the UK government’s own review of its digital services, published in January 2025, and UK trade press reporting in 2025 on a supplier-built system at a large UK public body.

First, what we did not find: no public case of an Indian public body, or of a body of our readers’ size, moving off a supplier’s system, and nothing from the Middle East. The bodies below are far larger than the departments and boards we write for.

Moving off old systems takes years, even at the top. Six years after the US national auditor named the 10 most critical federal legacy systems in 2019, press coverage of its July 2025 report found that 3 of those modernisations had been completed. The auditor’s lists include systems written in COBOL and assembly language, which are not our kind of work.

Dates move. For one of those systems, at the US health department, officials told the auditor in March 2025 that they now expect to complete the modernisation in fiscal year 2035, five years later than the original plan. The officials put the change down to funding availability for the project.

A supplier-built system can stay long past its planned replacement. UK trade press reported in 2025 that a large UK public body’s supplier-built system, more than 25 years old, may now run into the 2030s, later than its planned replacement, a possibility rather than a fixed date. We did not examine why the date moved and draw no cause from it.

Arrangements last a decade. The UK government’s own review found that councils’ children’s social care systems come from 3 main providers, and are used for a median of 10 years. Those are packaged products, which are not our kind of work.

Our reading: when leaving is planned as one step on one date, it is a step a public body can rarely afford to get wrong, and so it is put off. The records above do not tie any delay to one-step planning; the one reason given is funding. Our point is narrower: a plan with no single handover day removes one reason to wait.

What a Staged Exit Opens Up

The usual view is that a change of supplier is one transition, on one date, set by the old contract. Our reading is that a body which leaves one module at a time opens up three things the single handover cannot.

No single day carries the service. The old system keeps running while each module moves, so a module that is not ready waits.

Proof before acceptance. Each module is checked, function by function, against what the old system did, before anyone accepts it.

A decision after each module. After each accepted module the body can continue, or pause. At no point does the service rest on a firm that has just arrived.

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

Four Ways to Leave, Weighed

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

Option	When it fits	What it risks
One switch-over on the day the old contract ends	The system is small, well described, and a short outage would not stop a public service	Everything rides on one date, and the old supplier’s knowledge leaves just as it is needed
One new long contract for a complete replacement, built and switched over at the end	The body has a full description of the system and the funding for several years is assured	A single cutover at the end, and a new dependence on one firm for another decade
Build a complete new system beside the old one, then switch everything at once	The body can fund both systems for the whole build	Two systems paid for throughout, and the switch-over risk only postponed
Leave one module at a time, with the old system still running under the present supplier until the last module has moved	The service cannot stop, and the body wants proof at each step	The first step is an assessment that costs money before anything moves; the present supplier must keep running the old system while modules move; for a time the body pays two firms; each stage must still be sanctioned

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
A description of the system	Held by the supplier only	A specification the body owns, confirmed by its own officers	The specification
The cost of leaving	Unknown until after the end date, if ever	Known before the end date, set beside the cost of staying	The cost comparison
A specification other suppliers can price from	None; the system is described in one line	A specification the body can show to other suppliers, subject to its own contract with its present supplier, with each stage described	The specification and the staged plan with its fixed quote
Proof that a module is done	A completion certificate signed on a switch-over date	Each module accepted, with a traceability matrix linking every old function to its replacement	The traceability matrix
The old system	Switched off on one date	Kept running by the present supplier until the last module has moved	The staged plan, updated after each module

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 the system, the contract’s end date and any transition plan already drafted. 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 the body wants to move off its present supplier. The body arranges read-only access to the code with its supplier, as its contract allows. 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 take over the running of the supplier’s system or keep it running while modules move; the present supplier does, under the body’s contract with it. We do not negotiate with a supplier, give legal advice, or obtain code or data from a supplier. We do not replace or implement packaged products. 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	A change of supplier no longer means staking the whole service on one handover day.
Head of procurement	The work can be bought one part at a time, without committing to a single supplier for another decade.
Head of IT	Each part that moves sits on technology the department controls, while the old system runs until the last part has gone.
Head of finance	Money for the exit is asked for one stage at a time, each stage with its own evidence.
Head of audit and vigilance	A record at every stage: what moved, how it was checked and who accepted it.

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

The case	What IOanyT does
The US federal government: of the 10 most critical legacy systems its auditor named in 2019, 3 modernisations completed six years later, as its auditor’s July 2025 report was covered in the press; one now expected in fiscal year 2035.	Those systems include languages we do not work in, and we make no comment on any agency. For applications on technology we read, we produce the staged, priced plan and replace one module at a time while the old system keeps running.
A large UK public body: a supplier-built system, more than 25 years old, which the trade press reported in 2025 may now run into the 2030s.	We make no comment on that body or its supplier, and we do not say why the date moved. Our part is far smaller: for a body’s own application, a way out in stages, with no single handover day.
The UK government’s own review: councils’ children’s social care systems from 3 main providers, used for a median of 10 years.	We do not replace packaged products. For applications built around them, each module we replace is the body’s, with a traceability matrix.

IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. We turn one handover day into modules, each checked and accepted before the next, while your present supplier runs the old system.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →