An ERP implementation is the project of configuring and deploying an ERP system so it actually runs your business, and it is the hard, expensive and risky part, not buying the licence. Plenty of these projects fail or blow out, and they tend to do so for the same handful of reasons: scope that creeps, data that was never cleaned, customisation that turns into a millstone, and a business that underestimated how much of its own time the thing would eat.
The platform you choose matters, but the rollout is where the money goes and where projects live or die. Let us walk through the phases, the failure modes that recur, and the practices that keep a project honest. For the grounding first, our explainer on what ERP actually is covers the concept before the project starts.
The licence is not the project
People anchor to the subscription price because it is the number in the sales deck, but it is usually the smaller part of the story. Buying the software is a procurement decision you make once; implementing it is a project that runs for months, sometimes more than a year, and touches almost everyone who uses the system. The product can be excellent and the project can still fail, because the difficulty was never in the licence. It was in moving a real business, quirks and half-documented processes and all, onto a new system without breaking the day job.
The phases of an ERP implementation
Most implementations move through a recognisable sequence. Approaches vary, and some partners name or compress these stages differently, but the shape is fairly consistent.
- Discovery and process mapping. Understand how the business actually works before choosing or configuring anything.
- Selection. Choose the platform and the partner, both decisions, not just the software.
- Design and configuration. Set the system up to match the processes you mapped, configuring rather than rebuilding where you sensibly can.
- Data migration. Clean and move your data, routinely the most underestimated step in the project.
- Integration. Connect the ERP to the other systems it has to talk to, such as ecommerce, payroll, CRM or a warehouse.
- Testing. Prove it works with real scenarios and real data, not a tidy demo.
- Training and change management. Get your people ready and willing to use it.
- Go-live. Switch over, all at once or in stages.
- Post go-live support and optimisation. Stabilise, fix what surfaces, and improve from there.
The early phases are tempting to rush, and the ones that punish you for it. Discovery and data migration do more to decide the outcome than the go-live everyone fixates on.
Why so many projects fail
ERP failures are rarely mysterious. They trace back to the same predictable causes, most of which have nothing to do with the software being wrong.
Scope creep
The project starts as finance and inventory, then someone adds manufacturing, then a bespoke report, then a fourth integration. Each addition sounds reasonable alone. Together they push out the timeline and overload the team. A project without a firm boundary tends to expand until it falls over.
Over-customisation
Heavy bespoke modification feels like getting exactly what you want, until the next platform upgrade arrives and every customisation has to be retested and reworked. Over-customised systems are expensive to maintain and slowly trap you on an old version. Configure where you can; customise only where the business genuinely demands it.
Dirty or poorly migrated data
You can configure the system perfectly and still sink it with bad data. Duplicate customers, half-finished records, inventory counts that were never right: migrate that as-is and the new system inherits every old problem, plus the loss of trust when the numbers do not add up.
Weak change management and no sponsor
If the staff who use the system daily were not brought along, they quietly route around it and the promised single source of truth never arrives. And because implementations cut across departments, they need a senior sponsor to own them, or the project stalls the moment it competes with day-to-day work.
Underestimating the internal time
The quiet one. Your own people have to make decisions, test, clean data and learn the system, all on top of their day jobs. Budget nothing for that and the project slips or gets done badly.
ERP projects rarely fail because the product was wrong. They fail because the scope crept, the data was dirty, or nobody owned the change.
What good looks like
The practices that keep a project on the rails are mostly about discipline early, when it is least satisfying and most valuable.
Map processes, then agree a clear scope
Understand how the business actually runs before you shop, because the mapping tells you what you genuinely need. Then write down what is in and what is out, and hold the line. A fixed-price discovery phase helps, because it forces the hard thinking up front and gives you a defined scope to price the work against, not an open-ended bill that grows with every good idea.
Phase the rollout where you can
Going big-bang, switching everything on at once, concentrates all the risk into a single moment. A phased rollout, finance first and stable before inventory, then payroll or manufacturing, is slower on paper and, where it is possible, far less likely to end in a crisis.
Clean your data and train your people
Start the data work long before go-live, not the week of it. Cleaning takes longer than anyone expects, and it is the difference between a system people trust on day one and one they quietly abandon. Treat training the same way, as a workstream not a memo: the systems that stick are the ones whose users were told why the change was happening. If you are unsure you even need ERP yet, the signs you have outgrown Xero is a useful gut-check first.
Choose the partner with as much care as the product
ERP is almost always delivered by an implementation partner who configures and rolls it out, and the partner matters as much as the platform. A good product implemented badly fails, while a middling product implemented well can quietly do the job for a decade. Working with an experienced implementation partner with a real track record in businesses like yours protects the outcome more than the badge on the software. Ask how many comparable projects they have delivered, who will actually run yours, and what their plan is for data migration and training.
This article is general information, not procurement advice. The right approach depends on your specific business, its processes and its budget, and approaches vary between partners and platforms. Confirm current scope and capabilities with vendors and an independent partner before committing.
The bottom line
An ERP implementation is a business change project that happens to involve software, not a software purchase that happens to need a project. The phases are predictable, and so are the ways they go wrong: scope creep, over-customisation, dirty data, weak adoption, no sponsor, and a chronic underestimate of the internal time required. None of those failures is a surprise, which means each is avoidable. Map your processes first, fix the scope, clean your data early, phase the rollout where you can, take training seriously, and choose your partner with as much care as your platform. Get those right and ERP becomes the backbone you stop thinking about. Get them wrong and the logo on the contract will not save you.