Why ERP Implementations Fail [9 Root Causes Inside]
Short answer: ERP implementations rarely fail because of the software. They fail because the business case was vague, old processes were rebuilt in new software, data and reporting were left until last, and the project depended on too few people. Most of those failures are recoverable without replacing the system.
We have delivered more than 500 Microsoft Dynamics 365 Business Central implementations in the US, and our ERP implementation services team is regularly called in to rescue projects other teams started. The pattern is consistent. By the time a CFO calls us, the system is live, the licences are paid for, and the finance team is back in spreadsheets.
This guide covers the nine root causes we see most often, the warning signs at each phase, real rescue examples, and the 30-day plan we use to stabilise a struggling Dynamics 365 project.
Do 70% of ERP Projects Really Fail?
No, not in the way the statistic is usually quoted. The figure comes from Gartner, which predicts that more than 70% of recently implemented ERP initiatives will not fully meet their original business goals by 2027 (Gartner).
That is a statement about underperformance, not collapse. Speaking at Gartner’s Barcelona Symposium in November 2025, Gartner’s ERP strategy lead put outright catastrophic failure at about 25% (The Register).
The distinction matters for your next decision:
An underperforming ERP has a working core but weak configuration, reporting or adoption. It needs stabilisation, usually in weeks.
A failed ERP has a broken data model or architecture. It needs re-implementation, usually in months.
Most projects we are asked to rescue sit in the first group. Treating them as the second group is how companies end up paying for the same implementation twice.
What Struggling ERP Owners Tell Us
We reviewed the requests for help we received from US companies over the past 18 months. The same few stories repeat, and almost none of them is about the software itself.
What the company told us (paraphrased) | Root cause behind it |
|---|---|
The system was never finished, and the original partner stopped responding | Everything depended on one team (cause 5) |
Sixteen months after migrating, the system still does not work the way we were promised | Partner lacked product and industry depth (cause 4) |
The upgrade went live, but we are unhappy with the result and the support | Old processes carried into the new version (cause 2) |
Shopify, shipping software and Business Central do not reconcile, so financial reports do not tie | Fragile integrations (cause 7) |
Our billing reconciliation still runs outside the new system after go-live | Scope and data left unfinished (cause 3) |
An industry add-on was implemented without anyone who really knew it | Partner lacked product depth (cause 4) |
Our partner’s costs keep rising without the project moving forward | No measurable outcomes to manage against (cause 1) |
A request that keeps coming back is finishing or fixing an e-commerce integration, usually Shopify. If you sell online, test that link first.
The 9 Root Causes of ERP Implementation Failure
These are the causes we find most often when we audit a struggling Dynamics 365 project. Most stalled projects have three or four of them at once.
1. The business case had no measurable outcomes
“Replace the old system” is not a business case. Without targets such as “close the books in 5 days instead of 12”, nobody can say whether the project is on track, so scope expands to fill the budget. Gartner names weak business cases and unclear strategic alignment as leading causes of disappointing ERP results.
Rescue fix: write three to five measurable outcomes before touching configuration. Every open issue is then ranked by which outcome it blocks.
2. Old processes were rebuilt in new software
The most expensive mistake is customising Business Central or Dynamics 365 Finance to copy how the legacy system worked. It carries years of workarounds into a platform designed to run without them, and every customisation adds testing and support cost at each Microsoft update.
We see this most in NAV upgrades. A straight upgrade moves the technical debt to the cloud, which is why we often recommend re-implementing instead of upgrading.
Rescue fix: list every customisation, then retire whatever standard functionality now covers.
3. Data migration was treated as a weekend task
Dirty item masters, duplicate customers and unreconciled opening balances do not stay in the migration. They surface as wrong stock levels, failed postings and reports nobody trusts, and the finance team returns to spreadsheets within weeks of go-live.
Rescue fix: reconcile opening balances and the top 20% of master data that drives 80% of transactions before fixing anything else.
4. The internal team implemented without enough product depth
Self-implementation looks cheaper until configuration decisions start compounding. One global logistics group we worked with had deployed Dynamics 365 Finance through its internal team. The system was live, but configuration, reporting and adoption all fell short, putting a planned 30-entity rollout at risk.
Rescue fix: an independent configuration review against Microsoft standard practice, followed by targeted fixes rather than a rebuild.
5. Everything depended on one consultant
When a single contractor holds all the system knowledge, their departure becomes your outage. Adams Recycling, a South Carolina recycling business, was running an unsupported NAV 2018 system after the one external consultant it relied on became unavailable.
Rescue fix: document the configuration, move to a team-based support model, and stop running unsupported versions.
6. Reporting was designed last
Reports are what executives see, yet they are usually built after go-live. If the chart of accounts, dimensions and intercompany rules were not designed for reporting, no report-writer can fix it afterwards. American Vision Group, a Florida eyecare platform, had Business Central in place but was still consolidating its entities by hand.
Rescue fix: align the chart of accounts and mandatory dimensions first; the reports follow.
7. Integrations were held together with fragile middleware
E-commerce, marketplaces, EDI and warehouse systems all exchange data with the ERP. When those links run through unstable middleware, orders, stock and invoices drift out of sync. An equestrian retailer selling through stores, its own website, Amazon and eBay came to us with exactly this problem.
Rescue fix: map every integration, its owner and its failure mode, then replace the fragile ones with supported connectors.
8. The rollout scaled before the first site was stable
Rolling a shaky configuration out to more entities or countries multiplies every flaw. The fix is a proven template, not speed.
Rescue fix: stabilise one entity fully, then turn it into a global blueprint for the rest.
9. Change management was a line item, not a workstream
Users who were trained once, weeks before go-live, on processes that changed afterwards will rebuild their old spreadsheets. Gartner lists limited organisational change management among the main failure causes.
Rescue fix: role-based training on the live system, named super-users in each department, and adoption metrics reviewed weekly.
Warning Signs at Each Implementation Phase
Failure is visible long before go-live if you know where to look. If two or more of these signs apply to your project, it is time for an independent review.
Phase | Warning sign | What it usually means |
|---|---|---|
Discovery | Requirements are a list of current screens and reports | Old processes are about to be rebuilt (cause 2) |
Discovery | No one can state the target close time, order cycle or inventory accuracy | The business case has no measurable outcomes (cause 1) |
Design | The customisation list keeps growing after sign-off | Scope creep and future upgrade cost |
Design | Reporting is “phase 2” | The chart of accounts and dimensions will not support it (cause 6) |
Build | Test data is still demo data | Migration has not been rehearsed (cause 3) |
Build | One person answers every configuration question | Key-person risk (cause 5) |
Testing | Users test scripts, not their real working day | Adoption problems will appear after go-live (cause 9) |
Go-live | Opening balances do not reconcile | Finance will not trust the system |
Post go-live | Teams are back in Excel within 60 days | Adoption, reporting or data failure |
Post go-live | Month-end close takes longer than before | Configuration or intercompany setup is wrong |
ERP Rescue Case Studies
These four engagements show the range of rescue work, from a fix inside a live system to a full re-implementation, starting with two US clients. Two fixed the system already in place; only two needed a new one.
American Vision Group: fix reporting without switching platforms (Business Central)
Situation: a Florida-based eyecare services platform running several entities on Business Central. Reports were prepared separately per entity, intercompany transactions were reconciled by hand, and month-end close consumed the finance team.
What we did: as a Business Central support engagement inside the existing system, we created a consolidated reporting entity, aligned the chart of accounts, defined intercompany elimination rules, made dimensions mandatory on journals and invoices, and automated monthly P&L, balance sheet and cash flow reports.
Result: shorter month-end cycles, audit-ready monthly reports and a single view across entities, without a new platform. Read the case study.
Adams Recycling: recover from a lost consultant (NAV to Business Central)
Situation: a South Carolina recycling and materials recovery business on unsupported NAV 2018, on-premises servers and no Microsoft 365 integration. Its single external consultant had become unavailable, leaving no dependable support.
What we did: moved the business to Business Central SaaS covering finance, procurement, inventory, warehouse and sales, with Microsoft 365 integration and a reporting foundation ready for Power BI.
Result: a supported cloud platform, cleaner workflows for material tracking, and support that no longer depends on one person. Read the case study.
Global logistics group: stabilise before scaling (Dynamics 365 Finance)
Situation: a Germany-headquartered logistics business with 30 legal entities had deployed Dynamics 365 Finance through its internal team. Configuration, reporting and user adoption all fell short, and a wider multi-entity rollout was next.
What we did: instead of replacing the system, we stabilised the UK entity first. That meant a fully localised UK finance setup, bank integration, stronger reporting and hands-on training for six finance users across London, Aberdeen and Middlesbrough. We then built a global blueprint and governance framework, with localisation readiness for US sales tax and Indonesian tax.
Result: a stable UK system, more confident users, better reporting and lower transition risk through parallel running. Read the case study.
Equestrian retailer: re-implement when the architecture is the problem (Business Central)
Situation: a retailer selling through stores, its own e-commerce site, Amazon and eBay. Disconnected systems and unstable middleware left it without reliable visibility of inventory and fulfilment.
What we did: this was a case for re-implementation rather than repair. We designed a Business Central-led architecture integrating warehouse mobility, robotics, vendor document automation and marketplace connectivity.
Result: better picking accuracy, cleaner stock movement and real-time insight across channels. Read the case study.
Rescue or Re-implement? How to Decide
The right answer depends on whether the core of the system is sound. Stabilising is faster and cheaper whenever the data model and platform version are worth keeping.
Signal | Stabilise the current system | Re-implement |
|---|---|---|
Platform | Current, supported Dynamics 365 version | Unsupported version, such as NAV, GP or AX |
Chart of accounts and dimensions | Fixable with remapping | Fundamentally wrong for how you report |
Customisations | A manageable number, mostly replaceable by standard features | Extensive custom code blocking Microsoft updates |
Data | Reconcilable with cleansing | Corrupted at the source or untraceable |
Integrations | A few weak links | Architecture built on unstable middleware |
Users | Using the system but with workarounds | Have abandoned it for spreadsheets |
Typical timeline | Weeks | Months |
If most of your answers sit in the left column, a rescue will cost a fraction of starting again. If you are leaning towards re-implementation, use our ERP implementation cost breakdown to budget it realistically.
The 30-Day ERP Rescue Plan
This is the plan we use to stabilise a struggling Dynamics 365 project. The aim of the first 30 days is not to fix everything; it is to stop the damage, find the real causes and restore the finance team’s trust in the numbers.
Week | Focus | What happens | Output |
|---|---|---|---|
Week 1 | Triage | Interview process owners, review configuration, customisations, integrations and open issues, and reconcile key balances | Health-check report with every issue ranked by business impact |
Week 2 | Root cause and plan | Trace each top issue to one of the nine root causes and decide stabilise or re-implement | Recovery plan with scope, cost and owners |
Week 3 | Quick wins | Fix the blockers that stop month-end close, order processing or core reports | Measurable improvement users can feel |
Week 4 | Governance | Set up weekly steering, super-users, adoption metrics and a 90-day roadmap | A project that is managed, not firefought |
After day 30, the roadmap covers the deeper work: customisation retirement, integration replacement, reporting redesign, or a phased re-implementation where the audit called for one.
Frequently Asked Questions
Why do most ERP implementations fail?
Most ERP implementations fail for business reasons, not technical ones: a business case without measurable outcomes, old processes rebuilt through customisation, poor data migration, reporting designed last, and weak change management. Gartner expects more than 70% of recent ERP initiatives to fall short of their original goals, but only about a quarter fail outright.
What percentage of ERP implementations fail?
Gartner predicts that more than 70% of recently implemented ERP initiatives will not fully meet their original business goals by 2027. Complete, catastrophic failure is far rarer, at around 25%. Most “failed” projects are underperforming systems that can be stabilised.
Can a failed ERP implementation be rescued?
Yes, in most cases. If the platform is current and the data model is sound, a rescue focuses on configuration, data, reporting and adoption, and usually shows results within weeks. Re-implementation is needed only when the version is unsupported or the architecture itself is broken.
How long does an ERP rescue take?
A structured rescue starts with a 30-day stabilisation: one week of triage, one week of root-cause analysis, one week of quick wins and one week setting up governance. Deeper fixes then follow a 60 to 90-day roadmap, depending on scope.
Should I switch implementation partners mid-project?
Switch when the partner cannot explain the root causes, keeps adding change requests without progress, or depends on one person. Before switching, commission an independent health check so the new partner starts from facts rather than blame.
Is it cheaper to fix an ERP or replace it?
Fixing is almost always cheaper when the system runs on a supported version and the data can be reconciled, because licences, configuration and most of the data are kept. Replacement makes sense only when the underlying architecture or version is the problem.
Is Your ERP Project Showing Warning Signs?
If your finance team is back in spreadsheets, month-end takes longer than before go-live, or your project depends on one consultant, the problem is fixable, and the cost of waiting grows every month.
Dynamics Square’s ERP project health check gives you an independent review of your Dynamics 365 Business Central or Finance and Operations system, a ranked list of issues and a clear recommendation: stabilise or re-implement.