Manufacturers Keep Their Old Applications for One Reason. It Is the Go-Live Day.
We reviewed the public record on manufacturers whose sales fell after a new system went live. Here is what we found, why old applications are kept another year, the four ways forward, and the benchmark we would set.
It is Monday, a little after seven. The new order and dispatch system went live over the weekend.
The plant is running. At the dispatch desk, the screen says there is no finished stock for the first four orders of the day. The stock is thirty metres away, wrapped and labelled.
By nine there are six trucks at the gate. The old system was switched off on Saturday night.
The paradox: The plant can make everything it was asked for, and on the day the system changes it cannot send any of it.
What We Found
For this article we went through the public record on manufacturers whose sales fell after a new system went live: a company’s own filing, press accounts of go-lives from 1999 to 2024, and one survey on why firms keep old systems.
Four findings stand out.
The loss lands in the quarter of the change, and it is counted in sales. A large US maker of frozen potato products moved to “a new enterprise resource planning (ERP) system in North America”. Afterwards it had “reduced visibility into finished goods inventories at its distribution centers”. In its own filing, the company said lower order fulfilment “reduced sales volume growth by approximately 8 percentage points”, and net sales by about 135 million US dollars, in the quarter to February 2024.
The older cases have the same shape. In 2022, a US snack maker had problems at the go-live of a packaged ERP product and, by one account, lost out on 20 million US dollars in sales and 4.5 million in operating income. In July 1999, “in the lead up to Halloween and Christmas”, a large US confectionery maker switched on three packaged systems and was left unable to process more than 100 million US dollars of candy orders, with a “19% decline in quarterly profits”. Both are older cases, the second very old.
The damage shows at the far end of the chain. None of these records describes a plant that could not make goods. They describe goods that could not be fully seen, orders that could not be processed and sales that did not happen. A manufacturer’s systems are a chain: an order is entered, stock is promised, goods are picked, a truck is loaded, an invoice is raised. When the chain changes at once, the loss appears where the goods should leave.
Fear of that day keeps old systems in place. In one survey of 504 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 38% named fear of disrupting operations. That survey covers every sector, not manufacturing alone.
Our reading is that manufacturers do not keep their old order, stock and dispatch applications because they like them. They keep them because the only replacement they have been offered comes with a go-live day, and the public record shows what such a day can cost.
What our review does not show: Every case is a large firm, most of them in the US, and every one is the go-live of a packaged ERP product, which is not our kind of work. Two of the cases are older and one is from 1999. Some of these sources give a cause for what went wrong; we did not examine why any go-live failed, and draw no cause from it. We found no case of a manufacturer replacing an application it had built for itself, no named case from India, and no figure for what a day of stopped dispatch costs a mid-size manufacturer. The survey was run by a vendor and is not about manufacturing. That the go-live day is the usual reason old applications stay is our reasoning, not a measured finding.
What Waits While the Go-Live Day Is Feared
A replacement that keeps being put off is usually discussed as a technology delay. Our reading is that it holds the business in place.
The first cost is the year that keeps repeating. The old applications are kept for one more year, and next year the same decision returns, a little larger.
The second cost is new work built on old ground. Every new customer rule, every new warehouse and every new report is added to applications everyone agrees are past their time, and each addition is one more thing a replacement must carry.
The third is that the change, when it finally comes, comes all at once. The longer it waits, the more is switched on the same weekend.
The gap we see: most manufacturers that put off a replacement are not putting off the new system. They are putting off the day. The choice they see is between keeping the old applications and staking a quarter on one weekend. A manufacturer that can replace its own applications one part at a time, with the old ones still running, no longer has to choose between those two.
This is our reading of the evidence. It is not a measured market figure.
Four Ways Forward, Weighed
There are four real options. Each one is right for somebody.
| Option | When it fits | What it risks |
|---|---|---|
| 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 |
| 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 |
| 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 for a time, and keeping orders and stock in step between them is real engineering |
| 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 | It costs money before anything changes, and the list may be longer than anyone expected |
Our recommendation: write down what the old order, stock and dispatch applications do first. Then replace them one module at a time, beside the old ones, so that no single day decides the quarter. This is for applications a manufacturer built or had built beside its ERP. We do not install, configure or upgrade a packaged ERP product, and we do not work on the systems that control machines. While the work goes on, your own team or supplier keeps the old applications running.
Where You Are Now, and Where You Should Be
A recommendation is only useful if you can tell later whether it worked. So before any work begins we set a benchmark: a few measures taken from your own applications, each with a target.
For this issue, the benchmark would look like this.
| 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 in plain words, 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 |
| The old application while its replacement is built | Switched off at go-live | Still running until the new module is accepted | Reported at every review |
| Old functions matched to new ones | Not recorded | Each function of the old module linked to its replacement | The traceability matrix |
| Who says a module is ready | One signature for the whole system | Your own people, module by module | The record of each accepted module |
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 manufacturer.
How We Work With You
- We listen: a free Reliability Review. A first conversation about your applications, the replacement that keeps being put off, and the day everyone fears. 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 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. 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 order, stock and dispatch applications, rebuilt one module at a time while the plant goes on shipping. 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.
This approach has a price. Two systems run side by side for a time, and keeping orders and stock in step between them has to be right. The work takes longer on the calendar than one weekend. 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, which has its own maker and its own specialists, and we do not work on plant control systems or machines. The older technologies we read include VB6, Delphi, AngularJS, PHP 4 to 8, Java 8, .NET Framework and classic ASP. We have no published case of this work for a manufacturer.
What changes for the business:
| Role | What they gain |
|---|---|
| CEO | The replacement that has been put off every year can begin, without staking a quarter’s shipments on one weekend. |
| CTO or CIO | A written record of what the old applications do, so a part that is not ready stays switched off and the old one carries on. |
| CFO | No single date on which a quarter’s sales are at stake, and spend released one accepted module at a time. |
| COO | Stores and dispatch change one process at a time, and finished goods stay in sight throughout. |
| Head of risk | The largest operational risk in the year’s plan becomes a series of small ones, each with the old system still running behind it. |
The cases in this article, and what IOanyT does about that kind of problem:
| The case | What IOanyT does |
|---|---|
| After its move to a new ERP system, a large US frozen-food maker had “reduced visibility into finished goods inventories at its distribution centers”, and reported net sales about 135 million US dollars lower for the quarter. | Our part is far narrower than this case. We do not install packaged ERP products, and we draw no cause from the record. For applications a manufacturer built beside its ERP, we replace one module at a time while the old one keeps running. |
| A US snack maker lost out on 20 million US dollars in sales after go-live problems in 2022. | The same limit applies. For a manufacturer’s own applications, we never do a single cutover. |
| A large US confectionery maker switched on three packaged systems in July 1999 and could not process more than 100 million US dollars of orders. | The same limit applies. We write down what the old applications do before anything changes, and each new module is checked against it. |
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, because that is what a go-live day leaves out.
Sources
In this issue
Replacement goes wrong at go live