ERP implementation challenges have been cataloged in the same vendor listicles for twenty years, and the same seven still sink projects: Hershey left $100 million of Halloween orders unshipped in 1999, and Mission Produce was shipping fruit it could not properly invoice in 2021, for substantially the same reasons. An enterprise resource planning (ERP) system replaces the software that runs your finance, inventory, payroll, and orders with one integrated platform, which is exactly why an implementation touches everything and why the failure modes repeat.
Here is the position this post will defend: the challenges are predictable. What is rare is a buyer who plans against them with numbers instead of adjectives. The pages that rank for this topic will give you ten bullet points and a demo link. None of them will tell you what each challenge costs when it lands, name a company it landed on, or give you a single measurable criterion for beating it.
This post does all three. Seven challenges, one named failure each, and the numbers that separate the projects that survive from the ones that end up in earnings calls and courtrooms.
How Often ERP Implementation Challenges Become Failures
Start with the statistic you have probably already read: “70% of ERP implementations fail, according to Gartner.” It circulates on page after page, and almost nobody links a source, because the primary document behind that exact sentence does not exist.
What Gartner actually published is a prediction, and it is worth quoting precisely: Gartner research predicts that by 2027, more than 70% of recently implemented ERP initiatives will “fail to fully meet their original business goals.” That is analyst Denis Torii, on Gartner’s own site. Failing to fully meet goals is a lower bar than “failure,” and a forecast is a different thing from a measurement. The distinction matters if you are using the number to size your own risk.
The measured numbers are less dramatic and more useful. Panorama Consulting, which has published an annual ERP report for over a decade, put budget overruns at 58% of projects and schedule overruns at 65% in its published report data, with year-to-year swings (55% and 75% appear in other editions). In the same research, 53% of organizations realized less than half of the business benefits they expected, and roughly 40% discovered mid-project that they had underestimated staffing.
| The Claim You Will Read | Where It Circulates | What the Primary Source Says |
|---|---|---|
| “70% of ERP implementations fail (Gartner)” | Vendor blogs, unlinked, including one page ranking for this exact keyword | Gartner’s published statement is a prediction: by 2027, more than 70% of recent ERP initiatives will fail to fully meet original business goals (Denis Torii, gartner.com) |
| “55% to 75% of ERP projects fail” | Quoted without a document, attributed to Gartner | No primary document exists. Treat the range as folklore |
| “Most projects overrun” | Asserted without figures | Panorama’s published reports: 58% exceeded budget, 65% overran schedule, 53% realized under half of expected benefits |
So the honest read is this: most ERP projects go over budget or schedule, about half disappoint on benefits, and a minority fail outright. The interesting question is not the rate. It is the pattern. We dissected twenty named disasters in our hub post on why ERP implementations fail, and the same seven patterns explain nearly all of them. This post walks the same seven from the other direction: not as an autopsy, but as the list of what you will face and how to beat each one.
| Challenge | The Company That Hit It | What It Cost |
|---|---|---|
| 1. The go-live date is set before the plan exists | Hershey, 1999 | $100M in unshipped orders, 19% quarterly profit decline |
| 2. Your data is worse than you think | Target Canada, 2013 | Roughly 70% of manually entered supply-chain records held errors |
| 3. The system’s model is not your business model | Lidl, 2011-2018 | Around €500M written off after seven years |
| 4. Everyone selling to you is overpromising | Waste Management, 2005-2010 | $100M suit against SAP, amended toward $500M, settled |
| 5. Nobody owns the project | National Grid, 2012 | $585M recovery effort; Wipro paid $75M to settle |
| 6. Going live with known defects | MillerCoors, 2014 | Live with 8 critical defects; $100M suit, settled |
| 7. Treating go-live as the finish line | Revlon, 2018 | Material weakness disclosed, ~$64M in lost sales, 6.9% stock drop in a day |
Every figure in that table is public record: earnings disclosures, court filings, or sustained press coverage. Not one of the ten pages ranking for this keyword names even one of these cases. Keep the table in mind as you read; each challenge below picks up its row.
Challenge 1: The Go-Live Date Is Set Before the Plan Exists
Most ERP timelines are political artifacts. A fiscal-year boundary, a contract renewal, a board promise, and suddenly the project has a date before it has a scope. The work is then compressed to fit the date, and the compression comes out of the phases that fail quietly: testing, training, data reconciliation.
Hershey is the canonical case, and we broke it down fully in our Hershey ERP failure post. The integrator’s recommended 48-month scope was squeezed into 30 months so the system would land before Y2K, which pushed go-live into the Halloween ordering season. The software worked. The order-fulfillment process around it did not, $100 million of orders went unshipped, and quarterly profit dropped 19%.
The realistic durations are knowable in advance. An implementation moves through the same phases everywhere (discovery and planning, design, build, data migration, testing, deployment, then support), and the whole sequence runs from a few months at a small company to well over a year at a large one. The testing block alone runs 10 to 15 weeks in practitioner planning guides, with integration testing taking 4 to 6 of those weeks. Cloud deployments compress the phases (one practitioner comparison puts the design phase at 2 months versus 3.5 on-premise, and build at 4 versus 7), but they compress, not eliminate.
How to beat it:
- Derive the date from the plan, never the plan from the date. If the date moves first, say so out loud and re-scope in the open.
- Carry a 20-25% contingency on both budget and schedule. Scope creep and underestimated staffing are the two most common causes of overruns in survey data cited across the industry, and both are certainties, not risks.
- Treat phase-gate dates as forecasts that update. A date that cannot move is a decision to cut testing; you just have not admitted it yet.
Challenge 2: Your Data Is Worse Than You Think
Every company believes its master data is basically fine. Then the migration starts, and the duplicates, dead suppliers, inconsistent addresses, and fields that mean different things in different departments all surface at once. Data migration typically eats 10-15% of total project cost in industry estimates, and it is the line item most often missing from the proposal that won your business.
Target Canada shows the ceiling on this problem. During its 2013 expansion, roughly 70% of the supply-chain data manually loaded into its new systems contained errors: wrong dimensions, wrong costs, wrong vendor terms. Shelves sat empty while warehouses overflowed. The data was the operating model, and the data was wrong.
There are real numbers for the fix as well. A 2025 peer-reviewed engineering study of ERP migrations found data-quality issues behind roughly 32% of migration delays and 27% of budget overruns, and found that organizations investing 12-15% of project budget in data quality saw about 41% fewer implementation issues. Teams running structured validation frameworks achieved measurably higher data accuracy than teams that migrated first and reconciled later. Profile the data before you sign the implementation contract, not after.
- Assign ownership by department: accounting owns financial data, service owns customer records, operations owns the item master. Unowned data does not get cleaned.
- Dedupe, validate, and fill gaps before load. Migrating garbage faster is not progress.
- Reconcile against source systems with end users in the loop, because they know which fields are lies.
SAP-specific migrations have their own failure anatomy, which we covered in why SAP data migrations blow up. The short version applies to every platform: the data workstream is a project, staff it like one.
Challenge 3: The System’s Model Isn’t Your Business Model
Every ERP package embeds assumptions about how a business runs: how inventory is valued, how orders flow, how approvals chain. When those assumptions fit your operation, configuration is straightforward. When they do not, you face the real decision of the whole project: change the process or change the software.
Lidl chose to change the software. The retailer ran its inventory management on purchase prices; SAP’s retail standard assumed sale prices. Rather than adapt, Lidl customized against the grain of the system for seven years, and wrote off around €500 million when it scrapped the project in 2018. The bitter footnote: SAP had named Lidl a top customer one year before the collapse. Avon hit the same wall from the user side in 2013, abandoning a four-year, $125 million rollout after sales reps found the new ordering system so hard to use that they started quitting.
The consultant’s rulebook is blunt on this. As Günter Dusch puts it in SAP Basics, Tips and Tricks for Prospective SAP Consultants (translated from the German): “SAP standard objects are never changed in Customizing! Copying and adapting is the correct procedure.” The rule generalizes past SAP: heavy customization is not a workaround for a model mismatch, it is a decision to maintain your own software fork forever.
Map your processes before configuration starts, and be honest about which ones are genuinely differentiating. Most are not, and standard process plus retraining is cheaper than custom code plus upgrades. A few are, and compliance obligations (tax rules, GDPR, SOX controls, industry certifications) belong in scope from day one rather than discovered as change orders. The failure mode on one side is Lidl. On the other side it is a company that paved its old cow paths into the new system and bought nothing but a migration.
Challenge 4: Everyone Selling to You Is Overpromising
The demo was flawless. Demos are. The demo environment has clean master data, no volume load, and no interfaces to your 15-year-old warehouse system. The estimate attached to it is the number that won a competitive bid, which means it is the optimistic scenario by construction.
Here is the sentence a systems integrator (SI, the consulting firm that implements the software) cannot print: the estimate that wins your deal is the one that flatters your assumptions, and the vendor billing by the hour is not incentivized to correct your schedule fantasy before signature. That is not villainy, it is structure. Waste Management’s lawsuit against SAP pleaded that the sales cycle promised $220 million in annual benefits from a system the suit alleged was demoed in a rigged environment; the claim started at $100 million in damages, grew toward $500 million, and settled. MillerCoors and HCL spent 2017 suing each other over whose fault an understaffed blueprint phase was, and settled too. The pattern survives every software generation because the incentive does.
Rates are part of the same fog. A widely cited industry figure puts ERP consultants at $150-175 per hour plus travel, but that number dates from 2020 and moves sharply with seniority, region, and how much of the team sits offshore. Treat any single blended rate as a question, not an answer: whose hours, at what tier, on which workstream, and what happens to the rate when the people you met in the sales cycle roll off.
What to demand before signing: the named delivery team, not the bench. References from projects that actually shipped, at your scale, in your industry. Every assumption behind the estimate in writing, so a broken assumption becomes a conversation instead of a change-order ambush. Vendor-published criteria lists (industry experience, support model, training capability, scalability) are fine as far as they go; they are also written by the people being evaluated. Finding a partner whose track record you can check independently is the actual problem, and it is the one our engine works on: describe your project and watch it rank vendors against your requirements, free, no signup, no sales call attached.
Challenge 5: Nobody Owns the Project (and Everyone Is Part-Time)
Ask who owns your ERP project and you will usually get a committee. Ask whose bonus depends on it and the room goes quiet. That vacuum is where projects die, because every hard call (pause or push, cut scope or slip the date) lands with the party that has the least incentive to make it honestly: the integrator.
National Grid is the buyer-side anatomy lesson. The utility went live in 2012 with a hurricane bearing down and a delay priced at roughly $50 million on the table. It pushed. What followed, per the litigation record: payroll errors, 15,000 unpaid supplier invoices, a period-end close that went from 4 days to 43, and a recovery effort that ran 850 contractors at a burn near $30 million a month for two years, about $585 million in all. Wipro paid $75 million to settle; the total program has been reported near $1 billion. The 4-to-43-day close is the detail worth memorizing, because it is the red flag any executive can read without a single technical briefing.
The staffing version of the same vacuum hides in plain sight, and the advice pages contradict each other about it. One ranking page cites SAP guidance that key project-team members need at least 25% of their week; another says 50% for months or years. Practitioners who have run these projects say neither works: core roles need to be full-time, with backfills hired so the business keeps running. Half attention produces full problems. Panorama’s finding that around 40% of organizations underestimated staffing is what that spread looks like after the fact.
- Name one accountable executive sponsor with real rank, and put them in every quality-gate review.
- Backfill your key users’ day jobs. Never schedule finance during month-end close or the warehouse during peak season.
- Buy independent quality assurance that reports to you, not to the integrator. Expert witnesses who work ERP lawsuits list the same recurring warning sign: an implementation partner prioritizing its own speed over the buyer’s continuity, with nobody contractually positioned to say so.
- Remember that ownership has consequences upward, too. When Invacare’s transformation stalled in 2021, the board did not fire the integrator. In 2022 it removed the CEO.
Challenge 6: Going Live With Defects You Already Know About
No project goes live defect-free, and no honest advisor will promise you one that does. The failure pattern is narrower: going live with critical defects you have already logged, because the date won the argument. MillerCoors went live in 2014 carrying 8 critical and 47 high-priority defects, by the account in its own subsequent lawsuit. Everyone knew. The go-live happened anyway.
“Test adequately” is the advice every ranking page offers, and it is advice you cannot operationalize. These are the gates practitioners actually use, and they are numbers, not adjectives:
| Go/No-Go Gate | The Standard | The Counterexample |
|---|---|---|
| Test-case completion | 90%+ of planned cases executed | MillerCoors: live with 8 critical, 47 high defects logged |
| Critical defects | Zero unresolved at go/no-go | Same case; the defect list became the lawsuit exhibit |
| Integrations | Every external interface validated end-to-end before testing closes | National Grid: payroll and supplier invoicing broke on contact |
| Test environment | Realistic data under real load, in a dedicated environment | PG&E: production data left in a demo database exposed 47,000+ asset records |
| Cutover timing | Never at peak season or month-end | Hershey: go-live into Halloween ordering |
| Quality gates | Hard stops; unmet exit criteria halt the phase | Every case above skipped at least one gate to hold a date |
Whether you cut over big-bang or in phases changes the blast radius, not the physics: a phased rollout by module or region caps how much can break at once, at the price of running two systems side by side longer.
Bottom line: the pause is almost always cheaper than the wreck. National Grid priced its delay at roughly $50 million and pushed; the recovery cost $585 million. A slipped date is a bad quarter. A broken go-live is a bad half-decade.
Challenge 7: Treating Go-Live as the Finish Line
Projects are staffed, budgeted, and bonused to reach go-live. Then the consultants roll off, the war room empties, and the actual test begins: will a thousand people do their jobs in this system tomorrow morning? Success is adoption, not cutover, and ERP systems stay in service for a decade or more, so the adoption curve is the asset you were buying all along.
Revlon shows what the morning after looks like when this challenge wins. Its system went live in 2018; the business around it was not ready. The company disclosed a material weakness in its financial controls, attributed roughly $64 million in lost sales to service-level disruption at one distribution center, watched the stock fall 6.9% within a day of the disclosure, and collected investor lawsuits. The system was live. The business was not.
Training fails on timing more than on content. One implementation lead describes a retail client that trained every user two months before go-live; by launch day they had forgotten most of it, and the project ended up printing refresher job aids at every workstation and doubling floor support. Train within 2 to 3 weeks of first use, by role, with floor support and a named escalation path for the first weeks. One-and-done classroom sessions before cutover are how resistance to change gets manufactured: people do not resist the software so much as they resist being made bad at their jobs overnight.
- Budget hypercare (the intensive support window after go-live) for 3 to 6 months before the project starts, not out of whatever money is left.
- Define success as adoption metrics (transaction error rates, support-ticket trends, cycle times), and report them to the sponsor monthly.
- Expect the first enhancement requests within 3 to 6 months, and keep enough team to act on them. The system that cannot absorb its first change requests is already aging.
Frequently Asked Questions
What is a common challenge in ERP implementation?
Data quality is the most consistently underestimated one: duplicates, dead records, and inconsistent fields surface during migration, which typically consumes 10-15% of project cost. The most damaging, though, is a go-live date fixed before scope is understood, because it silently cuts testing and training.
What are the common ERP implementation failures?
The public record shows seven repeating patterns: compressed timelines (Hershey), bad data (Target Canada), forcing the system against the business model (Lidl), vendor overpromise (Waste Management), governance vacuum (National Grid), going live with known defects (MillerCoors), and abandoning the project at go-live (Revlon).
Why is ERP implementation so hard?
Because it is an organizational change wearing a software costume. One system replaces every department’s habits at once, so it inherits every process ambiguity, data sin, and political fault line you already have. The technology usually works; the schedule, staffing, and ownership decisions around it are what fail.
What are the 4 key ERP implementation strategies?
Big-bang (everything at once, fastest and riskiest), phased (by module or region, slower but contained), parallel (old and new run together, safest and most expensive), and hybrid combinations. Panorama’s overrun data argues for phasing anything large: 65% of projects already miss their schedules without betting the whole company on one weekend.
Sources
- Gartner, “What IT Leaders Must Do to Avoid Disappointing ERP Initiatives” (Denis Torii): the verified 2027 prediction quoted in the statistics section.
- Panorama Consulting ERP Report archives: budget, schedule, benefits, and staffing figures.
- World Journal of Advanced Engineering Technology and Sciences (2025), ERP migration study: data-quality delay, overrun, and investment figures.
- Günter Dusch, SAP Basics, Tips and Tricks for Prospective SAP Consultants (English 2nd edition, translated from the German): quoted on customization discipline.
- Case figures (Hershey, Target Canada, Lidl, Avon, Waste Management, MillerCoors, National Grid, PG&E, Revlon, Invacare, Mission Produce): public earnings disclosures, court filings, and sustained press coverage, as compiled in our hub analysis of why ERP implementations fail.
All seven challenges are beatable, and here is the uncomfortable symmetry: every company in the table above beat none of the ones that mattered on its project. The playbook is not secret. Realistic dates, profiled data, honest fit decisions, verified vendors, full-time ownership, numeric gates, and a budget that extends past go-live. The discipline is available to any buyer willing to own the project instead of renting ownership from the people selling it. If you are assembling your shortlist, browse the vendor directory by module and industry and start with delivery records instead of logos.
