Why ERP Implementations Fail and how SMEs avoid the same traps

How common is ERP failure, really?

ERP implementation failure is widely discussed, but the numbers only matter if you understand what each source means by failure. Gartner predicts that by 2027, more than 70% of recently implemented ERP initiatives will fail to fully meet their original business case goals, and as many as 25% will fail catastrophically. That is not the same as saying the project was cancelled — it means the business case was not realized.

Panorama Consulting's 2026 ERP Report found that more than a quarter of organizations reported their ERP project was over budget, and almost a quarter reported it was over schedule. The leading over-budget cause was the unexpected need for additional technology; the leading over-schedule cause was organizational issues such as governance gaps, resistance, and process redesign.

Info-Tech Research Group reports that roughly 55% of ERP projects come in over budget, and two-thirds of organizations realize less than half of their anticipated benefits. The common thread across every credible study: most ERP disappointments are delivery and adoption problems, not software problems.

• →Gartner (2027 forecast): 70%+ of ERP initiatives fail to fully meet business case goals; ~25% fail catastrophically.
• →Panorama 2026 ERP Report: 25%+ of projects over budget; ~25% over schedule.
• →Info-Tech: ~55% over budget; two-thirds realize under half of expected benefits.
• →Standish CHAOS data (~31% of IT projects successful, ~50% challenged, ~19% failed) covers all IT projects, not ERP specifically; large projects underperform small ones by a wide margin.

The real causes behind why ERP implementations fail

Across analyst research, academic reviews, and post-mortems of failed implementations, the same root causes appear in almost every case. Panorama Consulting identifies prioritizing technology over people as the number-one reason ERP implementations fail, noting that change management issues contributed to failure in every ERP lawsuit the firm has analyzed as expert witnesses.

An academic systematic literature review (Rajapakse & Thushara, 2023, covering 55 articles from 2000 to 2022) found that lack of top management support was the most frequently cited critical failure factor for ERP implementations globally, with inadequate education and training and users unwilling to use the ERP system also in the top five. Deloitte research similarly points to reluctance to change, insufficient user training, excessive customization, and lack of business process reengineering as critical failure factors.

A peer-reviewed 2021 framework (Stone & Zhang) identified five key success factors: project buy-in (the most important), change management, adequate employee training, employee participation, and data validation. When these are absent, the project is at risk regardless of which platform you choose.

• →Prioritizing technology over people (Panorama: present in every ERP lawsuit they analyzed).
• →Lack of top management support and visible executive sponsorship (top factor in 2023 academic review of 55 studies).
• →Inadequate change management and training; users unwilling to adopt the system.
• →Excessive customization and weak business process reengineering (Deloitte, Panorama).
• →Poor data quality and data migration discipline (Stone & Zhang, 2021).

The change management budget gap

One of the most consistent findings in ERP research is that organizations underinvest in the people side of the project. Prosci research found that projects with excellent change management programs met or exceeded objectives 88% of the time, while only about 13% (roughly 1 in 8) of those with poor change management met their objectives — making excellent change management approximately 7x more likely to deliver project success.

Despite that, Prosci also found that most organizations allocate roughly 92% of their ERP budget to technical activities and only about 8% to change management, with People and Change Management being the top recommendation category (36%) in their Unlocking ERP Implementations study. If your budget shows the same 90/10 split toward configuration, development, and integration, you are structurally repeating the most common failure pattern before go-live.

Prosci's ADKAR model (Awareness, Desire, Knowledge, Ability, Reinforcement) gives SMEs a practical structure for managing individual change. The point is not the framework — it is that without a deliberate, funded plan for adoption, even a technically perfect go-live will underdeliver on the business case.

Where Microsoft Dynamics 365 implementations break

Microsoft Dynamics 365 failure patterns are partner- and architecture-heavy rather than platform defects. The clearest recent large-scale case is Metcash, the Australian wholesaler: an $80 million Dynamics 365 project (Project Horizon) blew out by roughly $200 million (total spend around $300 million) and ran more than two years late. Governance failures included the project not reporting directly to the CEO and more than 200 KPMG consultants engaged at peak; the incoming CEO publicly called the prior 'dream' transformation a 'nightmare.'

The most detailed Dynamics lawsuit on the public record is ScanSource vs Avanade (2013): a Dynamics AX project estimated at about $17 million over 11 months ballooned to roughly $66 million over three-plus years without going live, with bait-and-switch allegations and roughly 500,000 lines of custom code. The lesson generalizes: adding more consultants does not equal faster delivery when governance, scope, and customization are uncontrolled.

Beyond individual cases, recurring D365-specific risk areas include dual-write configuration between Dynamics 365 Finance & Operations and Dataverse / Customer Engagement apps (Microsoft maintains extensive official troubleshooting documentation for plugin registration, authentication, metadata sync, and entity conflict errors), cloud migration sizing and performance choices, layered licensing complexity, and the limits of Microsoft's FastTrack program. FastTrack (Success by Design) provides architects, workshops, and checklists for eligible customers but is explicitly designed to support — not replace — an experienced implementation partner or day-to-day execution.

