When a Go-Live Costs a Quarter's Sales

1. At a Glance

Issue study · From the public record. No organisation is named here. None of the firms described was an IOanyT client, and IOanyT had no part in the events described. Everything about them comes from the public record.

Organisation type	Large manufacturers that changed their business systems on a go-live date: a food manufacturer as the main case, set beside older cases from snack, fresh-produce and confectionery makers and one lawsuit
Size band	The firms in the record: large. Our reader: a mid-size manufacturer whose order, stock and dispatch applications were built in-house or by a partner, beside a packaged ERP
Region	The main case: the US. The older cases: the US and Europe. None from India
The decision at stake	Whether, and how, to replace old order, stock and dispatch applications when the only plan on offer is one go-live date
The public outcome	After its move to a new ERP system, the food manufacturer reported that it could not see its finished stock at its warehouses, which cost it more than 100 million US dollars in sales, and tens of millions in profit, in one quarter in 2024
Why it matters to a mid-size manufacturer	The cost of a go-live lands in sales, in the same quarter. That is why old applications are kept another year, and why the question is how to replace them without such a day

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

“Everyone agrees the order and dispatch system is past its time. It was written for us fifteen years ago and only two people really understand it. But every time we plan the replacement, the plan has a go-live weekend in it, and I have read what happens to firms whose dispatch stops for a week. So we put it off another year, and add another customer rule to the old system in the meantime. I do not need a new system as much as I need a way to change the old one without betting the quarter.”

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

The firm is caught between applications it knows it must replace and a replacement plan it cannot afford to get wrong. Staying looks safer every year, and each year adds more to what the eventual go-live must carry.

3. What We Found

Method. We went through the public record on manufacturers whose results fell after a new system went live: a company’s own filing, press accounts of go-lives from the late 1990s to 2024, a law firm’s announcement of a lawsuit in 2025, and one survey on why firms keep old systems.

A move that hid the finished stock. A large US food manufacturer moved to a new enterprise resource planning (ERP) system. The figures are from the company’s own filing for one quarter in 2024.

What	Public record
What the company reported	It could not see its finished stock at its warehouses
What the company tied the loss to	Fewer orders filled in full
Effect on sales	Lower order fulfilment cut its sales volume growth by several percentage points, and its net sales by more than 100 million US dollars
Effect on profit	Net income and operating profit each down by tens of millions of US dollars
Period	One quarter
Why it happened	Not examined by us; we draw no cause from the record

Older go-lives, in the same shape. These are older cases, from one press article about go-lives of packaged ERP products. Some of the accounts give a cause; we did not examine why any of them went wrong, and draw no cause from it.

Firm	Year	Public record
A US snack maker	2022	Lost out on millions of US dollars in sales and in operating income
A fresh-produce supplier	2021	No longer knew for sure how much stock it had on hand; a drop in gross profit of more than 20 million US dollars in the quarter after go-live, which it put mainly down to the ERP problem (a poor harvest is also noted)
A large European confectionery maker	2018	A sharp fall in sales of its best-known product that year
A large confectionery maker	Late 1990s	An ERP go-live left it unable to ship a large volume of orders in its busiest season, and its quarterly profits fell

A go-live that reached a court. In 2025, the law firm acting for a global medical devices company announced that the company had sued the services firm that did the work on its packaged ERP go-live. The announcement says the company seeks well over 100 million US dollars and had paid close to 100 million in fees, and claims further damages for fixing the system and for business disruption. These are one side’s allegations. At our last check, on 14 October 2026, the court had not decided the case. We take no view on the dispute, name neither party, and do not repeat the cause the announcement alleges. We use it for one narrow point: by the time such a matter is argued, the fees have been paid.

Why firms do not start. In one survey of about five hundred IT professionals in the US, run by a firm that sells software services, half said the biggest reason they had not upgraded was that the current system still works, and more than a third each named fear of disrupting operations and data migration concerns. The survey covers every sector, not manufacturing alone.

Our reading of why a go-live costs a quarter. These four are our reasoning from the record above. None is a finding of any source.

1. Nobody has a written record of what the old applications do. The new system is built from workshops and memory, and the exceptions people forgot appear after go-live.
2. Everything changes at once. Because orders, stock and dispatch are joined, they are switched on one date, with the old system turned off and no way back.
3. The new system is checked against a document, not against the old system. A rule missing from the requirements is missing from the checks in the same place.
4. Acceptance comes once, at the end. One form declares the whole system ready, on reports from the firm that built it.

