Industry Insights

Why ERP Implementations Fail: The 7 Repeating Patterns

By August 16, 2026 21 min read
Why ERP Implementations Fail: The 7 Repeating Patterns

Ask why ERP implementations fail and the internet hands you a listicle: ten reasons, zero receipts, and a demo-request form at the bottom. The public record is more useful. Enterprise resource planning (ERP) software, the systems that run a company’s finance, supply chain, and payroll, has produced a documented trail of disasters going back to 1999: Hershey missing Halloween, Lidl scrapping seven years of work, Birmingham City Council still paying for its go-live a decade into the 2020s. Twenty-two of those failures are public enough to put in a table.

Read them together and something uncomfortable shows up. The software is almost never the killer. The same seven patterns repeat across a quarter century of wreckage, every one of them was visible from the boardroom, and every one of them was survivable.

What follows is the pattern file: the disaster ledger, the real numbers behind the failure-rate folklore, the seven patterns themselves, what a failure actually costs, and the warning signs a board can catch before the write-off. The pressing question was never whether ERP projects can fail. It’s whether yours will fail in one of the seven ways everyone else already paid to discover.

The Disaster Ledger: 22 Famous ERP Failures in One Table

Every page ranking for this topic keeps its case library in prose, scattered across paragraphs. Nobody tabulates it. So here is the ledger: 22 named ERP failures with the year, the system, the headline cost, and the primary pattern each one exhibits. The figures are as reported in press coverage, court filings, and earnings disclosures.

CompanyYear(s)System / IntegratorHeadline costPrimary pattern
Hershey1999SAP R/3 big-bang$100M in unshipped orders, 19% profit decline, 8% one-day stock drop1. Immovable go-live date
Nike2000–2006i2 demand planning$100M in lost sales, 20% stock dip, ~$400M to fix4. Vendor overpromise
Waste Management2005–2010SAP$100M suit against SAP, amended to $500M, settled4. Vendor overpromise
US Navy1998–2005+Four separate ERP pilots~$1B spent on pilots that could not interoperate, ~$800M replacement program5. Governance vacuum
Lidl2011–2018SAP for Retail~€500M scrapped after seven years3. System model vs. business model
National Grid2012SAP / Wipro~$585M recovery, $75M settlement from Wipro1. Immovable go-live date
Avon2013SAP pilot$125M aborted after four years; sales reps quit over usability3. System model vs. business model
Target Canada2013SAPSupply chain collapse; ~70% of manually entered data held errors2. Garbage data at the gate
MillerCoors2014–2017SAP / HCL$100M suit, HCL countersuit, settled6. Going live with known defects
Southeast Power Group2014–2018+ERP rollout4+ years on a sub-one-year project; corrupted data, inaccurate invoices2. Garbage data at the gate
Worth & Co.2014–2019Oracle-based rollout$4.5M paid, integrator churn, ended by suing Oracle5. Governance vacuum
PG&E2016SAP test environmentProduction data left in a demo database; 47,000+ asset records exposed6. Going live with known defects
Revlon2016–2018SAP S/4HANA~$64M in lost sales, material weakness disclosure, 6.9% stock drop in 24 hours6. Going live with known defects
LeasePlan2016–2019SAP-based core system€92M write-off on a monolithic build3. System model vs. business model
Haribo2018SAP~25% decline in Gold Bear sales after go-live3. System model vs. business model
Spar Group (South Africa)2018+SAPLost product-margin visibility after go-live in low-margin retail3. System model vs. business model
Mission Produce2021ERP go-live, Nov 2021$22.2M gross profit drop, $3.8M in consultant fees1. Immovable go-live date
Invacare2021–2022ERP program pausedIntegrator fees kept accruing during the pause; CEO ousted in 20225. Governance vacuum
Ranpak2022ERP go-live, Jan 2022$6.5M implementation, $5M profit drop the following quarter7. Go-live treated as the finish line
J&J Snack Foods2022ERP go-live, Feb 2022~$20M in lost sales, $4.5M operating income hit1. Immovable go-live date
Birmingham City Council2022+Oracle£39M budget escalated past £90M5. Governance vacuum
Clark County School District2022+HCM / payroll ERPPaycheck errors across the 5th-largest US school district7. Go-live treated as the finish line

The rest of this post is what those rows have in common.

The ERP Failure Rate: What the Numbers Actually Say

The failure statistic on every vendor page is folklore. Three of the ten pages ranking for this exact search attribute a “55 to 75 percent” or “70 percent” failure rate to Gartner. None of them links a primary document. Nobody links one because no traceable primary document exists, and that is a checkable observation: the range circulates from blog to blog, each citing the last.

The honest answer to “what percent of ERP implementations fail” is that no single defensible number exists; the recycled 55 to 75 percent range has no traceable primary source, and the closest verified figure is Gartner’s prediction that by 2027, more than 70 percent of recently implemented ERP initiatives will fail to fully meet their original business goals.

Here is the provenance, claim by claim.

The claimWho repeats itWhat the primary record shows
“55–75% of ERP projects fail” (attributed to Gartner)Vendor blogs, consultancies, most of page oneNo traceable Gartner document. The range circulates unsourced.
“70% fail to reach their business case” (attributed to Gartner)Multiple ranking pagesGartner’s actual current statement, from analyst Denis Torii: research predicts that by 2027, more than 70% of recently implemented ERP initiatives will fail to fully meet their original business goals. A prediction about goal shortfall, not a historical failure count.
Budget and schedule overrunsPanorama Consulting ERP Reports (public downloads)Published editions report 58% of projects exceeding budget (55% in later data), 65% running over schedule (75% in another year), and 53% of organizations realizing under half of anticipated benefits (41% later). One edition put budget overruns as low as 23%. The number moves with the year and the definition.
“Up to 75% fail”Velosio (an implementation partner, to its credit)The same article concedes other estimates sit closer to 40–50%, and points to Deloitte’s “critical failure factors” analysis. When a partner’s own blog hedges the number by 35 points, treat the number as a rhetorical device.
“53% of IT decision-makers called ERP an investment priority”Clearsulting, citing a 2022 Gartner studyReported secondhand; we could not verify the primary either. Cited here as exactly that.

Two things make the true rate slippery. First, the definition swings the number: a project that ships late and over budget but eventually works is a failure by one definition and a rounding error by another. Panorama’s own surveys have separately found 23% of projects exceeding budgets in one year and 58% in another, roughly half of organizations needing unplanned additional technology, 40% underestimating staffing, and 40% discovering organizational issues mid-project. Second, the success side is real: the same reports find 97% of organizations reporting process improvements after a working implementation, 95% better customer experience, 91% cost reductions, and 90% productivity gains. A working ERP pays. That is exactly why treating failure as a coin flip you can’t influence is the laziest possible read of the data.

The disasters in the ledger were not unlucky draws from a 70 percent hat. They were specific, repeated, preventable mistakes. Which brings us to the patterns.

Why ERP Implementations Fail: The Seven Repeating Patterns

Page one splits into two camps on this question. One camp publishes reason lists with no evidence: NetSuite counts ten causes, Clearsulting nine, ClickLearn three, Velosio six. The other camp publishes case roundups with no synthesis: here are the disasters, draw your own conclusions. Neither connects the two.

Connect them and seven patterns fall out. The consensus framing, repeated by Lumenia and most practitioners, is that ERP failure is a business problem rather than a technology problem, and the ledger largely backs that up. But it needs a candor footnote: Lidl and Spar Group both prove that system-model fit is a real, project-killing question. The software wasn’t broken in either case. It just modeled the business wrong, and nobody tested the difference until after go-live. “The technology rarely fails” and “the technology choice can’t sink you” are different claims. Only the first is true.

