When Gartner announced in 2020 that up to 75% of ERP projects exceed budget or deadline and 55% fail in their outcome, the market acted surprised. In 2026 you no longer see such surprise, the numbers have actually gotten worse. Our own analysis of 47 Slovak SMB implementations from 2023-2025 shows that 80% of projects end in one of four states: budget overrun of more than 50%, deadline overrun of more than 6 months, failure to meet the original business goals, or complete project abandonment before go-live.

ERP failure, however, is not random. It is a process with recognizable patterns. In this article we will name those patterns, show the five most common reasons for failure, and, more importantly, walk through proven practices that lift the probability of success from 20% to over 70%.

ERP failure is not an event, it is a process

Imagine a typical story. A company decides on a new ERP in January. In March it signs the contract. In May configuration begins. In September, go-live. In November, half the functionality does not work the way they imagined. In January of the following year, an invoice arrives for another 40,000 EUR for “out-of-scope adjustments.” In March of the second year, half of the employees still do not work in the system.

Is this a failure? Most companies would say: “No, the system is running.” But by any reasonable definition the project failed: delay, budget overrun, dissatisfied users. And what is critical: the signs of failure were already visible in April. By June the project’s fate was sealed. The September go-live was just a formal confirmation of a state that had been forming for months.

Tip: The best indicator of project health is the number of open issues and risks. If the weekly count of open risks continuously increases and higher-severity risks are not being closed, the project is failing, even if it appears to be running. Check this at every weekly status meeting.

Five most common reasons for failure

From the analysis of 47 projects, recurring patterns emerge. Rarely is it a single cause, usually two or three combine. But when ranked by frequency, we get:

Reason 1, Unclear business goals (88% of failed projects)

“We need a modern ERP.” This is not a goal. It is a wish. A goal sounds like: “Shorten the time from order to invoice from 14 days to 3 days,” or “Reduce warehouse errors from 2% to 0.3%,” or “Enable plant managers to close the books by the 5th of the month instead of the 18th.”

When you do not have measurable goals, neither the vendor nor your team knows when it is done. The project sprawls, because every new “good idea” seems relevant, and nobody has a criterion for “we are not doing this because it does not serve the goal.”

Solution: Formulate 3-5 SMART goals before signing the contract. Each goal goes into the contract as a success criterion, if we do not reach it after go-live, something in the project must change.

Reason 2, Underestimating change management (71%)

A new ERP is technically successful in 80% of cases, data is migrated, integrations work, transactions run. It fails on people. Employees do not use it, managers do not trust it, salespeople return to Excel.

The reason: change management got 2% of the project budget and was carried out as a one-day training the day before go-live.

Solution: Change management deserves 15-25% of the budget. It begins 3 months before go-live. It ends 6 months after. It contains: a communication strategy, champions in every department, training materials in multiple formats, a sandbox for experimentation, post-implementation support.

Reason 3, Poor data migration (68%)

The data from the old system is dirty. Duplicates, incomplete records, inconsistent formats. The vendor moves them as-is and delivers. Result: the new system contains old problems and 3 weeks after go-live the accountant calls saying “the invoices cannot be sorted into duplicates and non-duplicates.”

Solution: Data migration begins 6 months before go-live. It has its own plan with phases: audit, cleansing, mapping, test migration, validation, real migration, post-migration reconciliation. It is never a “side project,” it is often the most complex part of the entire implementation.

Tip: As a data quality test, do a “report sprint”, create 5 reports in the new system with migrated data and compare them with identical reports in the old system. If the numbers differ by more than 0.5%, you have a problem that needs to be solved before go-live.

Reason 4, Bad partner choice (54%)

The ERP vendor and the implementation partner are not the same. Many companies buy a “system” and do not realize that the actual work is done by the partner, a small firm that may have obtained the software license only last year.

Signs of a bad partner:

  • The project manager changes every 3 months
  • The consultant cannot answer industry questions
  • Escalation is not handled, or is handled through the vendor, not the partner
  • Documentation is poor and inconsistent

Solution: Before selecting a partner, find out: how many projects in your industry they have done, how many employees they have, what consultant turnover looks like, and who specifically your project manager will be. Ask for the CVs of the people who will be working on the project. The contract should guarantee continuity of at least the project manager.

Reason 5, Overly ambitious scope (49%)

Companies often see a new ERP as an opportunity to “solve everything at once.” They add modules they did not originally plan. Integrations that could be in phase 2. Customizations that extend the standard. Result: a project that was supposed to take 4 months takes 12, and the extra 8 cost twice as much.

Solution: Phase it. Phase 1, core modules (finance, warehouse, invoicing). Phase 2, extensions (CRM, HR, project management). Phase 3, specializations and integrations. Between phases, a minimum of 3 months of stabilization.

Anatomy of a successful implementation, 7 phases

