Every Retail Replacement Story You Have Heard Is One Kind of Project. Yours Probably Is Not.
We reviewed the public record on retail systems replacements that cost a great deal and disturbed trading. Every named case is one kind of project. Here is what we found, why firms wait, the options, and the benchmark we would set.
The board has discussed replacing the order and stock system three years running. Everyone agrees it is past its time.
This year the technology head presents a plan. Eighteen months of building, then a switch-over on one weekend in spring. The founder asks a single question. What happens on the Monday if the stores cannot see their stock?
There is a pause. The old system will have been switched off. The item is carried forward to next year.
The paradox: The system is too old to keep, and the stories that keep it in place come from projects that look nothing like the one on the table.
What We Found
For this article we went through the public record on retail systems replacements that cost a great deal or disturbed trading: a large grocer’s reported figures, two older and much-told failures, and one survey of why firms do not replace old systems, from the late 1990s to 2026. Four findings stand out.
A replacement 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 on a public cloud. By the end of 2025 the work had cost it more than £1 billion. Its sales in the second half of 2025 were hit by disruption to what was on the shelves and to shopping online, and its leadership said the work delayed its recovery. This was a packaged ERP product at a very large firm.
The best-known failures are old, and they are packaged products too. When a large retailer expanded into a new country over a decade ago on a packaged ERP system, its supply chain collapsed after launch. That was a new business on a new system, not a replacement, and it is an older case. The one record we found that ties a go-live to a busy season is older still 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.
Firms that wait mostly say the old system still works. In one survey of about five hundred IT professionals in the US, half said the biggest reason they had not upgraded was that the current system still works. Fear of disrupting operations was named by more than a third. The survey covers many sectors and was run by a firm that sells software services.
Every named case is the same kind of project. All three are packaged ERP products put in at very large firms, each changing a great deal at once. We found no public case of a retailer replacing an application it had built.
Our reading: the fear is real, but it comes from projects of one shape, and a retailer replacing its own application need not take that shape.
What our review does not show: We did not examine why any of these projects cost what it did or disturbed trading, and we draw no cause from them. Where reports give reasons, they are accounts of packaged ERP programmes at very large firms, and we do not repeat them as lessons for a different kind of work. We found no named mid-size retailer, no Indian or Middle Eastern case, and no figure for what a day of disrupted trading costs a mid-size shop. That a staged replacement of a retailer’s own application fares better is our reasoning, not a measured finding.
What Waits Behind “Not This Year”
A deferred replacement looks like a decision not to spend. Our reading is that it also keeps three things as they are.
The first is the switch-over weekend. While the only plan changes everything on one date, the founder’s Monday question has no good answer.
The second is the old system’s knowledge. The returns rules, the overnight jobs that feed the warehouse, the odd price for one trade customer live in the code and in a few people’s heads, and each year fewer of those people remain.
The third is the next idea. A new channel or loyalty scheme is built on the old system or not built at all.
The gap we see: most retailers can say that their old system works. Few can say what it does, part by part, and which part could change first. A retailer that holds that list can choose small, checked steps. One that does not chooses between a single weekend and another year.
This is our reading of the evidence. It is not a measured market figure.
Four Ways to Replace a System That Trades Every Day, Weighed
There are four real options. Each one is right for somebody.
| Option | When it fits | What it risks |
|---|---|---|
| Put in a packaged system all at once | The business runs close to the way the product expects, and can bear one large change | Everything changes on one date. What nobody listed is found on the shop floor |
| Keep the old system and patch around it | The system is stable, its experts are still there, and little new is planned | The knowledge leaves with the people, and new ideas wait |
| Replace in phases without first writing down what the old system does | Parts of the system are well understood and well separated | Each phase rests on memory. Gaps appear one phase at a time, after go-live |
| Write the specification first, then replace module by module, billed by milestone | The application is the firm’s own, much changed, and the business cannot stop trading | It costs money before anything new is built, takes longer on the calendar, and old and new run side by side for a time |
Our recommendation: write the specification first, then replace the application module by module, with the old system still running and each module accepted before it takes over. The work is billed by milestone, and you can pause after any accepted module. This is for applications a retailer built or had built. We do not implement packaged ERP or shop platforms, which is what every named case involved, and we do not train store staff or manage the change in how people work.
Where You Are Now, and Where You Should Be
Before any work begins we set a benchmark: a few measures taken from your own system, each with a target.
| Measure | Typical starting point | Where it should be | How it is checked |
|---|---|---|---|
| What the old system does | Known to the people who wrote it, and partly remembered | Every rule, report, job and connection in scope written down in plain words | The specification |
| Switch-over days | One weekend for everything | None: one module at a time takes over | The staged plan |
| How a module is shown to be ready | Tests written from what people remember | Each old function linked to its replacement and checked against the old system | The traceability matrix |
| Who says a module is ready | The project plan’s date | Your own people, module by module | Acceptance recorded for each module |
| Share of the old system still running | All of it until the switch, 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 the public record suggests and 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 retailer.
How We Work With You
- We listen: a free Reliability Review. A first conversation about the system, the plan on the table, and the question that keeps it there. 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 order, stock or trade application you built or had built. 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. Here that means your own application, rebuilt beside the old one on technology that is still supported. 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 implement packaged ERP products or shop platforms, and every case in this article was one. We do not keep the old system running or secure while the work goes on; your own team or supplier does, at your cost. We do not train store or warehouse staff or manage the change in how people work. We do not host. The older technologies we read include VB6, Delphi, AngularJS, PHP 4 to 8, Java 8, .NET Framework and classic ASP; PHP is a language we read, not one we build in. We promise no trading result, and we have no published case of this work for a retailer.
What changes for the business:
| Role | What they gain |
|---|---|
| CEO | The replacement that has been put off every year can begin, because no single day puts trading at stake. |
| CTO or CIO | A part that is not ready stays switched off, and the old system is still there. Nobody repairs a live shop in front of customers. |
| CFO | The year’s sales are not staked on one switch, and a stage that disappoints can be paused without writing off the rest. |
| COO | Stores and warehouses change one process at a time, never everything on one Monday. |
| Head of marketing | Promotions are planned beside one module’s change at a time, never beside a switch of everything. |
The cases in this article, and what IOanyT does about that kind of problem:
| The case | What IOanyT does |
|---|---|
| A large UK grocer moved off thousands of older systems onto a packaged ERP product, and its sales were hit by disruption to what was on the shelves. | Our part is far narrower than this case. We do not implement packaged ERP products, and we do not say what caused that disruption. For applications a retailer built or had built, we replace one module at a time with the old system still running, and each module is accepted before it takes over. |
| 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. For an application a firm built, we write down what the old one does first, and match each function in the new module. |
IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. We start by writing down what your own system does.
Sources
- Trade press, 2026
- Trade press, 2025
- A vendor's survey, 2025
In this issue
Replacement is costly and disruptive
Research note 2
The Cost of Waiting Belongs Beside the Fear of Replacing. Four Ways Forward, Weighed.
Retailers price replacing an old system but leave the cost of keeping it blank. What waiting costs, a fixed date that will not wait, four options weighed.
Research note 3
A Replacement You Can Pause Is One You Can Start. The Measures to Hold It To.
Percentage complete tells a board little. The benchmark we would set for a retail replacement: accepted modules, a price per stage, and a point to pause.
Issue study
Replaced All at Once
Retail system replacements that cost heavily and disturbed trading, why firms wait, the one fixed date that does not, the options and our benchmark.
More from Retail
Old php and databases under the shop
A Few Old Parts Hold the Whole Shop on an Old Version. Everything Else Waits With Them.
Accounts and systems held by someone else
A Firm That Does Not Hold Its Own Systems Cannot Plan a Move.
Wrong or unreliable data