The Panorama Consulting 2026 report surveyed 170 organisations between January 2025 and January 2026. Roughly 30% of ERP projects finished over budget. 22.3% exceeded their planned schedule.
Among the projects that went over budget: 54.9% needed technology that was only discovered after the project began, and 51% saw scope grow beyond the original plan.
Gartner projects that more than 70% of recently implemented ERP initiatives will fail to fully meet their original business-case goals by 2027 — a different measure, and a sobering one.
Read those causes again. They are not technical failures. They are failures of what happened before anyone wrote code.
The seven failure modes
1. Something unexpected needed buying or building
The single biggest cause — 54.9% of over-budget projects.
What it looks like: four months in, somebody discovers the warehouse scanners cannot talk to the new system, or the EDI connection to your largest customer needs a middleware licence nobody budgeted for, or the payment provider’s API does not support a transaction type you rely on.
Why it happens: discovery asked whether integrations were possible rather than testing whether they worked. “They have an API” is not the same as “we have authenticated against it and read real data”.
How to prevent it: during discovery, actually connect to every system. Authenticate, pull real records, confirm the fields you need exist. This is a few days of work and it is the highest-value few days in the project.
Early warning sign: your supplier’s discovery produced a document but never requested credentials for anything.
2. Scope grew
51% of over-budget projects.
What it looks like: the project started as stock and orders. By month five it also includes a customer portal, a reporting suite and a mobile app, because each addition seemed small at the time.
Why it happens: no written scope boundary, no change process, and a genuine phenomenon — people only understand what they want once they see something working.
How to prevent it: write down what is out of scope, not only what is in. Agree a written change process before work starts, with every addition priced before it begins. Expect changes; refuse unpriced ones.
Early warning sign: the phrase “while we’re in there” appearing more than twice in a month.
3. Data migration was treated as a task
What it looks like: migration was a line item estimated at two weeks. It takes nine. Go-live slips. Then the system launches with data nobody trusts, and people keep using the spreadsheets.
Why it happens: nobody looked at the actual data before estimating. Moving 40,000 clean records is a day. Moving 40,000 records where the same customer appears four times under three spellings, dates sit in two formats, and a third of phone numbers are in a notes field is weeks.
How to prevent it: quote migration separately, after inspecting a real extract. Rehearse it repeatedly with reconciliation reports you can check. Never let migration be a line in a bundled fixed price.
Early warning sign: migration quoted before anyone has seen your data.
4. The broken process was automated instead of fixed
What it looks like: the new system does exactly what the old one did, including the three-stage approval that exists because of an incident in 2017. It is faster and just as illogical, now encoded and expensive to change.
Why it happens: nobody had authority to change how the business works, so the software was built to match current practice.
How to prevent it: ERP implementation is the one moment when process change is politically possible. Someone must have authority to say “we are going to stop doing that”. Identify them before starting.
Early warning sign: requirements documented entirely as “the system must replicate…”
5. Nobody owned it
What it looks like: ERP touches every department, so it belongs to none of them. Decisions wait for meetings. The timeline doubles, mostly in gaps between activity.
How to prevent it: one named owner with authority to decide, with time formally allocated — not an existing full-time job plus an ERP project.
Early warning sign: when you ask who decides, the answer is a committee.
6. Training was the last line of the budget
What it looks like: the system goes live. The warehouse carries on using the spreadsheet because nobody showed them properly and the old way still works. Six months later the data is incomplete and the project is judged a failure.
Why it happens: training is the easiest thing to cut when the budget is tight, and the consequences arrive after the project is “finished”.
How to prevent it: treat adoption as the deliverable rather than go-live. Involve the people who will use it during process mapping — they become advocates rather than victims. Budget training explicitly and protect it.
Early warning sign: training is a single line near the bottom of the quote.
7. Go-live was one event
What it looks like: everything switches over one weekend. Something unanticipated happens on Monday. There is no fallback because the old system has been decommissioned.
How to prevent it: parallel running until the numbers reconcile, then phased cutover by department or site. It costs more and fails dramatically less.
Early warning sign: a project plan with a single “go-live” milestone and no parallel running period.
The warning signs, as a checklist
Signs your ERP project is heading for trouble — most are visible early.
- Discovery never requested credentials for any existing system
- Data migration was quoted before anyone saw your data
- There is no written list of what is out of scope
- There is no written change process with pricing
- No single named owner with decision authority
- Requirements describe replicating current process rather than outcomes
- Training is one line at the bottom of the budget
- A single go-live date with no parallel running
- “While we’re in there” is appearing regularly
- Nobody has written down what success looks like, with numbers
Three or more: act now. These compound and get more expensive to fix every week.
What to do if you are already in trouble
Stop and reassess rather than pushing through. The sunk cost is gone either way. The only question is what the remaining spend achieves.
Get the current state written down. What works, what does not, what is left. By someone with no stake in the answer if possible.
Re-scope to the smallest useful version. What is the least that would deliver real value? Ship that. Phase the rest.
Check the data honestly. If migration is the problem, it will not improve by being pushed. Fix the data as a separate piece of work.
Have the commercial conversation directly. If your supplier underestimated, say so and discuss it. Both sides quietly hoping is how projects fail completely rather than expensively.
Consider a phased exit. If the relationship has broken down, a partial handover of what exists is better than a disputed finish. This depends entirely on whether you hold the code and the data.
Failures on the client side
The supplier-side causes get written about. These are the ones that sit with you, and they are at least as common.
Nobody made the decisions. Migration alone generates dozens — which duplicate is correct, how far back to migrate, what gets archived. Each waiting a week is a week. This is the single largest client-side cause of slippage and it is entirely controllable.
The sponsor disengaged after signing. Executive attention arrives for the business case and departs for the delivery. Then it returns for go-live, at which point the decisions already made are questioned.
The wrong people were in the room. Requirements gathered from managers who describe the documented process, not from the people who perform the actual one. These differ in every business, and the gap surfaces during testing.
Nobody owned adoption. The software works. The warehouse keeps using the spreadsheet because nobody was accountable for them not doing so. Six months later the data is incomplete and the project is judged a failure.
Process change was refused. The project was expected to deliver improvement while changing nothing about how anyone works. That is not available.
Parallel running was cut to save time. Usually the week the deadline starts looking tight. It is the most expensive week to save.
Testing was delegated to the supplier. Your team knows what right looks like and the supplier does not. A system tested only by its builders launches with errors only your people could have spotted.
What a well-run ERP project looks like
- Discovery that connected to every system, not just asked about them
- Migration quoted separately after inspecting real data
- A written scope boundary and a priced change process
- One named owner with authority and allocated time
- Phase one delivering real value in months, not at the end
- Migration rehearsed repeatedly with reconciliation reports
- Parallel running until the numbers agree
- Phased cutover with training built into the rollout
- Source code, documentation and migration scripts handed over, infrastructure in your accounts
What the numbers actually say
Worth separating, because these figures get blended into a single “ERP failure rate” that no source supports.
| Source | Measure | Finding |
|---|---|---|
| Panorama 2026 (170 orgs, Jan 2025 – Jan 2026) | Budget | ~30% finished over budget |
| Panorama 2026 | Schedule | 22.3% exceeded planned schedule |
| Panorama 2026 | Cause, of over-budget projects | 54.9% needed technology discovered after start; 51% saw scope grow |
| Gartner | Business-case attainment | >70% of recent ERP initiatives will not fully meet original goals by 2027 |
| Info-Tech | Budget | ~55% reported over budget |
| Info-Tech | Benefits | Two-thirds realised less than half of anticipated benefits |
These are not interchangeable. Going over budget, going over schedule, and not fully meeting a business case are three different outcomes. A project can finish on budget and on time and still miss its business case — which is what the Gartner figure is measuring, and why it is the highest number.
The practically useful reading: roughly a third of projects overrun on cost, roughly a quarter on time, and a majority under-deliver against what was promised internally. The causes are consistent and they are not technical.
The questions to ask at each stage
Before signing
- Have you connected to each of our systems, or only confirmed they have APIs?
- Has anyone looked at a real extract of our data?
- Is migration quoted separately?
- What is explicitly out of scope?
- What is the change process, and how are changes priced?
During discovery
- What did you find that we did not know about?
- Which integration worries you most?
- What is our duplicate rate?
- What would you descope first if we needed to reduce cost?
During build
- What has slipped, and by how much?
- What are you least confident about?
- How many migration rehearsals have we done, and what did the reconciliation show?
Before go-live
- Does the finance team agree the reconciliation?
- How long will we run in parallel?
- Which department goes first, and why?
- What is the rollback plan?
The most useful question in the list is “what are you least confident about?” A supplier who answers honestly is managing the project. One who says “nothing” is either not looking or not telling you.
Frequently asked questions
What percentage of ERP projects fail?
It depends on the measure. Panorama’s 2026 survey of 170 organisations found roughly 30% over budget and 22.3% over schedule. Gartner projects over 70% of ERP initiatives will not fully meet their original business-case goals by 2027 — a different and stricter measure. Figures quoted as a single “failure rate” usually blend incompatible definitions.
What is the main reason ERP implementations fail?
In the Panorama data, the largest cause of budget overrun is technology that was only discovered to be necessary after the project began — 54.9% of over-budget projects. That is a discovery failure and it is preventable by actually testing integrations before committing.
How do I stop ERP scope creep?
Write down what is out of scope, agree a written change process that prices every addition before work starts, and deliver in phases so changes land in the next phase rather than the current one.
Why is data migration always underestimated?
Because it is estimated before anyone looks at the data. Record count is irrelevant; data quality is everything. Insist migration is quoted separately after a real extract has been inspected.
How long should an ERP implementation take?
A custom operational layer takes 8–16 weeks. A mid-size ERP takes 20–36 weeks. Large multi-site builds take nine months or more. Products typically take 3–12 months depending on scale.
Can we recover a failing ERP project?
Often yes, by stopping, assessing honestly, and re-scoping to the smallest version that delivers value. Pushing on unchanged is the response that most reliably makes it worse.
What is parallel running?
Operating the new system alongside the old one until the outputs reconcile, before switching anything off. It costs more and it is the main defence against a go-live that cannot be reversed.
What makes the difference
Looking across projects that land and projects that do not, the separation is consistent and it is not about technology choice.
Discovery that connected rather than asked. Credentials requested, systems authenticated against, real records pulled, data extract inspected. This single practice addresses the largest cause in the Panorama data.
Migration quoted separately, after inspection. Not a line in a bundled price.
A written scope boundary. What is explicitly out. This is the mechanism against scope growth; discipline alone is not.
One owner with authority and allocated time. Not a committee, not a full-time role with a project attached.
Phase one delivering value in months. People engage with software they are using. Requirements sharpen when informed by something real.
Parallel running until the numbers agree. No decommissioning on faith.
Adoption treated as the deliverable. Not go-live. Training built into the rollout, and the people who will use it involved from process mapping onwards.
Honest reporting of bad news. Within the week. The projects that fail catastrophically rather than expensively are the ones where both sides quietly hoped.
None of this is technically difficult. It is all decided before anyone writes code, which is precisely why the failure rate stays stubbornly high — the causes sit in the part of the project that feels like administration.
Written by Jas Singh, Founder. Last updated 8 October 2026.
Figures from the Panorama Consulting 2026 ERP report (170 organisations, January 2025 – January 2026) and Gartner projections through 2027, reported via secondary sources. These measure different things — budget overrun, schedule overrun and business-case attainment — and are cited as directional rather than as a single comparable failure rate.
Related: ERP software development · Custom ERP vs Odoo vs NetSuite vs SAP · ERP data migration
