There are a lot of ways ERP systems can fail. Many businesses rush into rolling out new functions without carefully considering the details -- or knowing the common reasons for ERP implementation failure.
"It takes time, dedicated training and adequate management for ERP to flourish as a proficient tool within your business," said Jenny Chua, business development manager at The World Management, an ERP consultancy in Singapore.
John Belden, chief of strategy and research at Boston-based UpperEdge, an IT negotiations consultancy, commonly sees three key characteristics of these projects that often contribute to ERP implementation failure:
- ERP implementations are often two to 10 times bigger than previous projects.
- They are transformational, which means there are winners and losers in the organization because of the digital transformation enabled by the implementation.
- They are generational, which means an organization might not have done anything comparable in a decade or more.
"A program will have problems when enterprises don't recognize these issues and try and mitigate these risks," Belden said.
Here are 13 well-publicized cases of ERP implementation failure that illustrate some of the main reasons why these projects fail and how to avoid them.
1. Nike's unrealistic goals
Nike thought it could "Just Do It" when it embarked on a $400 million upgrade of its ERP system in 2000. But the new system resulted in $100 million in lost sales and a 20% drop in stock price when it couldn't fulfill orders for Air Jordan footwear.
"Nike was overly optimistic in their goals, and they failed to verify business process met operational needs before deploying the system," said Alex Sharpe, principal at Sharpe LLC, a management consultancy.
The lesson: It's important to set realistic goals in the implementation plan, especially regarding ERP functionality and project schedules. Sharpe also recommends defining operational and business requirements early on and keeping them in mind when developing systems.
"Ensure you take enough time to test the system for any kinks that need to be ironed out before putting your system into production," he said.
2. MillerCoors' hiring the wrong people for the job
MillerCoors (now Molson Coors Beverage Co.) embarked on an ambitious plan to consolidate its financials on a single ERP system to reduce costs and improve operational efficiency. In 2014, it hired HCL Technologies to implement the project, which was stalled by numerous defects. MillerCoors ended up suing HCL for $100 million, and the lawsuit was finally resolved in 2018.
Deepak Lalwani, principal and management consultant at Deepak Lalwani & Associates, an IT consultancy, said the problem arose because the planning and architectural phases were not given adequate consideration. In addition, many critical defects and other problems were identified but not fixed.
HCL's core competency was generally regarded as implementation, not planning and architecture.
The lesson: Ensure you have the right ERP expertise for the particular project. "IT is often the toughest and the most expensive part of integrating multiple companies, and they rushed through the planning and architecture phase only to get hurt by it later," Lalwani said.
3. Revlon's underestimation of operational impact
Revlon attempted to integrate its ERP processes across business units after a merger with Elizabeth Arden in 2016. The new system failed spectacularly after it went live in 2018, resulting in a loss of $64 million in sales, a 6.4% loss in stock price and an investor lawsuit.
A key issue was that Revlon had attempted to consolidate Microsoft and Oracle systems on a new SAP implementation but lacked hands-on experience with SAP. It also decided to go live without making sure the ERP business processes would work as intended.
"Rolling out a system that does not meet operational needs and requirements often leads to adverse business impacts," Lalwani said.
The lesson: Mind both the operational and business sides of the ERP equation.
4. National Grid's lack of disaster testing
National Grid's ERP implementation was essentially blown away by Hurricane Sandy in 2012 when the utility attempted to consolidate its U.S. operations on a common SAP system. Ultimately, the project took two years to clean up, at a cost of $585 million.
The parent company had successfully worked with the Wipro consulting firm on a similar ERP consolidation in Europe, but the ERP project team struggled with major differences in the regulatory environments in the U.S. Wipro suggested the SAP ERP project was ready to go live based on test results, but the actual system did not hold up under the increased workload. Emergency business processes were required to repair the electric grid after the hurricane, which involved special procedures for bringing in workers and materials from other utilities for the extensive repairs.
Belden said the implementation team had focused on "happy path" testing, which involved testing functions under ideal circumstances, but there had been insufficient testing of the system in emergency scenarios. National Grid decided to go live as the hurricane was making its way up the coast.
The lesson: It is vital to assess all the factors that can affect readiness before going live with a large ERP implementation.
5. Waste Management's failure to verify vendor claims
Waste Management ran into some major snags when it attempted a massive SAP installation in 2005. After numerous problems and delays, the company ended up in a $500 million lawsuit against SAP that was eventually settled out of court.
SAP had suggested Waste Management could achieve $106 million to $220 million in annual benefits from a consolidated ERP system that could be implemented in 18 months.
Lalwani said one big problem was Waste Management's failure to verify SAP's claims before making an executive decision. The company quickly discovered there were significant gaps between what was promised and what was delivered in the software.
The lesson: Verify vendor claims with internal business and technical teams. "Performing a proof of concept on critical functionality … can reduce significant risk," Lalwani said.
6. Invacare's ERP system catches a cold
Medical device manufacturer Invacare's ERP project faced a key setback in rolling out a major SAP upgrade in 2021. Unfortunately, the company had to pay a monthly maintenance fee to the system integrator as the project dragged on into 2022, and the fed-up board went shopping for a new CEO in August 2022. The stalled project added to mounting financial pressure: Invacare filed for Chapter 11 bankruptcy protection on Jan. 31, 2023, and emerged that May with significantly reduced debt. Its North American unit, about 40% of revenue, had been hit hardest, and the company flagged its IT infrastructure among the areas due for a rethink.
"ERP implementations are one of the most resource-intensive projects a company can pursue; budget and timeline mismanagement can derail an ERP project or stop it altogether." said Gaurav Joshi, senior director of supply chain advisory at Haskoning, a civil engineering consultancy.
The software and support vendors a company chooses can make all the difference. Joshi has found it important to conduct a request for proposal process that includes a comparative bid analysis, vendor demos and a scorecard filled in by key stakeholders.
The lesson: It's important to accurately estimate the total cost of ownership, have a timeline that considers all services and partners, and develop a plan to avoid cost overruns due to change orders or delays.
7. PG&E's production data leak
In 2016, Pacific Gas and Electric faced a significant security breach when a third-party vendor hired to create a new asset management platform copied live PG&E data to its own network without implementing necessary security measures during Oracle ERP testing. This led to more than 30,000 data items being online and accessible for nearly 70 days.
A white-hat security researcher alerted PG&E to the breach, prompting the utility company to initiate recovery efforts. These efforts resulted in substantial costs and a nearly $3 million fine. In addition to financial expenses, PG&E's reputation and customer confidence in how the utility manages sensitive data were damaged.
The lesson: Make sure project teams possess the required technical expertise, and use a dedicated testing environment that doesn't handle live data.
8. Cover Oregon's outsized project
Bigger projects tend to put an organization in a position where it is not prepared for the volume and magnitude of decisions required. As a result, overwhelmed teams end up piling on one bad decision after another.
Belden said a classic example was the 2012 attempt by the state online healthcare marketplace, Cover Oregon, to simultaneously implement Obamacare and replace its supporting transaction processing systems. It ultimately spent more than $300 million and was unable to process a single insurance application through the exchange.
"They created a scenario where the project got so enormous, they could not meet the due dates," Belden said, or make the decisions that were required. Problems were exacerbated by the need to meet the hard deadline imposed by Obamacare. Belden said he believes the project would have worked out if Cover Oregon had kept the ERP project smaller and restricted it to what would have been required for Obamacare.
The lesson: Limit the scope of the ERP project to the appropriate time frame.
9. Israel Chemical Limited's narrow focus
Generational problems can occur when no one on the program management team understands where the problems are.
"They may have prior experience, but it was 10 to 15 years ago and the people who learned the lessons are somewhere else in the organization or have moved on," Belden said.
A good example is Israel Chemical Limited's failed SAP ERP implementation in 2014. The project cost ballooned from $120 million to more than $500 million. Ultimately, the company's CEO resigned, and the entire implementation was cancelled.
The CEO had assigned the project to a relatively new person in the CFO office, according to Belden. This project lead was primarily focused on making sure financials were properly incorporated into the ERP project and did not adequately consider the needs of the manufacturing and supply chain sides of the business. Employees in the first factory revolted after they had the new system imposed upon them.
"They got more focused on financial integrity rather than operational integrity," Belden said.
The lesson: Focus on all users of the proposed ERP implementation and not just one part of the business.
When AI and agents enter the picture
The aforementioned failures predate the current wave of enterprise AI, but the same tendencies to overpromise, skip the hard verification and automate a broken process are resurfacing as companies layer generative and agentic AI onto systems like ERP. The following patterns aren't always ERP-specific, but they are showing up wherever organizations bolt AI onto core operations.
10. Mistaking consolidation gains for agentic ROI
Vendors increasingly pitch double-digit ROI from layering agentic AI onto ERP, but those numbers often rest on a baseline that was already broken. Joshua Greenbaum, principal at Enterprise Applications Consulting, pointed to one company that lifted its contract win rate from 10% to roughly 40% after a transformation it credited to AI. The catch: the same project consolidated 11 disparate legacy ERP systems into one. "Every time I look at these big wins, I ask the question: what was the baseline?" Greenbaum said. Most of the gain, he argued, came from the consolidation itself, the kind of well-executed transformation that delivers double-digit returns before a single agent is switched on. The same failure to model the full picture shows up beyond ERP: Klarna's widely reported plan to replace some 700 customer service agents with AI booked the headcount savings but not the cost of the quality drop and rehiring that followed, leading the fintech to walk back the strategy within a year.
The lesson: Isolate the contribution of the AI from the underlying transformation, and model the full cost, not just the headline savings. Ask what the baseline process looked like and how much of the improvement would have been produced by consolidation alone.
11. Stringing together agents that are only mostly right
Enterprises rushing to give agents autonomy are running into a reliability ceiling. Greenbaum noted that companies "don't really dare let agents be fully autonomous." They aren't yet trustworthy enough for the million-dollar decisions ERP touches. Even granting an agent the benefit of the doubt at 95% accuracy, stringing several agents together compounds the error quickly into something unreliable. Much of what agentic AI promises, Greenbaum argued, amounts to papering over messy underlying processes rather than fixing them. The accountability stakes are already visible outside ERP: in early 2024, Canada's Civil Resolution Tribunal held Air Canada liable after its website chatbot invented a bereavement-fare refund policy, rejecting the airline's argument that the chatbot was a separate entity responsible for its own statements.
The lesson: Keep a human in the loop for high-stakes decisions, treat compounding errors across chained agents as a design constraint and assume the organization owns whatever its agents assert.
12. Treating AI prompts as private
As companies wire AI tools into ERP and finance workflows, many assume their prompts and the model's answers stay private. They don't necessarily. Brian Sommer, president of analyst firm TechVentive, pointed to U.S. case law in which an executive asked an AI tool for a strategy to avoid paying merger breakup fees. The prompt proved fully discoverable, was entered into evidence and helped sink the executive's case. "It's not your AI," nor are the prompts you put in there or the answers you get back, Sommer said. The same exposure feeds data-sovereignty concerns that are common in Western Europe, such as which AI tools touch the data and which foreign governments can reach it.
The lesson: Treat AI prompts and outputs as discoverable business records. For sensitive work, weigh in-country or private large language model deployments and govern what data leaves the building.
13. Expecting ERP data to answer questions it never captured
A recurring disappointment is asking AI to forecast based on ERP data that was never designed for the job. Sommer described a CFO at a seasonal manufacturer who invested heavily in AI sales forecasting and eventually identified 47 useful indicators, of which exactly one, last year's sales, came from internal ERP data. Everything else was external: macroeconomic signals, long-range weather forecasts and more. ERP automates a narrow band of accounting-driven transactions, Sommer noted, and it has no view of the external events, such as a closed shipping lane or a supply shock, that actually shift the business.
The lesson: Before layering AI onto ERP, map what the system actually captures. Most high-value questions depend on external data the ERP was never built to hold.
How to avoid ERP implementation failures
The following are some common steps to consider during an ERP implementation:
- Select a knowledgeable vendor. Evaluate ERP vendors with a history of successful software implementations.
- Get feedback from all stakeholders and build the migration team. To enhance project success, get feedback from all departments, ensure key migration team roles are filled and install a knowledgeable project manager.
- Control project costs. Ensure staff resources are available and finalize what features and capabilities are required for the project. Staffing changes and last-minute customizations can lead to scope creep that drives up costs.
- Establish a realistic timeline. Larger organizations consolidating multiple legacy systems will need to extend their migration timeline.
- Prioritize change management. Map current business processes to the new ERP system to smooth the transition and training.
- Focus on system integration. The newly selected ERP system should integrate as seamlessly as possible with internal systems and any other tools that might be implemented.
- Ensure data quality. Most organizations have data stored in different formats and owned by different stakeholders. All data for the new ERP database should be accurate and consistent before it's migrated.
Editor's note: This article was updated in June 2025 and again in October 2026 to include additional ERP projects and to improve the reader experience.
George Lawton is a journalist based in London. Over the last 30 years he has written more than 3,000 stories about computers, communications, knowledge management, business, health and other areas that interest him.