• →Partner / VAR execution quality varies widely; more bodies does not mean faster results (Metcash, ScanSource vs Avanade).
• →Dual-write misconfiguration between F&O and Dataverse is a well-documented D365-specific technical risk.
• →Cloud sizing, licensing tiers, and hotfix management differ from on-prem and drive TCO surprises.
• →Microsoft FastTrack identifies risk but does not implement; it cannot substitute for strong partner execution or internal governance.

Where Odoo implementations break

Odoo failure patterns look different from SAP or D365 mega-projects. Because Odoo is modular and popular with SMEs, failures tend to come from flexibility abuse and partner variance rather than nine-figure cost explosions. The most-cited post-go-live cause is customization overload: heavy custom code outside Odoo's standard ORM and framework creates fragile systems, broken modules on upgrade, and maintenance burdens that make the system impossible to evolve.

A documented example is Ekofluid GmbH in Austria, whose first Odoo implementation failed due to broken customizations, near-zero user adoption (staff reverted to manual processes), missing bilingual features, and daily operational failures; the company was later rescued by a clean Odoo v17 standardization delivered by Portcities. Rescue providers (Cudio reports 35 Odoo rescues, alongside firms like Adatasol, Archeti, and Silent Infotech) consistently list the same root causes: weak discovery, bad data migration, customization without strategy, poor partner delivery, and no change management.

The hidden-cost trap compounds this. Odoo's One App Free plan and the open-source Community Edition are free in license only: Community requires self-hosting, in-house or partner developers, carries no official support, and offers no guaranteed upgrades. SMEs attracted by 'free ERP' marketing frequently underestimate the real total cost of ownership. Partner quality variance is a widely acknowledged Odoo weakness, despite the official Ready, Silver, and Gold partner tiers; picking the wrong or inexperienced partner is one of the most frequently listed root causes of Odoo failure.

Important caveat: rigorous independent Odoo-specific failure-rate research does not appear to exist. Most public evidence comes from rescue providers (who have a commercial interest in framing projects as rescues) and user forums. Treat Odoo failure patterns as consistently reported across practitioners and users rather than as a statistically proven rate.

• →Customization overload is the most-cited Odoo post-go-live failure (fragile modules, upgrade pain).
• →Partner quality variance: wrong or inexperienced partner is a top-listed Odoo root cause.
• →Free license does not equal free ERP: self-hosting, upgrades, support, and TCO surprises hit SMEs.
• →Evidence base is rescue providers and forums, not independent academic research.

Famous failures that are NOT Dynamics or Odoo

A surprising amount of ERP failure content misattributes case studies to the wrong platform. The well-known Waste Management vs SAP lawsuit (more than $100M spent, sued for up to $500M alleging misrepresentation around demos and capabilities) was an SAP implementation, settled out of court around 2010. Target Canada's failed ERP, which contributed to inventory chaos and billions in losses, was SAP ECC on a rushed roughly two-year rollout. National Grid's US ERP failure, with cleanup costs near $585M and a $75M settlement with integrator Wipro, was also SAP.

Hershey, Lidl, AstraZeneca, and Avon are similarly SAP or other legacy platforms. They are real, instructive failures — but they are not evidence against Microsoft Dynamics 365 or Odoo. When you read vendor-critical content, check which platform actually failed before drawing conclusions.

• →Waste Management vs SAP (settled ~2010): SAP, not D365.
• →Target Canada (SAP ECC): SAP, not D365.
• →National Grid US (Wipro integrator): SAP, not D365.
• →Hershey, Lidl, AstraZeneca, Avon: SAP or other legacy, not D365 or Odoo.

How to avoid becoming a failure statistic

1. 01
   Start with business process, not software

   Decide what processes you are standardizing before you pick a platform. A peer-reviewed field survey (Hong & Kim, 2002, Information & Management, 34 organizations) found that ERP success significantly depends on the organizational fit of the ERP. Run a structured requirements and process exercise first; do not let a vendor demo drive your process design.

2. 02
   Fund change management like a workstream, not a footnote

   Given Prosci's finding that excellent change management makes success roughly 7x more likely, treat change management as a funded workstream with a named owner, an ADKAR-style plan, training, communications, and adoption metrics — not a line item bolted on at go-live.

3. 03
   Pick the right implementation partner and govern them

   Panorama recommends independent third-party oversight and a strong executive sponsor who builds a sponsorship coalition, removes barriers, and communicates the 'why' throughout the project. Run detailed RFPs with scripted business-process demos, reference checks with similar-size companies, and site visits or proof-of-concepts before you sign.

4. 04
   Limit customization and own your data

   Excessive customization is a named failure cause across Panorama, Deloitte, and rescue providers. Prefer standard processes, document exceptions, and treat data migration as a first-class workstream with validation well before cutover. This applies equally to D365 and Odoo.

5. 05
   Use platform safety nets correctly

   For Dynamics 365, engage Microsoft's FastTrack / Success by Design materials for architecture reviews and checklists, but do not treat them as a substitute for an experienced partner. For Odoo, prefer a partner with a proven track record on your version and module set, and question any proposal that leans heavily on custom code.