After leading ERP transformations for a US insurance giant, a global investment bank, and multiple Berlin-based tech scale-ups, I've watched the same failure patterns play out with depressing regularity. The technology almost never fails. The product decisions made before a single line of code is written almost always do.
ERP migrations are uniquely brutal because they sit at the intersection of three competing worldviews: Finance wants accuracy and compliance. IT wants clean architecture and maintainability. The business wants speed and minimal disruption. A product manager who can't hold all three simultaneously and make trade-off calls that everyone can live with is going to have a very bad time.
Failure Pattern 1: Scope Defined by the Vendor, Not the Business
The first meeting after contract signature is usually dominated by the vendor's implementation methodology. It's polished, it's reassuring, and it's almost entirely disconnected from how your business actually operates. The vendor's scoping process is optimised for their delivery velocity, not your operational reality.
I learned this the hard way on an early engagement, where we inherited a scope document that assumed a clean, single-instance data model. The client had two business units running different ERPs, with 15 years of custom field mappings, workarounds, and shadow spreadsheets that finance absolutely depended on. None of this was in scope. All of it became a crisis.
The fix: before you touch the vendor's scope template, spend two weeks embedded with the finance operations team. Map every manual process, every spreadsheet, every workaround. These are your real requirements. The undocumented ones that will either be addressed in the migration or return as post-launch incidents.
Failure Pattern 2: No Product Owner for Data Migration
Data migration is always treated as a technical workstream. It should be treated as a product workstream with a dedicated product owner. The questions that kill migrations are product decisions, not technical ones: what do we do with orphaned records? How do we handle historical transactions that don't map cleanly to the new chart of accounts? What's the cutoff date and what happens to in-flight transactions?
At one banking client, we inherited a data migration workstream that had been running for six months before I joined. The technical team had built a technically competent ETL pipeline. But nobody had signed off on the business rules for 12 different data transformation scenarios. The pipeline was ready. The decisions weren't. We pushed the go-live by four months.
Failure Pattern 3: Governance That Exists on Paper
Every ERP programme has a steering committee. Most steering committees receive a status report, nod, and adjourn. Real governance means the committee is making actual decisions, about scope changes, risk acceptance, and resourcing, on a cadence that matches the programme's velocity.
The most effective governance structure I've used is a tiered decision model: the product team owns decisions that affect only their workstream, a cross-functional working group owns decisions that affect multiple teams, and the steering committee owns decisions that change scope, budget, or timeline. Document which tier owns which decision type before the programme starts, and you'll eliminate 80% of the escalation delays that kill ERP timelines.
What Good Looks Like
An SAP S/4HANA migration I led succeeded not because we had a perfect plan, but because we had a clear decision-making structure, a ruthlessly honest scope baseline, and a product team empowered to say no to scope creep, even when it came from the CFO. We shipped on time, within budget, and with zero P1 incidents in the first 30 days post-go-live. That's the benchmark.
ERP migration is a product challenge wearing a technology costume. Treat it that way, and you'll have a fighting chance.