Replaced All at Once

1. At a Glance

Issue study · From the public record. None of the organisations described here was an IOanyT client, and IOanyT had no part in the events described. Everything about them comes from the public record. Every public case is a packaged ERP product put in at a very large firm, which is not IOanyT’s kind of work.

Organisation type	A large UK grocer moving off systems it had shared with a former owner, onto a packaged ERP product; beside it, a large retailer’s expansion into a new country over a decade ago and a large confectionery maker’s go-live in the late 1990s, both on packaged products
Size band	The cases: very large. Our reader: a mid-size retailer, brand or distributor with an order, stock or trade application of its own
Region	The main case: the UK. The older cases: not given here. The fixed date in section 3: Saudi Arabia
The decision at stake	Whether, and how, to replace an old system in a business that cannot stop trading, when every story the board has heard is of a replacement that cost a great deal and reached the shelves
The public outcome	The grocer’s work cost more than £1 billion by the end of 2025; sales in the second half of 2025 were hit by disruption to what was on the shelves and to shopping online; its leadership said the work delayed its recovery
Why it matters to a mid-size retailer	The fear these cases leave behind keeps many old systems in place. The cases are of one shape; a retailer’s own application does not have to be replaced in that shape

2. The Business Problem, in the Buyer’s Words

“Every year the replacement of the order and stock system comes to the board, and every year we put it off. Everyone has read about the grocer whose shelves emptied after its systems changed. Our plan is eighteen months of building and one weekend to switch, and nobody can tell me what happens on the Monday if the stores cannot see their stock. Meanwhile the one developer who understands the returns rules is talking about retiring. I know the old system has to go. I do not want to bet a year’s trading on one weekend to get rid of it.”

These words are imagined. They describe the decision as the research shows it, not a real conversation.

The firm is caught between an old system that still works and a replacement plan of the only shape it has heard of: everything at once.

3. What We Found

Method. 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, one survey of why firms do not replace old systems, and one tax authority’s announcement of a fixed date, from the late 1990s to 2026.

The main case: a separation that reached the shelves. A large UK grocer moved off systems it had shared with a former owner, to a packaged ERP product on a public cloud.

What	Public record
Scale	Thousands of older systems
Cost	More than £1 billion by the end of 2025
Effect on trading	Sales in the second half of 2025 were hit by disruption to what was on the shelves and to shopping online
What its leadership said	The work delayed its recovery
Kind of project	A packaged ERP product at a very large firm

Two older cases. 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. A large confectionery maker, not a retailer, had an ERP go-live in the late 1990s, in the run-up to its busiest season, that left it unable to ship a large volume of orders in that season, and its profits fell. It is the one record we found that ties a go-live to a busy season.

Why firms wait. 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. Budget limits were named by more than two in five, and fear of disrupting operations by more than a third. The survey covers many sectors and was run by a firm that sells software services.

A date that does not wait. Saudi Arabia’s tax authority announced on 24 July 2026 that its e-invoicing Wave 25 covers “taxpayers whose revenues subject to VAT exceeded (SAR 187,500) during 2022, 2023, 2024 or 2025”, who will be notified to integrate their e-invoicing solutions with its platform “by no later than February 1, 2027”. Our reading, and only that: a seller whose old billing system reaches its accounts only by an export may find that this date arrives before any replacement is ready.

Our reading of why replacements of this kind cost a great deal and disturb trading. These four are our reasoning from the shape of the record. None is a finding of any source, and none is offered as the cause of any public case.

1. Nobody holds a written record of what the old system does, so the new one is built from memory and demonstrations.
2. Everything changes at once, in a business that cannot stop trading, with no way to stop part-way.
3. The price is set before the old system has been read, so what is found later arrives as revised forecasts.
4. One date carries everything, so a late part delays the whole and the go-live slides towards busier weeks.

4. The Options a Firm in This Position Had

Option	When it fits	What it risks	Our view
Put in a packaged system all at once	The business runs close to the way the product expects, and can bear one large change on a known date	Everything changes on one date; what nobody listed is found on the shop floor	We would advise against this for a firm whose own application is much changed and poorly written down
Keep the old system and patch around it	The system is stable, the people who know it are still there, and no fixed date is near	The knowledge leaves with the people; a date set by someone else can arrive first	Right only as a bridge with an end date
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	Better than one weekend, but the gaps move rather than go
Write the specification first, then replace module by module, billed by milestone, with a pause after any accepted module	The application is the firm’s own, much changed, and the business cannot stop trading	Costs money before anything new is built; takes longer; may cross more than one peak; old and new run side by side	Our recommendation

5. Our Recommendation, and the Decision It Asks of the Board

For the order, stock or trade application a retailer built or had built: write the specification first, from the system itself, with its risks listed and the cost of keeping it set beside the cost of replacing it. Then replace it one module at a time, with the old system still running, each module proven against the old one with a traceability matrix and accepted by the retailer’s own people before it takes over. Each stage has a price, set beside its quote. The work may cross more than one peak, and the retailer can pause after any accepted module. The retailer’s own team or supplier keeps the old system running until each module is accepted.

6. Benchmark: Where You Are Now, and Where You Should Be

These are targets, not results. In an engagement the starting points are replaced by the retailer’s own figures, taken in the first review.

Measure	Typical starting point	Where it should be	How it is checked
What the old system does	Known to the people who wrote it	Every rule, report, job and connection in scope written down in plain words	The specification
The cost of waiting	The support fee alone	Set beside the cost of replacing, line by line	The cost comparison
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
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	The traceability matrix
Where the business can stop	Nowhere without losing what was spent	After any accepted module	The staged plan and the milestone record

7. How IOanyT Would Work

1. 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.
2. We research. We research your sector, the regulator’s position and what the public record says about firms in your situation. This study 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 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.
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. 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.

8. What the Client Would Own

• The map and the specification: what the old application does, in writing.
• The risk register: what the assessment found, listed before any price is set.
• The traceability matrix: for every module IOanyT rebuilds, every old function linked to its replacement, with how it was checked.
• The code: the rebuilt modules are the client’s.
• The filled-in benchmark: each measure, where it started and where it stands.

9. What This Approach Does Not Cover

• IOanyT does not implement packaged ERP products or shop platforms, and is not a partner of any product maker. Every public case in this study was a packaged ERP product at a very large firm.
• IOanyT does not keep the old system running or secure during the replacement, and does not host it. The retailer’s own team or supplier does, at the retailer’s cost.
• IOanyT does not train store or warehouse staff or manage the change in how people work.
• IOanyT does not run load tests as a stated service. A traceability matrix shows that a module does what the old one did; it does not show how it behaves at the heaviest volume.
• IOanyT does not promise to time or reorder stages around a trading calendar. The retailer can pause after any accepted module, and the work may cross more than one peak.
• PHP is a language IOanyT reads, not one it builds in. The older technologies it reads include VB6, Delphi, AngularJS, PHP 4 to 8, Java 8, .NET Framework and classic ASP.
• IOanyT does not offer a compliance, audit or legal service, and says nothing about what tax, card-payment or data protection rules require of a particular firm. Meeting Saudi Arabia’s e-invoicing rules is the seller’s own work.
• This study does not say IOanyT would have prevented the events described, or that IOanyT has done this work for a retailer. IOanyT has no published case of this work for a retailer.

About this study: IOanyT did not work on this case. It is drawn from published findings, cited below.

10. Sources

Source	Used for
Trade press, 2026	The grocer: scale, cost, disruption, what its leadership said
Trade press, 2025	A large retailer’s expansion into a new country; a large confectionery maker’s go-live
A vendor’s survey, 2025	Reasons for not replacing old systems
ZATCA, 24 July 2026	Saudi e-invoicing Wave 25

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, so a replacement can be made of steps you can check and stop.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →