A Replacement You Can Pause Is One You Can Start. The Measures to Hold It To.

The steering group meets on the first Monday of the month. The report on the screen says the replacement is seventy-two per cent complete.

The head of operations asks which parts of it the stores can use today. None, comes the answer: everything goes live together. The go-live date has moved twice. The budget line shows how much has been spent, and nobody can say how much of what was bought is working.

Someone asks whether the project could stop for a quarter. The supplier says no: none of it is finished, so stopping would lose it all.

What We Found

We looked at what the public record says about go-lives that went wrong in businesses with a busy season, and at one large grocer’s recent replacement.

A go-live in the busy season can cost that season. The one record we found that ties a go-live to a busy season is very old and is not a retailer. A large confectionery maker’s ERP go-live in the late 1990s left it unable to ship a large volume of orders in its busiest season, and its profits fell.

A new system can fail at launch. When a large retailer expanded into a new country over a decade ago, it ran on a packaged ERP system, and its supply chain collapsed after launch. It was a new business on a new system rather than a replacement, and it is an older case.

A change to many systems can reach the shelves. A large UK grocer moved off thousands of older systems it had shared with a former owner, onto a packaged ERP product. Its sales in the second half of 2025 were hit by disruption to what was on the shelves and to shopping online.

All three were packaged ERP products at very large firms, and in each a great deal changed at once. None is the kind of work we describe below.

What a Replacement in Accepted Modules Opens Up

A staged plan is usually sold as a safer plan. Our reading is that it first changes what the business can measure and decide.

• Progress becomes something you can use. A module accepted and in use is progress. A percentage complete is not.
• Spend can be read against what it bought. Each stage has its price, set beside the quote, and each accepted module shows what that price paid for.
• Stopping becomes a choice. After any accepted module the business can pause, and keep what it has. Nothing finished is lost.

The work may cross more than one busy season before it is done. A staged plan is not a faster plan, and on any given peak some parts will be new and others old. What it removes is the single date on which everything changes.

This is our reading. It is not a measured market figure.

Three Ways to Hold a Replacement to Account, Weighed

Option	When it fits	What it risks
Report percentage complete against one go-live date	The project is small, and one date for everything is safe	Nothing is usable until the end. A late part delays the whole, and stopping loses everything spent
Report by phase, with each phase going live on what people remember the old system did	The phases are well separated and well understood	Each phase can be measured, but a gap is found only after it goes live
Write the specification first, then accept modules one at a time, each priced beside its quote and proven against the old system	The application is the firm’s own, much changed, and the business cannot stop trading	It takes stages and costs money before new code is written. The work may cross more than one peak, and old and new run side by side for longer

Where You Are Now, and Where You Should Be

This is the benchmark we would set before the first module is built, and fill in as each module is accepted.

Measure	Typical starting point	Where it should be	How it is checked
Price of each stage	One figure for everything	A price for each stage, set beside its quote	The staged plan, and spend reported against each quote at every review
Progress	Percentage complete	Modules accepted one at a time, each in use	Acceptance recorded for each module
Single cutovers	One go-live date for everything	None	The staged plan
Behaviour of each module	Tests written from what people remember	Every old function linked to its replacement and proven against the old system before it takes over	The traceability matrix
Where the business can stop	Nowhere without losing what was spent	After any accepted module, keeping what was accepted	The staged plan and the milestone record
Share of the old system still running	All of it until go-live, then none	Falling module by module, with the old system there until each module is accepted	Reported at every review

The starting points above are what we expect to find. In an engagement they are replaced by your own position, 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 retailer.

A small part of the finished record might look like this.

Module	Price beside its quote	Proven against the old system	Status
Returns rules	Within its quote	Two months of returns run through old and new, totals matched	Accepted by the customer service lead; in use
Trade-order pricing	Within its quote	Each trade customer’s price list compared, line by line	Accepted by the finance head; in use
Warehouse pick lists	Quoted, not started	Not yet	The business chose to pause here before the next stage

The rows above are an illustration, not taken from a real system.

How We Work With You, and What You Are Left With

1. We listen: a free Reliability Review. A first conversation about the replacement, how its progress is reported, and whether it could stop. 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 order, stock or trade application you built or had built. It produces 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. Here that means your own application, rebuilt beside the old one on technology that is still supported. 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 above. As each module is accepted 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.

This has a price. The work is spread over more of the calendar and may cross more than one peak before it is finished. Old and new run side by side for longer, which has a cost and needs stock and orders kept in step between them. A traceability matrix shows that a module does what the old one did; it does not show how the module behaves at the heaviest volume, and we do not run load tests as a stated service. We do not keep the old system running; your own team or supplier does. We do not implement packaged ERP products or shop platforms, and every case above was one. We do not train store or warehouse staff or manage the change in how people work. We have no published case of this work for a retailer.

At the end you hold the specification, the traceability matrix for every module we rebuilt, and the filled-in benchmark. Switching off each part of the old system is your team’s decision.

What changes for the business:

Role	What they gain
CEO	The board approves one module at a time, each with its price, and can stop after any accepted one.
CTO or CIO	Each module is proven against the old system, function by function, before it takes over.
CFO	Spend is read against accepted modules at every review, so the board knows what it has for the money.
COO	Stores and warehouses take each change as one module that was checked against the old system first.
Head of marketing	No campaign has to share its week with a single cutover, because there is none.

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

The case	What IOanyT does
A large confectionery maker’s ERP go-live in the late 1990s left it unable to ship a large volume of orders in its busiest season.	Our part is far narrower: that was a manufacturer installing packaged products, which we do not do, and we do not say why it went wrong. For applications a firm built, we replace one module at a time, each proven against the old one and accepted before it takes over.
A large retailer’s supply chain collapsed after it expanded into a new country on a packaged ERP system, over a decade ago.	We do not implement packaged ERP. For an application a retailer built, each module is matched to the old one with a traceability matrix and accepted by its users, with the old system still 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 set the benchmark before the first module is built, so progress is something you can use.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →