"Who Said It Was Ready?" Is a Question to Answer Before Go-Live, Module by Module.

Three weeks after go-live, the board meets with one item on the agenda.

Dispatch is running at half its usual rate. The finance head reports that every milestone in the contract was signed off and every invoice has been paid. The supplier has written to say the system was delivered to the agreed requirements.

The managing director asks who, on the company’s side, said the system was ready. There is a signature on a go-live form. The person who signed it says they were told all the tests had passed.

What We Found

For this article we went through the public record on what follows a failed go-live: a lawsuit announced in 2025 and a company’s own filing on the quarter after its change of systems.

By the time it is argued about, the fees have been paid. 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 in a case that, at our last check on 14 October 2026, had not been decided. We take no view on them, and we name neither party.

The cost lands on the manufacturer first. Whatever is decided about fault, the first bill is the firm’s own. After a large US food manufacturer moved to a new ERP system, it reported net sales more than 100 million US dollars lower, and net income tens of millions lower, in one quarter in 2024.

Fear of the day is widespread. In one survey of about five hundred IT professionals in the US, run by a firm that sells software services, more than a third named fear of disrupting operations among their reasons for not replacing old systems. That survey covers every sector, not manufacturing alone.

Our reading of these records is narrow. When acceptance is one signature at the end, the evidence that a system was ready is thin on the day and contested afterwards. Accepting the work in parts, each on evidence the firm holds itself, moves that decision to where it can still change something.

What Acceptance in Parts Opens Up

Acceptance is usually treated as the last step of a project. Our reading is that it is the board’s main control over one.

• “Ready” gets a meaning. A module is ready when its functions match the record of the old one and your own people have said so, not when a date arrives.
• Payment follows proof. Money goes out for a module that has been accepted and is in use, so the firm keeps its strongest position until it has seen the work.
• The evidence stays in the firm. What each module was checked against, and who accepted it, is on file in the company, not only in a supplier’s records.

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

Three Ways to Accept a New System, Weighed

Option	When it fits	What it risks
Milestones signed off on the supplier’s own reports, one go-live form at the end	The system is small and the supplier has a long record with the firm	Most of the price is paid before anything is in use, and the evidence belongs to the other party
An independent reviewer checks the whole system before go-live	The firm must replace everything at once and wants a second opinion	The review looks at a finished system, late, and the date still decides
A benchmark agreed before work starts, and each module accepted against it, by the firm’s own people, while the old application keeps running	The applications are the firm’s own and dispatch must keep running	It takes longer on the calendar, and the firm’s own people must give time to each acceptance

Where You Are Now, and Where You Should Be

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

Measure	Typical starting point	Where it should be	How it is checked
What “ready” means	A date and a pass rate	Each module’s functions match the record of the old one	The specification and 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: design, build, testing	When a module is accepted	The milestone tied to that module
Where the evidence is kept	In the supplier’s files	In the company’s own files, module by module	The filled-in benchmark, handed over
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
Modules still on the old applications	Not counted	Counted, and falling at every stage	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 manufacturer.

A small part of the filled-in benchmark might look like this.

Module	Checked against	Accepted by	Status
Order entry	64 functions of the old order screen	Head of customer service	Accepted; old screen retired
Stock promise and quality hold	41 functions, including the quality hold	Stores manager	Under review; old application still running
Truck loading and dispatch note	Not started	Dispatch supervisor	Waiting; old application still running

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

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

1. We listen: a free Reliability Review. A first conversation about your applications, the replacement plan 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.
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 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. 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. Accepting in parts takes your people’s time at every module, and the work takes longer on the calendar than one go-live. A module that was accepted can still disappoint later; acceptance on evidence makes that less likely, and we promise nothing more. We do not keep the old applications running or secure them in the meantime; your own team or supplier does. We do not install, configure, upgrade or change a packaged ERP product, and we do not work on plant control systems or machines. We give no legal advice: how a contract, a dispute or a claim should be handled is for your lawyers. We have no published case of this work for a manufacturer.

At the end you hold the specification, the traceability matrix for every module we rebuilt, and a filled-in benchmark that shows who accepted each module, and against what.

What changes for the business:

Role	What they gain
CEO	The board can ask who said it was ready, and get a name and a record for each part, before anything goes live.
CTO or CIO	The head of IT never has to declare a whole system ready on memory; each module is accepted on its own record.
CFO	Money leaves for a module that is accepted and in use, so the firm keeps its strongest position until it has seen the work.
COO	Stores, dispatch and customer service accept their own module, and the old application stays behind it until they do.
Head of risk	Evidence of every acceptance held in the company’s own files, not in the supplier’s.

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

The case	What IOanyT does
A global medical devices company has sued the services firm behind its ERP go-live; by its own law firm’s announcement in 2025, it had paid close to 100 million US dollars in fees and seeks well over 100 million. These are allegations in a case not decided at our last check (14 October 2026).	Our part is far narrower than this case. We do not install packaged ERP products, we take no view on the dispute, and we give no legal advice. For a manufacturer’s own applications, each module is accepted against a benchmark agreed before work starts, and billed by milestone, each milestone tied to a module you accept.
After its move to a new ERP system, a large US food manufacturer reported net income tens of millions of US dollars lower for the quarter.	The same limit applies, and we draw no cause from the record. For a manufacturer’s own applications, we never do a single cutover.

IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. We agree what “ready” means before the work starts, so the answer is on file before anything goes live.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →