ERP migration: what it costs, why it overruns, and the alternative

Gartner predicts that by 2027 more than 70 percent of recently implemented ERP initiatives will fail to fully meet their original business case goals, and that as many as 25 percent will fail catastrophically. Panorama Consulting's 2026 ERP Report, drawn from 170 organizations, found more than a quarter of projects over budget and almost a quarter over schedule, against a median timeline of nine months. Those are the odds a CFO accepts when the answer to a process problem is an ERP migration. Most of the time the migration is launched because the work between systems has stopped working, and that is a different problem with a cheaper fix. This piece sets out what a migration involves, what it costs, why it overruns, and when a layer on top of the system you have is the better answer.

What an ERP migration involves

An ERP migration moves the system of record. The ledger, the order book, inventory, purchasing and the customer master leave one platform for another, and everything that touched the old platform has to be rebuilt against the new one. Five pieces of work follow from that. The data has to be cleaned and moved, which is where a decade of duplicate vendors and half-closed orders surfaces. The processes that run through the system have to be redesigned to fit it, because the new platform will not run the old workarounds. Integrations with the CRM, the bank, the warehouse system and the payroll provider have to be rebuilt. People have to be trained on screens they did not choose. And on the cutover date the old system stops, so every one of those pieces has to be finished at the same time. An upgrade keeps the platform and changes the version. A migration changes the platform, and that is why it carries the risk it does.

What it costs and why the budget slips

Panorama's respondents had a median revenue of about $200 million, which is the mid-market company this blog is written for. More than a quarter of them reported their project over budget, and the most common cause was the unexpected need for additional technology: a reporting layer the chosen system could not provide, an integration nobody had scoped, a custom build to cover a gap discovered late. Almost a quarter were over schedule, and there the most common cause was organizational rather than technical: governance, resistance to standardizing processes, sign-offs that trailed the build. Fewer than a quarter of organizations reported an intense focus on change management. Panorama's own reading is that benefits tied to a new operating model were the hardest to realize, because leaders spent their attention making existing processes run faster rather than changing how decisions were governed. The pattern is consistent across the report. The software gets delivered; the process work around it is what slips, and the process work was the reason for the project.

Two failures every CFO knows

Lidl went live with SAP in its Austrian stores in May 2015, intending to roll the system out to 10,000 stores and more than 140 logistics hubs. In 2018 it stopped. Computer Weekly reported that the retailer dropped the project after spending around 500 million euros, with a memo reportedly sent to staff by Lidl's chief executive, Jesper Hoyer, saying that the project's strategic goals could not be reached without spending more than the company was willing to. Three years after go-live and half a billion euros in, the project was over.

Revlon's failure was smaller in money and larger in consequence. The company launched a new SAP ERP system in the United States in February 2018, and its own annual report records that the launch disrupted its Oxford, North Carolina plant so badly that it could not fulfil about $64 million of shipments that year and spent $53.6 million on remediation, with the plant back at pre-SAP output only by December. The following year's filing reports that management identified a material weakness in internal control over financial reporting as of 31 December 2018, primarily as a result of the ERP implementation, and remediated it during 2019. Shareholders filed a class action, which Computer Weekly reported in May 2019. A cosmetics company could not ship product because its system of record changed underneath its plant. In both cases the software worked somewhere else. What failed was the process work that a migration forces a company to do all at once, on a deadline, with the old system switched off.

The problem underneath the migration

Ask why a mid-market company decides to migrate and the answers are about work, not software. The close takes three weeks because the ledger, the bank and the subledger disagree and someone reconciles them by hand. Orders are keyed twice, once into the CRM and once into the ERP. Invoices arrive as PDFs and a clerk types them in. The ERP gets the blame because it is the system everyone sees, but the hours are being spent between systems, in the manual steps that move data from one to the next. The McKinsey Global Institute's automation research found data collection and data processing among the activities most open to automation, and those steps are exactly that. A migration replaces the system and leaves the steps, which is one reason Panorama's respondents found operating-model benefits so hard to realize: the platform changed and the work did not. Documented processes had drifted long before the project started, as we set out in why documented processes rot, and a migration inherits that drift as scope.

The alternative: a layer on top of the system you have

An AI layer on top of your existing systems. No migration, no IT project. That is what we build, and the mechanism is simple to state. An agent reads from and writes to the systems the company already runs, including a legacy ERP with no API, which we explain in writing back to legacy systems without an API. It takes over the manual steps between systems: matching the invoice to the order and the receipt, applying the cash, entering the order once, reconciling the accounts at close. The exceptions still route to a person, logged and reversible, under the controls for autonomous agent actions. The system of record stays where it is. What the company gets in weeks, at a fraction of a migration's cost, is the process fixed and a measured baseline of how it now runs. We described this layer, and why it does not require migration, in where this goes next: the system of action.

A migration is still the right call in a few cases: the vendor has sunset the platform, a roll-up has six ledgers to consolidate into one, or the system cannot hold the volume the business now does. Even then, the sequence matters. A company that has fixed and measured its processes first migrates a known process onto the new platform. Panorama's data ties the budget overruns to system misfits discovered late, after a poor selection, and the schedule overruns to resistance to process standardization: both are process problems found mid-build.

A reasonable counter, answered

A reasonable counter is that the layer postpones the migration rather than avoiding it, and that a company running agents over a fifteen-year-old system has bought itself a more complicated version of the same problem. Sometimes that is true, and a platform at the end of its life should be replaced. But the order still favors the layer. The migration that follows a measured, running process is a smaller project: the data is already clean because the agent has been matching against it, the exceptions are known because they have been routed and counted for a year, and the selection is made against a process map rather than a workshop drawing, which is the point at which Panorama says the fatal misfits are usually missed. A company that migrates first spends nine months and a budget overrun to arrive at the process work it could have started with.