Most ERP migrations fail at the planning stage, not the technical one.

The checklist

  1. Data cleanup before migration, not during. Dirty data imported into a new system is still dirty data, just wearing a new interface. Clean it in the old system first, where you still understand its quirks and where errors are often easier to spot against familiar formatting.
  2. A named stakeholder who signs off on scope, not a committee that revisits decisions mid-project every time someone new joins a meeting. One accountable person, full stop, who can say yes and have it actually stick.
  3. An agreed cutover date, locked early in the project, with the old system frozen a few days before it so nothing new gets created that then has to be migrated separately on top of the planned dataset.
  4. A real training plan, scheduled against actual go-live and given enough time, not squeezed into the final week as an afterthought once everything else is "done" and attention has already moved on.
  5. A rollback plan, even if you never end up needing it, because not having one turns a minor hiccup during go-live into a genuine crisis with no agreed way back to a working state.

Why each one matters

Skipping data cleanup means inheriting every existing error, duplicate customer records, mismatched product codes, with a new system wrapped around it, which is often worse than fixing it in the old system would have been, since the new system now has to be reconfigured once the errors are finally found. Skipping a named stakeholder means decisions get re-litigated every time someone new weighs in, stalling progress for weeks at a time. Skipping a locked cutover date means the project drifts without a forcing function pushing it toward completion. Skipping real training means a system nobody actually knows how to use correctly at go-live, which looks like a software failure but is really a planning one that shows up as low adoption for months afterward.

The single biggest point of failure

It's rarely technical. It's an unclear decision-maker, someone who can say yes to a scope question and make that decision stick without reopening the conversation every two weeks as new stakeholders raise old objections again, often the same objections that were already settled earlier in the project.

Quick answers

What's the most commonly skipped item on this list? The rollback plan. Teams assume go-live will work, and most of the time it does, but the migrations that go genuinely badly are consistently the ones with no agreed fallback when something didn't go as planned.

How far in advance should the cutover date be locked? Ideally at the start of the configuration phase, once discovery is complete, since locking it early gives training and data migration a fixed target to plan backward from rather than a moving one that keeps slipping.