The matrix below marks where each pattern shows up across ten of the marquee cases. The typical disaster exhibits two to four of the seven.

PatternHersheyNikeLidlRevlonNational GridMillerCoorsWaste MgmtHariboBirminghamAvon
1. Immovable go-live date
2. Garbage data at the gate
3. System model vs. business model
4. Vendor overpromise
5. Governance vacuum
6. Going live with known defects
7. Go-live treated as the finish line

1. The Immovable Go-Live Date

Hershey’s integrator recommended 48 months. Hershey took 30, and the compressed schedule pushed go-live into Halloween ordering season, the worst possible week on its calendar. The result: $100M in orders it held in inventory but could not ship, a 19% profit decline, and the case study every ERP writer has cited since. National Grid went live under a different calendar gun, with Superstorm Sandy bearing down and a delay priced at roughly $50M. J&J Snack Foods went live mid-quarter during a busy period in 2022 and gave back roughly $20M in sales. Mission Produce cut over in November 2021 and, in CEO Steve Barnard’s own words on the earnings call, shipped fruit unfit for sale and had to buy from third parties to cover orders. That one cost $22.2M in gross profit.

The date always has a defensible reason. Fiscal year boundaries, license renewals, a board promise. The pattern is going live because the calendar says so, when the system’s readiness says otherwise. This is the everyday version of the “unrealistic timelines” entry on every consensus list, and it is the single most repeated line in the ledger.

2. Garbage Data at the Gate

Target Canada launched its 2013 expansion on an ERP filled by hand, at speed, by new hires. Roughly 70 percent of the manually entered supply-chain data contained errors. Orders went out wrong, shelves sat empty while warehouses overflowed, and the supply chain never recovered. Southeast Power Group spent four-plus years on a project scoped for less than one, unable to issue accurate invoices off corrupted data.

Nike belongs partly in this pattern too: its i2 engine generated demand forecasts bad enough to order the wrong shoes at scale, and a forecast is only as good as the history feeding it. Garbage in was not a metaphor. It was $100M of the wrong inventory.

Every listicle mentions data quality. What the cases add is the mechanism: bad data doesn’t degrade an ERP, it disables one, because every downstream module trusts the record upstream. Migration is where NetSuite’s “data hygiene” bullet and ECI’s “trap phase” warning stop being abstractions and start being unshippable orders.

3. The System Model vs. the Business Model

Lidl valued inventory at purchase price. SAP for Retail assumed retail price. That single modeling mismatch, plus the customization spiral that followed from refusing to change either side, consumed seven years and roughly €500M before Lidl scrapped the program in 2018. The irony is on the record: SAP had publicly named Lidl a top customer in 2017, one year before the collapse.

Haribo never mapped its legacy workflows onto the new system and watched Gold Bear sales drop about 25 percent when it couldn’t keep product on shelves. Spar Group, a case none of the ranking pages carries, lost the ability to analyze product margins after its SAP go-live. In low-margin retail, that is blindness at the exact altitude where the business lives or dies. LeasePlan wrote off €92M on a monolithic build that could not fit the digital business it was becoming. Avon spent four years and $125M on a pilot so hard to use that sales reps quit rather than adopt it, then aborted the rollout.

The consensus lists file this under “over-customization” and “business process re-engineering not in the plan.” The buyer-side translation: the fit question is testable before you sign, and none of these five tested it.

4. The Vendor Overpromise

Waste Management’s suit against SAP contains a number worth memorizing: a promised $220M in annual benefits from software pitched as an out-of-the-box fit. The suit started at $100M in 2008 and was amended to $500M before settling. Nike bet its supply chain on i2’s demand-planning engine and got $100M in lost sales, a 20 percent stock dip, and class-action suits for the trouble.

The pattern survives today in gentler forms. One vendor on page one of this very search advertises a “100 percent success rate” while noting most of its clients arrive after a failed implementation. Read that twice. A perfect record marketed to you across two decades of documented industry disasters is not evidence of safety. It is the overpromise pattern, live, in the wild. Expert witnesses who work ERP litigation describe the recurring theme in these cases as the implementation partner prioritizing its own speed over the client’s value and continuity. Flimsy requirements make the promise easy to make and impossible to check.

5. The Governance Vacuum

Birmingham City Council’s Oracle project ran from a £39M budget past £90M while problems went unreported upward, and the council, Europe’s largest local authority, was still untangling it years after go-live. The US Navy spent roughly $1B across four separate ERP pilots that could not talk to each other, then started an ~$800M replacement program. Worth & Co. churned through integrators for five years, paid $4.5M, and ended up suing Oracle.

The everyday form of this pattern, named in practitioner forums over and over, is delegation: handing the project to IT or to the vendor and checking back at go-live. Clearsulting calls it governance; NetSuite calls it leadership buy-in and too many decision-makers; Lumenia insists the sponsor hold real rank. All of those are the same observation. When nobody with organizational power owns the project, the project is unowned, and unowned projects report good news until they can’t.

6. Going Live With Known Defects

MillerCoors went live with 8 critical and 47 high-severity defects, open and documented. The result was a $100M lawsuit against HCL. PG&E left production data sitting in a demo database, exposed 47,000-plus asset records, and traced the root cause to a non-expert working a specialized testing role with no dedicated test environment. Revlon’s controls broke visibly enough that the company disclosed a material weakness in its financial reporting: an audit-grade admission that the system went live before it was ready.

Every consensus list includes “insufficient testing.” The cases sharpen it. The defect counts were known. Someone with the authority to say “not yet” looked at 8 critical defects and said “go.” The testing didn’t fail. The go/no-go decision did.

7. Treating Go-Live as the Finish Line

Clark County School District, the fifth-largest in the United States, launched a new HCM and payroll platform and started issuing wrong paychecks to educators. National Grid’s aftermath included payroll errors and 15,000 unpaid supplier invoices. Ranpak booked its $6.5M implementation, went live in January 2022, and watched $5M of profit disappear the following quarter as operations absorbed the new system.

The consensus definition is right and bears repeating plainly: success is defined by adoption, not go-live. Training, change management, and post-go-live support are where ClickLearn’s three reasons, Clearsulting’s “upskilling,” and ECI’s human-psychology framing all point. Cutover is the middle of the project. The organizations in the ledger that treated it as the end paid for the difference in the quarters that followed.

What an ERP Failure Actually Costs: Anatomy of the Bill

Page one asserts that failure costs “tens or hundreds of millions” and leaves it there. The ledger lets us do better: break the bill into categories, each with a named receipt.

Cost categoryWhat it looks likeNamed receipts
Implementation fees, sunkMoney paid before the program dies or resetsWorth & Co. $4.5M; Ranpak $6.5M; Avon $125M over four years
Write-off / abandonmentThe program scrapped outrightLidl ~€500M; LeasePlan €92M; US Navy ~$1B in pilots
Lost revenue and profitOrders you cannot ship, sales you cannot makeHershey $100M unshipped; Revlon ~$64M; Mission Produce $22.2M; J&J Snack Foods ~$20M
Remediation burnContractors hired to stabilize a broken go-liveNational Grid: 850 contractors at ~$30M/month for two years, $585M total
Settlements and legalLitigation as partial recoveryWipro paid National Grid $75M; Waste Management and MillerCoors both settled
Market reactionThe stock price votes on the go-liveRevlon down 6.9% within 24 hours; Hershey down 8% in a day; Nike down 20%

National Grid is the only case public enough to decompose fully, and the decomposition is the lesson. Total program cost: close to $1B. Fees paid to Wipro: over $100M, with Ernst and Young also engaged on the implementation. Post-go-live burn: roughly $30M a month at the program’s end. The $585M recovery figure that press coverage repeats is not the whole bill. It is the largest line item on it.

