Why ERP projects fail: the mistakes to avoid and how to avoid them

Most ERP projects that fail do not fail because of the software. They fail because of decisions taken, or avoided, long before the first screen is configured. If you are weighing up an ERP project, understanding the typical causes of ERP project failure is one of the most useful things you can do before you sign a contract.

This guide goes through the mistakes we see most often, one section each, and gives the remedy for every one. It applies equally to a first system for a growing business and to a replacement of an ageing platform. For the wider picture of how a project unfolds, read our guide to ERP implementation.

What does a failed ERP project look like?

Failure is rarely a dramatic collapse. More often it is a slow disappointment. The common forms are:

• a go-live that is delayed repeatedly until confidence is lost;
• a budget that grows well beyond the original quote because the scope was never pinned down;
• a system that goes live but that staff work around with spreadsheets;
• reports that nobody trusts because the underlying data is wrong;
• a solution so heavily customised that every update becomes a project in itself.

In each case the business has paid for a system and still cannot run on it comfortably. That is the definition of failure that matters: not whether the software was installed, but whether the company actually operates better afterwards.

The mistakes that cause ERP projects to fail

1. Starting without a clear business case

Many projects begin with a vague feeling that the current tools are creaking. That is a reason to look at the market, not a reason to buy. Without a clear statement of what must improve, nobody can judge whether the project succeeded, and every stakeholder carries a different, unspoken expectation.

The remedy. Write down the outcomes you want in plain language: faster month-end close, reliable stock visibility, fewer manual re-keying steps, better control of purchasing, smoother VAT reporting. Agree them at board level and tie each to something that can be observed after go-live. This document will guide every later decision.

2. Vague or incomplete requirements

This is the most frequent root cause. A requirements list that says "good reporting" or "integration with our e-commerce platform" leaves enormous room for interpretation. Suppliers answer the question they think you asked, quotes become impossible to compare, and the gaps surface during the project, when they are most expensive to close.

The remedy. Document how your business really works, including the awkward exceptions: unusual pricing rules, multi-site stock, intercompany trading, subcontracting, rebates. Distinguish what is essential from what is merely desirable. Our ERP requirements template gives you a structure to follow, and it is worth involving the people who do the work every day rather than only managers.

3. Choosing on the demonstration or the price alone

A polished demonstration shows the product at its best, with clean sample data and a prepared scenario. A low headline price may hide limited scope, optional modules or a thin implementation budget. Choosing on either basis alone is a common route to regret.

The remedy. Ask each shortlisted supplier to demonstrate your own scenarios, using your own awkward cases. Compare the total cost of ownership over the life of the system, not just the first-year figure; our guide to ERP cost explains what to include. For a structured approach, see how to choose an ERP.

4. Underestimating data migration

Existing data is almost always messier than people believe: duplicate customers, inconsistent product codes, obsolete suppliers, open orders in several formats. Loading that into a new system simply recreates the old confusion, now with a new interface. Data work is also routinely left until the end, when time is short.

The remedy. Treat data as a workstream with its own owner from the first week. Decide what to migrate, what to archive and what to leave behind. Clean and standardise before loading, run trial migrations, and reconcile the results against your accounts. The detail is covered in our guide to ERP migration.

5. Customising too much

Every business believes its processes are unique. Some are, and give a genuine competitive edge. Many are simply habits built around the limitations of the old system. Heavy customisation increases cost, lengthens testing and makes upgrades difficult, which defeats part of the purpose of a modern platform.

The remedy. Apply a simple rule: adapt the process to the standard product wherever it does no harm, and customise only where the difference creates real value. Ask your integrator to justify each proposed development against that test. Configuration and standard options should always be considered first.

6. A weak sponsor and unclear governance

An ERP project crosses finance, operations, sales, purchasing and IT. When decisions between those functions are left to a committee with no authority, disputes stall the project. When the sponsor is absent after the kick-off, the team learns that the project is not really a priority.

The remedy. Appoint an executive sponsor who can settle disagreements and who attends regular steering meetings. Name a dedicated internal project lead with enough time to do the job, not someone fitting it around a full workload. Set out who decides what, and how change requests are approved.

7. Neglecting people and change management

A system can be technically perfect and still be rejected by the people expected to use it. Staff who were not consulted, who fear for their roles, or who simply do not understand why things are changing will find ways to avoid it. Resistance is rarely stubbornness; it is usually a sign that communication was inadequate.

The remedy. Involve key users from the start, explain the reasons for the change and listen to their objections. Identify champions in each department. Be honest about how roles will evolve. Change management is not an optional extra to be trimmed when the budget tightens.

8. Cutting corners on testing and training

When timelines slip, testing and training are the first items to be squeezed, because they come last. Yet this is exactly where problems are found cheaply, before real customers and real invoices are involved. Users who meet the system for the first time on the day of go-live will struggle.

The remedy. Protect the time for testing with realistic scenarios drawn from your daily business, including month-end, returns, credit notes and exceptions. Let the actual users run the tests and sign them off. Train people on their own processes using a copy of your data, close to go-live so the knowledge is fresh.

9. Unrealistic timelines and budgets

Pressure to go live by a particular event, such as a year end or a lease expiry, drives compromise. A timeline built to please rather than to reflect the scope leads to rushed data work, thin testing and a difficult launch. Budgets that ignore internal time, training, contingency and post-go-live support cause similar trouble.

The remedy. Build the plan from the scope upwards, with your integrator, and include a realistic allowance for your own staff's time. Keep a contingency for the unexpected. If a fixed date is unavoidable, reduce the scope of the first phase instead of squeezing the quality of what is delivered.

10. Picking the wrong integrator, or leaving roles unclear

The integrator shapes the experience far more than most buyers expect. A team without experience in your sector will learn on your project. Equally, if responsibilities are vague, each side assumes the other is handling data, testing or training, and tasks fall between the two.

The remedy. Look for demonstrable experience with businesses like yours, ask for references you can speak to, and meet the people who will actually work on your project. Agree in writing who is responsible for each deliverable. Our guide to choosing an ERP integrator sets out the questions to ask.

11. Treating go-live as the finish line

The first weeks after go-live are when real volumes meet the system for the first time. Unexpected cases appear, users forget their training and small configuration gaps become visible. If the project team disbands the moment the system is live, the business is left to cope alone.

The remedy. Plan a period of enhanced support after go-live, with named contacts and fast responses. Schedule a review once the system has settled, to capture improvements. An ERP is not a one-off installation but a platform that evolves with the business.

12. Ignoring compliance and external connections

A UK business has obligations that the system must support: VAT records and digital reporting under Making Tax Digital, data protection under UK GDPR, and in some sectors specific traceability or audit requirements. Connections to banks, carriers, e-commerce platforms and tax services are also easy to overlook until late in the project.

The remedy. List every compliance requirement and every external system in the scoping phase, and test each connection explicitly. For the invoicing side, see our guide to ERP and e-invoicing.

Summary: warning signs and remedies

Does the choice of ERP affect the risk?

The product matters, but less than the fit. Odoo, Microsoft Dynamics 365 Business Central, Sage, Oracle NetSuite and SAP Business One differ in approach, target size and the way they are deployed and licensed. Each can serve a given business well, and each can disappoint if it is poorly matched to the requirements or badly implemented.

Two choices deserve particular attention. The first is how the system is hosted; the trade-offs are explained in our comparison of cloud and on-premise ERP. The second is how much of the standard product you will rely on, since a platform with a rich standard scope can reduce the need for bespoke development. If you are comparing specific products, our comparisons set them side by side without favouring any publisher.

How to give your project the best chance of success

If you remember only a few principles, make them these:

1. Define before you buy. Outcomes and requirements in writing, agreed by those who will use the system.
2. Keep it as standard as you sensibly can. Customise for advantage, not for habit.
3. Own your data. Start cleaning early and reconcile carefully.
4. Give the project real leadership. A sponsor with authority and a project lead with time.
5. Bring people with you. Communicate, train and listen.
6. Choose the integrator as carefully as the software. Experience in your sector is worth more than a polished pitch.
7. Plan beyond go-live. Support and review are part of the project.

Finding an integrator who has done this before

Many of the mistakes above come down to inexperience on one side or the other. A good integrator will challenge vague requirements, resist unnecessary customisation, insist on data discipline and be honest about timelines. That is precisely the kind of partner worth looking for.

Our service is free and neutral. You describe your project, and we put you in touch with a suitable ERP integrator for your sector, size and chosen platform; the integrator then carries out the project. You can see the steps on the page explaining how the introduction works, and if you are still at an early stage, our guide to ERP for small business may help you frame your needs first.

Software names mentioned are trademarks of their respective publishers and are referred to for information only. This site is independent and is not affiliated with any software publisher.