Successful implementations have a similar structure. Let’s break it down.

Phase 1, Discovery and goals (2-4 weeks, before contract signing)

Map the current state of processes, define 3-5 business goals with measurable KPIs, identify critical constraints (legislation, integration systems, deadlines). The output is a Business Requirements Document (BRD) and acceptance criteria.

Phase 2, Solution and partner selection (4-8 weeks)

Shortlist of 3 vendors/solutions, demos with the same scenarios at each, due diligence of references, proof of concept for critical integrations. Output: a signed contract with a Statement of Work (SoW) that contains the SMART goals from Phase 1.

Phase 3, Project planning (2-3 weeks)

Kick-off, identification of the Steering Committee, appointment of a client-side project manager, team setup, detailed work plan with milestones, communication plan, risk register. Without this, only chaos can be done.

Phase 4, Configuration and customization (6-12 weeks)

Weekly sprints, each with a concrete deliverable and a demo. Engage key users (power users) from the start, not just at training. Each sprint ends with testing of business scenarios, not just unit tests.

Phase 5, Data migration (in parallel, 8-16 weeks)

Three rounds of migration, mock 1 (3 months before go-live), mock 2 (1 month before), real migration (the weekend before go-live). Between rounds, data validation through comparison reports.

Phase 6, Testing and training (4-6 weeks)

User Acceptance Testing (UAT) with real scenarios and real users. Training in small groups (max 8 people), multiple rounds, with an available sandbox instance. Train-the-trainer for internal champions.

Phase 7, Go-live and hypercare (4 weeks)

Cut-over plan with concrete tasks and owners. The first 4 weeks, intensive support, a “hypercare” team at the client, daily status calls. Gradual hand-over to standard support.

Change management, the heart of success

If you take only one insight from this article, let it be this: the success of an ERP project is 30% technology and 70% people. The best-configured system will fail if people do not adopt it. An average system will succeed if the whole organization stands behind it.

Elements of effective change management

Executive sponsor. A director or owner who publishes communications, attends status calls, and resolves escalations. Without a real sponsor, the project has no weight.

Network of champions. One person from each key department who “brings the project home.” They get early access, train others, and act as a filter for feedback.

Communication plan. Monthly newsletters with project status. An intranet page with FAQs. Open office hours with the project team. Video previews of the new system.

Different types of training. Classic classroom training (for 30% of people). Video tutorials (for 40%). Hands-on in the sandbox (for 30%). Never “everyone learns the same way.”

Post-live support. A hotline with quick answers, regular “lunch & learn” sessions, gathering feedback and quickly fixing friction points.

How to choose a good partner, five criteria

The partner matters more than the solution itself. Our case studies show that the same ERP implemented by different partners yields a 50% difference in success rate. So what to look at?

1. Industry specialization. A partner with 20 clients from your industry brings know-how that cannot be studied. It is no coincidence that successful manufacturing implementations are led by partners with a manufacturing background, not generalists.

2. Partner size relative to the project. If you are a 200,000 EUR project and the partner has 5 employees, you represent 30% of their capacity, and any outage threatens the entire project. Ideal: project = 10-25% of the partner’s capacity.

3. Team stability. Ask for staff turnover over the last 2 years. More than 30% is a warning sign.

4. Documentation culture. Ask for an anonymized example of “lessons learned” from a previous project. If the partner has no written takeaways, they are not improving.

5. References. Call 3-5 clients and ask: “If you had to do it again, would you choose the same team?”

Numerical benchmark, what a “good” project looks like

Of our 47 projects, the successful ones (top 20%) had these characteristics:

  • Budget overrun on average 8% (vs. 65% for failed projects)
  • Deadline overrun on average 12 days (vs. 4 months for failed projects)
  • User adoption 3 months after go-live: 85%+ (vs. 35% for failed)
  • ROI achieved within 18 months of go-live: 100% (vs. 20% for failed)
  • Change management budget: 18% of total cost (vs. 3% for failed)
  • Phasing: 2-3 phases (vs. “big bang” for failed)

The pattern is clear: less ambition at once, more investment in people, better planning.

Conclusion, failure is predictable, success is plannable

80% of ERP implementations fail. That is the bad news. The good news: failure is not random, it is the result of predictable mistakes. When you avoid those mistakes, unclear goals, underestimating the human factor, poor migration, the wrong partner, scope overcombination, you get into the top 20% where projects succeed.

The key is admitting that ERP is not an IT project. It is a business transformation project with an IT component. Whoever pilots it from the IT department without a strong business sponsor makes the first mistake even before signing. Whoever invests 3% in change management and 97% in technology makes the second.

If you are facing an ERP project and want to increase the probability of success, reach out to us. In a 60-minute free consultation we will go through your plan, identify risk points, and propose adjustments. You can move from 80/20 to 30/70, but you have to start with the right questions, not with a software order.