Nine well-documented ERP failures, from a confectioner to a UK council. The headline failure rates are shakier than the vendors admit, but the post-mortems agree on the same handful of causes. Here they are, with what to do about each one on a Business Central project.
Search for "ERP failure rate" and you will be told that 50%, 68% or 75% of projects fail. Those numbers are repeated so often they have become furniture. Before we get to why projects fail, it is worth being honest about how good the numbers are, because a consultancy quoting a scary statistic to sell you a rescue is part of the problem.
Most of the headline figures trace back to the annual Panorama Consulting ERP Report and to Gartner surveys. Read across several years, they put the share of projects that exceed their original budget, timeline or expected benefits at somewhere between 50% and 75%. That is a range, not a rate, and "failure" in those studies means "missed at least one of three targets". Outright abandonment, the project cancelled and the money written off, is much rarer: low single digits to low teens.
The most-quoted 2026 figures (a 68% failure rate, 189% average budget overrun, 73% failure in discrete manufacturing) come from a dataset of about 2,400 manufacturing implementations compiled by an ERP reseller, and the "share of failures" by cause in the same study adds up to well over 100% because one project can fail for several reasons. Useful as a direction of travel; not something to put in a board paper as fact.
The study I trust most is older and broader. McKinsey and the University of Oxford looked at more than 5,400 IT projects and found that large ones (over $15m) ran on average 45% over budget, 7% over time, and delivered 56% less value than predicted. One in six was a "black swan": a project that went so wrong it threatened the company itself.
So the fair summary is this: most ERP projects do not collapse. Most of them cost more, take longer and deliver less than promised, and a meaningful minority do real damage. The interesting question is why, and the post-mortems, including court filings and public audits, are remarkably consistent.
A note on names: every case below is a matter of public record, reported in the press, in audit reports or in court filings. For legal reasons we are not going to name the organisations here. If you want the names, they are not hard to find.
| Organisation | Year | What went wrong | Cost |
|---|---|---|---|
| Org 1 (US confectioner) | 1999 | Compressed a four-year programme into about 30 months and went live big-bang in the run-up to its peak season. Order-to-cash broke. | Over $100m of orders unfilled; quarterly profit down about 19% |
| Org 2 (global sportswear brand) | 2000 | Under-tested demand-planning software produced bad forecasts, so the company over-ordered some lines and under-ordered others. | About $100m lost sales; share price down about 20% |
| Org 3 (US waste services group) | 2005 to 2008 | The business sponsor delegated delivery to IT, the project stalled, and the customer and the vendor sued each other. | Litigation over $100m; project abandoned |
| Org 4 (US utility) | 2012 | Went live days before a major storm hit its network. Payroll and financials failed under load. | Remediation estimated at up to $585m |
| Org 5 (retailer entering a new country) | 2013 to 2015 | Rushed rollout on bad master data: wrong dimensions, prices and barcodes. Stores were overstocked and out of stock at the same time. | Contributed to a market exit costing about $2bn |
| Org 6 (European grocery chain) | 2011 to 2018 | The business valued stock at purchase price; the software's retail model assumed retail price. Seven years of bending the software to the process, then scrapped. | About €500m written off |
| Org 7 (European confectioner) | 2018 | Moved 16 factories in 10 countries from 1980s-era regional systems to a single new ERP at once. Deliveries missed, shelves empty for days. | Sales of its flagship product down 25% in the year |
| Org 8 (US cosmetics group) | 2018 | Cut over without adequate safeguards. Manufacturing and shipping disrupted for months. | About $64m lost net sales; shares down nearly 7% in a day |
| Org 9 (large UK local authority) | 2022 onwards | Replaced a long-standing ERP with a new cloud suite, customised it to fit existing processes, went live despite known risks, and could not reconcile its bank accounts or produce reliable accounts for years. | Budget £19m; spend £171m and rising, with £200m forecast |
Notice what is not in that list: a case where the software did not work. Every one of these ran on mature, widely used products. The failures were decisions.
This is the root of most of the others. An ERP implementation is a change to how the business works, with some software attached. When the sponsor is the IT director rather than the finance director or managing director, nobody has the authority to settle the argument between sales and the warehouse about who owns the item master, and the decision gets deferred until go-live makes it for you. Org 3 is the textbook example; the auditors of Org 9 made the same finding in politer language ("business case and programme governance not properly designed before the project began").
Prosci's change management research, built on more than 10,800 responses over 25 years, has found the same top contributor to success in every edition since 1998: active and visible executive sponsorship. Projects with a highly effective sponsor met their objectives 79% of the time; with an ineffective one, 27%. Only about half of projects report having an effective sponsor at all.
On a Business Central project: the sponsor is the person who signs the cheque and loses sleep if month-end does not close. They attend the steering meeting, they make the calls on scope, and they say in public that the project matters. If they will not do that, delay the project until someone will.
Org 6 spent seven years and half a billion euros trying to make the software value stock the way it always had. Org 9 customised its new suite to replicate existing processes rather than adopting the standard ones. In both cases the customisation was the project: it absorbed the budget, it broke every time the vendor shipped an update, and it meant the organisation never got the benefit of a modern process.
On a Business Central project: Business Central ships with a standard way to do finance, sales, purchasing, stock and (if you need them) manufacturing and warehousing that works for tens of thousands of companies. The default answer to "can we make it work like the old system?" is "let's see why the old system did it that way first". Extensions are for the things that make you money and nobody else does, not for keeping a 2009 posting routine alive. The fit-gap in the Analysis phase exists to have those arguments early, when they are cheap.
Org 5's supply chain fell over on master data: items with the wrong dimensions, wrong prices and wrong barcodes, keyed in a hurry by people who did not know the system. The warehouse software did exactly what it was told. The most-cited 2026 study attributes 38% of failures wholly or partly to data migration, and that matches our experience: a Business Central migration is a data project with a configuration project attached.
On a Business Central project: profile the data before you design anything. Decide what history you really need (usually opening balances, open items and two years of history, not fifteen). Clean customers, suppliers and items in the old system, where the people who know them can see them. Rehearse the migration at least twice, once for SIT and once as a full cut-over dress rehearsal, and reconcile the trial balance, debtors, creditors and stock to the penny each time. If the numbers do not reconcile in rehearsal, they will not reconcile on go-live weekend.
Org 2's forecasting software was not tested against realistic demand. Org 8 cut over without safeguards. Org 9 went live with risks known and unmitigated. Testing is the thing that gets cut when the date is fixed and the budget is gone, and it is the thing that would have caught the problem.
On a Business Central project: we run three gates and do not open the next until the last is signed off: unit testing of every extension and integration by the developer, system integration testing end to end with migrated data, and user acceptance testing run by your own super users. We wrote up where each one sits in the lifecycle. The point of UAT being run by your people is that it is the first time anyone tests whether the system does what the business needs, rather than what the specification said.
Training a week before go-live, from slides, in a room, is where most projects put it, and it is why users revert to spreadsheets on day two. The 2026 dataset blames inadequate change management for 42% of failures and insufficient end-user training for 29%; Prosci's figures say projects with excellent change management are roughly seven times more likely to meet their objectives. The mechanism is simple: people do not adopt what they do not understand, and once the workaround is established it never leaves.
On a Business Central project: name super users in the Analysis phase, one or two per department, and train them as the system is built so they can run UAT without us. They then deliver end-user training on the real configuration with real data in the Deployment phase, and they become your first line of support after go-live. That is also what makes hypercare short.
Org 1 picked the date first and squeezed the work into it. Org 7 moved 16 factories at once. Every rushed project in the list went live into its busiest period, because the date had been promised and nobody wanted to be the one to move it. A fixed date with undefined scope guarantees that testing, training and data get cut, in that order.
On a Business Central project: agree the scope before the date. Go live at a quiet time, straight after a period end (first working day of a month, never the last), and never in your peak trading month. If the business has manufacturing, advanced warehousing or complex integrations, expect Design, Development and Deployment to take considerably longer than the standard timeline, and plan for that rather than discovering it. Phasing is respectable: finance first, then operations, is how most mid-sized businesses should do it.
A US brewer sued its integrator for $100m after a post-merger consolidation stalled. The auditors of Org 9 found the suppliers "did not raise warnings", probably because of pressure to protect budgets and reputations, and that the council depended on contractors because it had no programme management skills of its own. A partner with no experience of your industry cannot make up for software that does not fit it, and a partner that is not challenged will tell you what you want to hear.
On a Business Central project: ask who will actually be on the project, not who is in the sales meeting. Ask for a reference in your industry. Insist on a steering meeting where risks are reported in plain words, in the first five minutes, not buried on page 40. And keep someone on your side of the table who understands both the business and the technology. If you do not have that person, that is exactly the gap a fractional CIO or CTO is meant to fill.
Most ERP projects do not collapse; they cost more, take longer and deliver less than promised, and the reasons are the same every time: no real sponsor, software bent to the old process, data migrated in a hurry, testing cut, training left to the end, a date fixed before the scope, and a partner nobody is managing. None of them is a software problem.
The flip side, what the projects that work have in common, is in the companion piece: Why Business Central projects succeed.
If you are about to start a Business Central project, or you are in one that feels like it is drifting, our health check is one day of senior time to tell you which of the seven you are exposed to. If you would rather just talk it through, book a 30 minute call.