4. The Options a Firm in This Position Had

Option	When it fits	What it risks	Our view
Keep the old applications another year	They still do their job and nothing outside forces a change	The list of what they do stays unwritten, and the decision returns next year, larger	Right only as a pause with an end date
Replace everything on one weekend	The applications are small, simple and well documented	Every function nobody listed arrives on the same Monday, at the dispatch desk	We would advise against this for old, much-changed applications that nobody has written down
Replace one module at a time, beside the old applications	The applications are the firm’s own, and dispatch must keep running	Two systems run side by side, and keeping orders and stock in step between them is real engineering	Right, once the old applications are written down
Write down what the old applications do first, then replace one module at a time	The applications are old, much changed, and nobody holds a full list of their rules	Costs money before anything changes; the list may be longer than expected	Our recommendation

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

For the order, stock and dispatch applications a manufacturer built or had built beside its ERP: write down what they do first, from their code, and have the firm’s own people confirm it. Then replace them one module at a time, beside the old ones, checking each new module function by function against that record. Each module is accepted by the firm’s own people against a benchmark agreed before work starts, and paid for by milestone once accepted. The old applications keep running until each module is accepted; the firm’s own team or supplier keeps them running. The packaged ERP itself is not part of this work.

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 manufacturer’s own figures, taken in the first review.

Measure	Typical starting point	Where it should be	How it is checked
What the old order, stock and dispatch applications do	Known to the people who use them	Every function written down, including the exceptions, confirmed by your own people	The specification
Steps of the chain that change on one date	All of them, on one weekend	None: one module at a time	The staged plan
What each new module is checked against	A requirements document	The old module’s functions, one by one	The traceability matrix
Who accepts	One signature for the whole system	Your own people, for each module, in writing	The record of each accepted module
When money is released	At milestones of effort	When a module is accepted	The milestone tied to that module
The way back if a module disappoints	None: the old system is switched off	The old application still running until the module is accepted	Reported at every review

7. How IOanyT Would Work

1. We listen: a free Reliability Review. A first conversation about your applications, the replacement that keeps being put off, and how it would be accepted. 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 and dispatch applications you built or had built beside your ERP. 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 order, stock and dispatch applications, each new module checked against the record of the old one. 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 order, stock and dispatch applications do, in writing, confirmed by the firm’s own people.
• The risk register: what the assessment found, listed before any price is set, including rules nobody owns, listed for the business to decide.
• 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. No runtime or platform fee.
• The filled-in benchmark: each measure, where it started and where it stands, and who accepted each module.

9. What This Approach Does Not Cover

• IOanyT does not install, configure, upgrade, change or move a packaged ERP product, and is not a partner of any ERP maker. Its work is on the applications a manufacturer built or had built beside its ERP. Every case in section 3 was a packaged ERP go-live, so IOanyT’s part is far narrower than any of them.
• IOanyT does not work on plant control systems, machine software or shop-floor control systems.
• IOanyT does not keep the old applications running or secure them during the replacement, and does not host them. The manufacturer’s own team or supplier does.
• IOanyT does not clean, correct or move data as a stated service, train staff or manage change, or run load tests. Keeping orders and stock in step while old and new run side by side is part of the engineering of each stage and is agreed at scoping.
• A record of what the old system does shows what it does, not whether it is right. Deciding about an old rule is the business’s.
• IOanyT gives no legal advice. How a contract, an acceptance clause or a dispute should be handled is for the manufacturer’s lawyers. This study takes no view on the lawsuit in section 3.
• This study does not say IOanyT would have prevented the events described, or that IOanyT has done this work for a manufacturer. IOanyT has no published case of this work for a manufacturer.

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

10. Sources

Source	Used for
The food manufacturer’s company filing, 2024	The main case: finished stock that could not be seen, and the quarter’s sales and profit
CIO.com, 2025	The older go-lives: the snack, fresh-produce and confectionery makers
The claimant’s law firm, 2025	The lawsuit, as one side’s allegations
A vendor’s survey of US IT professionals, 2025	Why firms keep old systems

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 with what the old applications do, so that no single day has to decide the quarter.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →