An ERP implementation is probably the most important IT project your business will ever undertake. It's expensive — not just financially, but in time, effort, process change, and the sheer weight of expectation sitting on top of it. So why does the industry still talk about failure rates as high as 70%? Why does something so significant go wrong so often?
Having been through go-lives, here are the five reasons I see come up again and again and what to do about each one.
1. The Consultant Doesn't Understand Your Business
This is the big one, and it's preventable. An ERP is not a one-size-fits-all product. Yes, there are editions suited to manufacturers, distributors, and professional services firms, but the real configuration work — the stuff that makes the system actually reflect how your business operates — requires a consultant who genuinely understands what you do, how you do it, and why.
The warning sign is a consultant who talks about features rather than outcomes. If they're listing off capabilities without connecting them to your actual processes — "it's got multi-level BOMs," great, but what does that mean for the way you handle outside processing right now? — they're not there yet. Push them. Ask them to explain the outcome, not the function.
The clearest sign that a consultant truly understands your business is when they can produce a workflow diagram — a visual map of your processes, department to department, showing exactly how the ERP layers on top. If they can do that with confidence and accuracy, you're in good hands. If they can't, that's a red flag you shouldn't ignore.
Don't just take "that's easy" for an answer. If it's that easy, ask them to show you in the system. And if something gets fixed or configured behind the scenes without explanation, ask why. You don't need to understand how to code it, but you do need to understand the rationale. That understanding is what protects you later.
2. The Customer Doesn't Know What They Don't Know
This one is uncomfortable to say, but it needs to be said: a significant number of go-live failures have a customer-side contribution. Even the best consultant can only work with what they're given.
Common failure modes here include putting the wrong person in the project manager role — someone too new to the business to understand the data, the workflows, or the edge cases that actually matter. Or having the original champion who drove the ERP investment hand it off to someone else and disengage entirely, leaving a gap between the vision and the execution.
The PM on your ERP project needs to be someone who knows your business deeply, is not afraid to push back when something doesn't look right, and will take the time to properly understand what's being built. A weak PM who accepts everything at face value and never escalates concerns is one of the most reliable routes to a painful go-live.
There's also a broader mindset issue. Teams coming from spreadsheets and QuickBooks often underestimate just how different a fully integrated ERP is. In a spreadsheet, you can overtype a number and move on. In an ERP, the system enforces discipline — if an item isn't set up correctly, if inventory isn't in the right location, if an order is missing a required field, it won't let you proceed. That's the point. But if users arrive at go-live assuming the system will just handle things, without understanding how or why, you'll have chaos.
The mitigation is scenario testing — real, messy, true-to-life scenarios that reflect what actually happens in your business on an average day. Not a clean fictional example, but a real customer order from six months ago, with partial stock, mixed lot numbers, a tight deadline, and purchasing involved. Put that in front of the team and watch what happens. You'll find training gaps, configuration issues, and wrong assumptions well before they become go-live problems.
3. Integrations Weren't Tested Thoroughly Enough
The base ERP gets most of the attention during an implementation. The integrations often don't — and that's where a lot of go-lives fall apart.
Whether it's a Shopify connector, an EDI integration, a shipping platform, or a payment processing bolt-on, integrations need to be tested with the same rigour as the core system. That means real data, real volumes, and real edge cases. Not one test order from one customer with one item. Think about what happens when you process a hundred orders. What happens when a customer cancels a line that's already been partially fulfilled? What happens when a SKU doesn't sync correctly, or a parent-child customer relationship doesn't map over the way you expected?
If your integration is the main channel through which orders enter the system, and it fails at go-live, it doesn't matter how well everything else works. You can't ship. You can't invoice. The whole thing grinds to a halt.
Test to breaking point. Stress test with volume. Build a proper test plan for your integrations the same way you'd build one for your pilot. The devil, as always, is in the detail.
4. The Mock Cutover Wasn't Done Properly
A mock cutover is a rehearsal for go-live weekend. You practice the actual data migration, run through the exact steps in the right order, and time each one. It sounds obvious. A surprising number of projects skip it or treat it as optional.
The value isn't just in spotting problems before the real thing — though it will do that. It's in knowing how long each step actually takes. Import 230,000 SKUs in a test environment and time it. Turn on a Shopify sync and watch how long it takes to pull across customers and orders. If that process takes eight hours and you didn't know, your cutover plan falls apart on a Friday night when you least want it to.
A good cutover plan doesn't just list the steps — it has estimated times against each one, owners for each task, and clear decision points. The team going into go-live weekend should have no surprises. Every task, including the tedious ones, should be accounted for. If there's manual work involved — say, linking a thousand purchase order lines to sales order lines one by one because the system can't do it automatically — that needs to be in the plan, with a realistic time estimate and the right people allocated to it.
When people know what's coming, even the unglamorous parts, they can commit to it. When they're surprised by it at 10pm on a Saturday, they can't.
5. Go-Live Support Is Underestimated — Especially That First Week
Get past cutover weekend, and the temptation is to exhale. Don't. The first week of go-live is where a lot of the hard work either sticks or unravels.
End users, particularly those who weren't embedded in the project team, are performing for the first time with real data and real stakes. People get stage fright. They forget things they tested confidently a week ago. They process records they shouldn't, pick from the wrong location, or post to the wrong period. These are fixable problems — but only if someone catches them quickly. Left unaddressed, small issues compound into bigger ones, and confidence in the system drops fast.
Have your consultant visible and available for at least the first few days. A floor walk where they're simply present and approachable does more for adoption than any amount of post-go-live documentation. Set up a clear escalation chain — end user to workstream owner, workstream owner to project team, project team to consultant — so nothing sits unresolved because nobody knew who to ask.
Run a daily team check-in during that first week. Bring the core team together at the end of each day to log what came up, what's outstanding, and what needs to be looked at before tomorrow morning. Long days for the core team are inevitable — but walking in each morning with a clear, structured list is far better than walking into accumulated, untracked chaos.
And don't overload phase one. The first go-live should be about core processes working reliably. Not automations, not business events firing everywhere, not every feature the system can do. People need to learn how to use it first. Automations can come later, once the foundation is solid.
The best possible outcome at the end of go-live week is an anticlimactic one: people doing their jobs, inventory moving, orders going in, nothing burning. That's not a disappointment — that's the goal.
ERP go-lives fail for predictable reasons, and most of them are preventable. A consultant who genuinely understands the business. A customer team that takes ownership and prepares properly. Integrations tested at real-world volume. A mock cutover that leaves no surprises on the day. And go-live support that doesn't disappear the moment the switch is flipped.
None of this is complicated in theory. All of it requires discipline and commitment in practice. Get these five things right, and you give your project the best possible chance of success.