Notice the shape: the recovery cost multiples of the project. That ratio holds across the ledger, which is why the sticker price of the implementation is the least interesting number in the business case. If you want the baseline for what a healthy project should run before any of this goes wrong, we published the real numbers in our breakdown of what an SAP implementation actually costs.

The Red Flags Visible From the Boardroom

Here is the part no ranking page writes, because most of them are written by people who sell implementations. Every disaster in the ledger emitted executive-visible signals before the write-off. Not technical signals. Board-meeting signals.

  • The period-end close is stretching. National Grid’s monthly close went from 4 days to 43 after go-live. No dashboard access required; the CFO knows this number cold.
  • Integrator fees keep accruing during a “pause.” Invacare paused its program in 2021 while fees continued. By August 2022 the board had ousted CEO Matt Monaghan, citing the stalled transformation. A pause that still bills is not a pause.
  • Known defect counts at go-live. MillerCoors carried 8 critical and 47 high-severity defects across the line. If nobody will show the board the open-defect list before cutover, that is the answer.
  • Auditor findings. Revlon’s material weakness disclosure was the failure surfacing through the controls process. By then the market reaction was already booked.
  • Spend is outrunning delivered progress. The recurring theme expert witnesses report from ERP litigation: cost burn tracked against milestones actually delivered, and a partner moving at its own preferred speed rather than yours.

Then there is the pause-or-push decision itself, and the ledger’s clearest arithmetic. National Grid went live partly because a delay had been costed at roughly $50M. The broken go-live cost $585M to fix. The delay was priced. The failure wasn’t.

Bottom line: the cost of a delay is almost always smaller than the cost of a broken go-live. Price both before every go/no-go meeting, and treat any team that prices only the delay as telling you something.

The last lever is the one buyers forget they hold: the contract. Wipro paid National Grid $75M. Waste Management amended its suit against SAP from $100M to $500M and settled. MillerCoors filed against HCL in the Northern District of Illinois in March 2017 over what the complaint framed as an incomplete blueprinting phase; HCL countersued that June, and the parties settled, a sequence documented in TechTarget’s reporting on the case. Litigation is nobody’s plan A. But the recourse exists, and the quality of your statement of work decides whether it exists for you.

Boards sit at different distances from these signals. A few get all of them monthly, because they asked for exactly these numbers at kickoff. More get a status deck with a traffic light somebody negotiated. And some find out from the auditors, which is the most expensive subscription of the three.

You are in charge of your project, not your system integrator.

That line belongs to Eric Kimberling, who works ERP failures as an expert witness, writing about National Grid. His companion advice: independent, third-party quality assurance on the program is the board’s insurance policy, and it would likely have prevented the National Grid disaster outright.

The Buyer’s Prevention Playbook

Prevention advice on page one is written for project managers. This list is written for the people who approve the budget, because every pattern in Section 3 was stoppable from the buyer’s chair.

  1. Staff it honestly. Core team members give the project at least half their time, on paper, backfilled. Carry a 20 to 25 percent contingency on top of planned cost. Name the phases plainly: install the software, migrate the data, train the people. Weeks for a small firm. Months to years for a large one. Every compressed version of this sentence in the ledger ended in Section 4.
  2. Test to numeric gates, not vibes. 90 percent-plus test-case completion before go-live. Critical-defect resolution tracked and trending to zero. Every external integration validated before testing closes. The full sequence: point testing, volume and load testing, and a complete mock go-live. MillerCoors’ 8 critical defects would not have survived this paragraph.
  3. Respect the calendar. Never go live at peak season or over a month-end close. Train people within two to three weeks of first use, not months early. Budget a cutover window that assumes the data migration will not fit a weekend, because it rarely does. Hershey’s Halloween is 25 years old and still the controlling precedent.
  4. Buy independent QA. A third party with no revenue stake in the go-date, reporting to you, not the integrator. This is the National Grid lesson priced against a $585M recovery: the insurance policy costs a rounding error.
  5. Define success as adoption, not go-live. Fund change management before, during, and after cutover, and hold a post-go-live support budget you expect to spend. The ledger’s pattern-7 rows are what deleting this line item looks like.
  6. Pick the partner on delivery evidence, not badges, and put protections in the contract. The pitch team is not the delivery team, references beat logos, and the statement of work is the only card you hold when a pattern starts. We wrote the full evaluation method, scorecard included, in our guide to choosing an SAP implementation partner honestly.

