The Real Reason ERP Migrations Fail: It’s Never the Software

Table of Contents

• The Post-Mortem That Always Blames the Software
• What Actually Breaks, in Order of Frequency
• Governance Failure: No One Owns the Backlog
• Scope Failure: The Business Case Nobody Revisits
• Change Failure: Adoption Planned as an Afterthought
• Decision Failure: Escalations That Never Resolve
• Where the Software Actually Does Matter
• Reframing the Program Before It Starts
• Checklist: Is Your Program Set Up to Fail?
• FAQ
• Regard d’Expert
• Références

The Post-Mortem That Always Blames the Software

Almost every troubled ERP migration produces the same post-mortem narrative: the software wasn’t right for us, the vendor overpromised, the platform couldn’t handle our complexity. It’s a comfortable story because it locates the failure outside the organization. It is also, in the large majority of cases examined closely, wrong — or at least radically incomplete. The software is rarely where these programs actually break.

What Actually Breaks, in Order of Frequency

Across troubled ERP and CRM programs, four failure modes recur far more often than genuine platform limitations: unclear backlog ownership and governance, a business case nobody revisits once the program is underway, change management treated as a pre-launch formality rather than a design principle, and escalation paths that exist on paper but never actually resolve conflicts in time. These four, not software capability, are where the real damage accumulates.

Governance Failure: No One Owns the Backlog

A migration without a single, empowered owner for scope and prioritization decisions doesn’t fail loudly — it fails slowly, through a thousand small unresolved trade-offs. Every business stakeholder pushes their own priority, nobody has the standing to say no, and the program’s original scope quietly expands until the timeline and budget it was built around no longer apply. By the time this becomes visible, it looks like a software problem: « the system can’t do what we need. » It rarely is one.

Scope Failure: The Business Case Nobody Revisits

The original business case — the value the migration was meant to deliver — is written once, approved once, and then almost never revisited as the program evolves. Scope drifts, timelines slip, and costs grow, but the yardstick against which « success » gets measured stays frozen at kickoff. Programs that build in a quarterly revisit of the original business case catch drift while it’s still correctable. Programs that don’t discover the gap only at go-live, when it’s far more expensive to address.

Change Failure: Adoption Planned as an Afterthought

Change management scheduled as the final pre-launch phase, rather than a design input from day one, consistently produces the same pattern: a technically sound system that a meaningful share of users quietly route around within months of go-live. This isn’t a training problem alone — it’s a sequencing problem. Users consulted during specification become advocates. Users informed only at pre-launch training become, at best, passive bystanders.

Change management designed as a workshop input, not a launch-week task.

Decision Failure: Escalations That Never Resolve

Most programs have an escalation process on paper. Far fewer have one that actually produces timely decisions. When conflicts between business units, or between business requirements and technical constraints, sit unresolved for weeks because no one has the authority or willingness to make the call, the program absorbs that delay silently — it will surface later — until it surfaces months later as a missed milestone attributed, again, to « the software. »

A tested escalation path resolves conflicts before they compound into delay.

Where the Software Actually Does Matter

None of this means platform choice is irrelevant. Genuine capability gaps exist, integration complexity varies meaningfully between platforms, and some organizational requirements genuinely exceed what a given system supports well. The point is narrower and more uncomfortable: in troubled programs, these genuine technical limitations are usually a smaller share of the failure than the governance, scope, change, and decision failures layered on top of them — and blaming the software lets the other four go unexamined.

Reframing the Program Before It Starts

Programs that avoid this pattern tend to share a specific discipline: a single named owner for backlog and scope decisions from day one, a quarterly (not annual, not never) revisit of the original business case against current reality, change management resourced and sequenced as a design input rather than a launch-week task, and an escalation path tested early on a real, minor conflict — not discovered to be theoretical only when a major one arrives.

Checklist: Is Your Program Set Up to Fail?

• Is there a single, empowered owner for backlog and scope decisions, or does prioritization happen by whoever pushes hardest?
• Has the original business case been revisited in the last quarter, or is it frozen at kickoff?
• Is change management resourced from the specification phase, or scheduled as a pre-launch task?
• Has the escalation process actually been tested on a real conflict, or does it only exist on paper?

FAQ

Doesn’t platform choice matter at all, then?
It matters, but it is consistently a smaller factor in troubled programs than governance and change management — treating it as the primary risk misdirects attention from where problems actually originate.

How do we know if our escalation process actually works?
Test it deliberately on a real, low-stakes conflict early in the program — if it doesn’t produce a timely decision then, it won’t when the stakes are higher.

Who should own the backlog if not the steering committee collectively?
A single named Product Owner with genuine authority to prioritize and say no — collective ownership by a committee is a common substitute that rarely functions as well in practice.

Is it too late to fix governance once a program is already underway?
No — reasserting clear ownership and revisiting the business case mid-program is disruptive but far cheaper than discovering the same gaps at go-live.

Regard d’Expert

Across ERP and CRM programs I’ve led, the software has almost never been the reason a program struggled. The reason has consistently been one of the four failure modes above, usually more than one at once, compounding quietly until they surface as a « the platform can’t do this » conversation months later. Fixing the platform conversation doesn’t fix the actual problem — fixing governance, scope discipline, change sequencing, and decision-making does. This is exactly the kind of upfront diagnostic our Diagnoz® platform is designed to surface before a migration program even begins.

I’m currently available to support ERP or CRM program governance and delivery, in France or internationally.

👉 Contact Notoriti to have an honest conversation about what’s actually at risk in your program.

Références

• Direct professional experience — multi-country ERP and CRM transformation program governance
• Standish Group, CHAOS Report (longitudinal research on IT project success/failure factors)