This is Part 2 of a two-part series on ERP implementation success. In Part 1, we covered what buyers should look for before selecting an ERP implementation partner. In this article, we share 15 real-world implementation mistakes we've seen firsthand, the lessons they taught us, and the questions every buyer should ask to help prevent them.
15 real implementation and go-live failures. Hard lessons learned while working inside larger firms where executive oversight was lacking. Each one includes the buyer takeaway, along with the deeper misunderstanding that sits beneath them all. Correcting and avoiding these mistakes is the reason Dominate Solutions was founded.
ERP Project Scope, Pricing, and Accountability
This is the foundation. When scope and price are soft, everything downstream inherits the problem.
1. A sales team that faces no consequences for how the initiative actually turns out
When a salesperson can over-promise, under-scope, and discount their way to a signature with no accountability for whether the project succeeds, the same pattern repeats initiative after initiative; rinse and repeat. The customer inherits a project that was never deliverable as sold, and the implementation team inherits a commitment it had no part in making and no ability to keep. The disconnect between who sells and who delivers is the root problem: when the sale and the outcome are decoupled, integrity becomes optional. This is the incentive failure behind most of what follows in this theme.
What to demand: evidence that the people selling to you are connected to, and accountable for, the delivery. Ask whether your sales contact stays involved after signing, whether the delivery team had a say in the scope and timeline you were quoted, and whether the firm measures its sellers on customer outcomes, not just closed initiatives. A seller with no stake in the delivery has no reason to be straight with you.
2. A flimsy scope document that was never fully vetted
A scope written quickly, or signed before requirements were genuinely worked through with the customer over multiple rounds of discovery, guarantees disputes later, every gap becomes a "you said / we said" mid-project.
What to demand: a rigorously vetted scope built from real discovery, where every deliverable is named and agreed before you sign. If discovery felt thin, the scope is thin.
3. A price cut to close the initiative — with no cut to the work
When a sales team reduces the price to win without reducing the scope, the gap doesn't disappear; someone absorbs it, and it's usually quality, hours, or your timeline.
What to demand: any price reduction comes with an explicit, written scope reduction. A discount with nothing removed is a red flag, not a win; it's a promise the delivery team may not be funded to keep.
4. A critical third-party product that nobody vetted
A customer-requested ISV (a third-party add-on) became a critical part of the solution, and its references were never checked. When it underdelivered, it took the whole project's credibility with it.
What to own, together: if you bring a third-party product to the table, it earns the same reference-and-vetting scrutiny as the ERP itself. Your Partner should insist on it; so should you.
5. Not vetting the problems in the current system before signing
If the legacy system isn't reconciled, or the ledger and subledger don't tie, the data migration has nothing clean to tie out to. You can't migrate your way out of a problem you never diagnosed, and a balance that didn't reconcile in the old system won't reconcile in the new one.
What to demand: a Partner who treats data migration as a Day 1 topic and vets it during the sales process; examining the actual state of your data, surfacing where it's broken, and naming the risks and the mitigation plan before the contract is signed. The goal isn't to find that everything is clean; it's to find what isn't, so there are no surprises that can't be solved once the project is underway. A Partner who doesn't ask about the condition of your data is planning to discover it the hard way, on your time.
Implementation Methodology and Who Owns What
Most "customer mistakes" in this section are really the result of a Partner who never explained the rules of the road.
6. The methodology — and your responsibilities — were never explained
Buyers get blindsided by work they didn't know was theirs: training expectations, data migration, user testing and validation. None of it is unreasonable; all of it is a problem if it shows up as a surprise.
What to demand: a plain-language walkthrough of the implementation methodology before kickoff, with your responsibilities spelled out; what you own, when it's due, and what happens if it slips.
7. Test scripts written in a vacuum, around the old system
A customer wrote their own testing scripts without fully absorbing the training, and built them around how the old system worked rather than the new one. The tests passed against the wrong target, and the gaps surfaced at go-live.
What to own: treat training as mandatory, not a box to check, and build testing around the new system's workflows, with your Partner reviewing your scripts, not leaving you to write them alone.
8. Recreating every old customization "because that's how we've always done it"
Faithfully rebuilding the exact customizations from the legacy system ports the old problems straight into the new platform, and inflates cost and risk doing it.
What to own (the mindset): a new ERP is a chance to adopt better standard processes. Demand that your Partner challenge legacy customizations and show you the standard way first, rather than blindly rebuilding what you had.
ERP Implementation Project Team and Schedule Integrity
Who does the work, and against what schedule, decides whether the plan survives contact with reality.
9. Trainees staffed on a live implementation to "get experience"
Learning on your project, on your budget, on your timeline.
What to demand: a named, experienced delivery team. Ask plainly who is actually assigned to your implementation and what they've done before, the same continuity question you should be asking during the sale.
10. A go-live date set by an executive who didn't own the work
A date assigned arbitrarily by someone not accountable for delivering it, and with no grasp of the implementation's requirements or complexity, becomes a date the team is set up to miss, and a source of pressure that corrupts quality.
What to own (governance): the go-live date is set with the implementation team based on real complexity, not imposed on it from above. A date pulled from the air is a date you'll miss.
11. No accountability for day-to-day progress, cadence, and issue resolution
This is the keystone. When neither the project sponsor nor the project managers are held accountable for the daily rhythm; progress between milestones, a living issue log, and timely resolution, the project drifts. It doesn't fail at go-live; it fails quietly for months and reveals it at go-live.
What to demand and own, together: both sides name an accountable sponsor and PM, commit to a fixed cadence, standing status, a live issue log with owners and due dates, and a clear escalation path, and hold those roles responsible for momentum between milestones, not just at them.
12. A schedule that ignored predictable risk
Recurring, foreseeable events; hurricane season, floods, your own busy season, were never built into the project plan, so the first storm blew the timeline apart.
What to demand: a schedule that accounts for your region's and your business's realities, with contingency built in rather than assumed away.
ERP Partner Relationship and Conduct
Implementations are a two-way relationship, and the relationship is part of the deliverable.
13. Tolerating abuse of the implementation team
A customer executive berating the team with abusive language and blow-ups poisoned the working relationship and drove away the people doing the work.
What to expect from a good Partner — and hold yourself to: implementations succeed on healthy, two-way collaboration. A good Partner establishes engagement norms and escalation paths up front, so problems have a channel. Pressure is legitimate; abuse is not, and it derails the very people delivering your project. Notably, the cadence and issue log from Lesson 11 are what replace the blow-ups: when there's a visible mechanism to raise and resolve problems, frustration has somewhere to go besides the team.
14. Not knowing who the naysayers are before the work begins
Every implementation has people who will resist it, quietly or loudly. Discovering them mid-project, after they've had months to undermine momentum, is far costlier than naming them at the start.
What to demand and own, together: identify the likely resisters before kickoff and agree with the project sponsor on a plan for each; bring them in and give them a stake, or, where necessary, move them off the project. This isn't politics for its own sake; adoption is where ERP value is won or lost, and a determined naysayer with no plan around them can sink a technically perfect implementation. The sponsor owning this conversation up front is one of the clearest signs the project has real executive backing.
15. Waiting for a meeting to raise an issue, risk, or anything that affects time or money
When problems are saved for the next scheduled status call, they've already cost time, and the delay itself signals that the project has no culture of candor. Worse, when communication isn't open, information becomes leverage: people withhold it, or weaponize it, to protect themselves or sabotage the effort.
What to demand and own, together: open communication protocols at every level, established at the onset and modeled top-down. Issues, risks, and anything touching schedule or budget get raised the moment they're known, through a known channel, not banked for a meeting. This is a leadership trait, not a tool: when both sponsors set the expectation that surfacing a problem early is rewarded rather than punished, the team develops trust, mutual respect, and a genuine sense of being one team; and the information that would otherwise be hidden or weaponized stays on the table where it can be solved. The real-time channel and the issue log from Lesson 11 are the same mechanism: cadence gives problems a place to go; open protocols make sure they get there early.
The Mistake Behind All the Mistakes
The deepest failure isn't on the list above — it's beneath all of it. Buyers and firms that treat an ERP implementation as a software installation miss what it actually is: a change in nearly every aspect of how work gets done. New processes, new roles, new daily habits, and the change lands differently on different people. The office experiences it as new screens and workflows; the field experiences it as new expectations, new devices, and a level of accountability they may never have had before. A back-office controller and a field foreman are living through two different projects under one name.
Several of the failures above: the resisters who were never identified, the communication saved for meetings, the training treated as a box to check, are really this one mistake showing up in pieces.
What to demand and own, together: a project run as change management, not just configuration. That means current-state-to-future-state process change made explicit; the impact on office and field assessed separately, because it is not the same; and deliberate, continuous communication to every stakeholder group throughout the project; not an announcement at the start and training at the end. People support what they understand and helped shape; they resist what is done to them. The technical work is the easy half. The human change is the half that decides whether go-live succeeds, and it is the half a software-only mindset never even staffs.
Six quick questions about how you bill, track cost and run your crews.