One more thing a systems integrator’s blog cannot print, so we will. Every disaster in the ledger had a professional integrator on the payroll, and the integrator got paid either way; National Grid’s recovery alone moved roughly $30M a month into consulting firms for two years. Failure is a revenue stream for the industry that implements. We don’t do implementations, which is why we can put that sentence in writing, and why step 6 deserves more diligence than your last one got. If you’re staring down that selection now, describe your project and watch the engine rank partners by delivery evidence, free, no signup.

Frequently Asked Questions

What are the common reasons for ERP implementation failure?

Seven patterns cover the documented disasters: immovable go-live dates, bad data at migration, system-model misfit with the business, vendor overpromising, absent governance, going live with known defects, and treating go-live as the finish line. People and governance failures, not broken software, drive nearly all of them.

What percent of ERP implementations fail?

No verified single rate exists. The widely cited 55 to 75 percent range has no traceable primary source. Gartner’s actual prediction: by 2027, more than 70 percent of recent ERP initiatives will fail to fully meet original business goals. Panorama’s published reports show 55 to 58 percent budget overruns.

What are the failures of ERP implementation?

An ERP failure is a project that derails, falls short of expectations, or gets abandoned: significant deviation on scope, budget, or timeline. Lidl scrapped seven years of work for roughly €500M, Avon aborted after $125M, and Revlon disclosed a material weakness after its go-live disrupted shipping.

What are the problems with ERP implementation?

The recurring problems are data quality at migration, compressed timelines that force peak-season go-lives, defect-laden cutovers approved anyway, under-resourced core teams, and adoption ignored after launch. Each one is visible early: defect counts, close times, and burn rate against progress all signal trouble before the write-off does.

Sources

  • Gartner, “What IT Leaders Must Do to Avoid Disappointing ERP Initiatives” (analyst Denis Torii): the verified by-2027 prediction quoted in the failure-rate section.
  • Panorama Consulting Group, ERP Report series (public report downloads, 2015 and later editions): budget, schedule, and benefits-realization statistics. Cited by name; report-year figures as published.
  • TechTarget, “MillerCoors ERP lawsuit begins harshly, ends softly”: the litigation record for the MillerCoors v. HCL dispute.
  • Company disclosures and contemporaneous press coverage for the named cases: Hershey, Nike, Lidl, Revlon, National Grid, Waste Management, Haribo, LeasePlan, the US Navy, Birmingham City Council, Avon, Target Canada, Mission Produce, Invacare, Ranpak, J&J Snack Foods, Southeast Power Group, PG&E, Worth & Co., Spar Group, and Clark County School District. Figures appear as publicly reported; several are approximations noted with a tilde.

The disasters keep repeating because the patterns live on the buyer’s side of the table, and the buyer’s side is exactly where nobody selling an implementation can afford to point. The software will keep getting better. The seven patterns don’t care. They are organizational, they are visible from the boardroom, and they are yours to catch, which is the most optimistic sentence in this post: everything in the ledger was preventable with information that existed at the time. We’ll take the famous cases apart one at a time in upcoming autopsies. Until then, if a project is in your future, start where the evidence lives: browse the vendor directory by module and industry and pick the team that has already shipped a project shaped like yours.

Share
Need SAP help?

Describe your SAP problem in plain English and get ranked vendor matches with the reasoning to back them up.

See how it works

Keep Reading