The Enterprise ERP Migration Playbook

Why most ERP migrations fail

The majority of ERP migration projects that run over time and over budget have one thing in common: they treated the migration as a technology project. It is not. It is an operations transformation that happens to involve software. The data is the last concern; the first concern is how your business actually runs — and how the new system needs to model that.

The three most common failure modes we see are: (1) underestimating data complexity — businesses rarely know how messy their master data is until they try to move it; (2) training too late — users see the new system for the first time a week before go-live; (3) scope creep without timeline adjustment — new requirements added without removing others or extending the timeline.

Avoid all three by treating this playbook as a contract with yourself, not a to-do list.

Phase 1: Discovery and data audit (Weeks 1–2)

Before writing a single configuration, you need to understand what you are migrating from. A data audit covers: number of customers, vendors, items, and open transactions; the state of your chart of accounts; whether your legacy system has API export capability or requires manual data extraction; and which fields in the legacy system map to which fields in the new platform.

For most mid-market companies, the data audit reveals between 15–40% of master data that needs cleaning before migration — duplicate vendors, inconsistent item codes, accounts that were opened but never used, customers with multiple records. Cleaning this now saves it from compounding inside the new system.

Document every data source: the ERP, any side spreadsheets, any third-party integrations that push data in. Everything that enters the new system needs a defined migration path or a documented decision to exclude it.

Phase 2: Configuration and build (Weeks 3–8)

Configuration is not the same as development. A well-designed enterprise platform should require minimal custom code — most business logic can be expressed through configuration: workflow rules, approval chains, account mappings, tax rules, report definitions, and access controls.

Work module by module in dependency order: Finance first (Chart of Accounts, fiscal year, tax configuration), then Procurement and Inventory (which depend on Finance), then Manufacturing or HR depending on your operations, then CRM and customer-facing modules last.

Each module should be demonstrated to the business owner in your actual configuration — not a generic sandbox — before the team moves to the next module. This is the quality gate that prevents discovering configuration errors at UAT.

Phase 3: Data migration execution

Data migration has three runs: a trial run (identifies failures and gaps), a validation run (confirms clean data migrates correctly), and the cutover run (the real thing, done during the cutover window).

For each run, define acceptance criteria before you start: what percentage of records must migrate cleanly, which fields are mandatory versus acceptable to leave blank, and who signs off on data quality before you proceed.

Migrate in this order: master data first (customers, vendors, items, accounts), then opening balances, then open transactions, then historical data if required. Each layer depends on the one above it being clean.

For the cutover run, define a go/no-go decision point. If the cutover run starts and hits a failure rate above your threshold, you roll back to the legacy system and reschedule. This decision point must be defined before you start — not negotiated under pressure during the window.

Phase 4: User acceptance testing and training (Weeks 8–10)

UAT is not about testing software. The software has been tested by the implementation team. UAT is about your users confirming that the configured system matches how your business actually works — and surfacing the gaps before go-live.

Give each user group a defined set of test scenarios based on their actual job functions. A finance user tests: posting a vendor invoice, running a bank reconciliation, generating a month-end report. An inventory user tests: receiving a purchase order, processing a stock transfer, generating a stock ledger.

Training happens during UAT, not before it. The sequence is: show the user how the task works in the new system, have them do it themselves, have them do it again in a scenario they define. Three repetitions per workflow. Self-sufficiency is the goal, not familiarity.

Phase 5: Go-live and hypercare (Weeks 10–14)

Cutover should happen over a weekend or a holiday period when transaction volume is low. Define the start time, the end time, and what constitutes a successful cutover before you begin.

On day one of live production, the implementation team should be on-site or on-call. Responses to issues should be in minutes, not hours. The first 30 days of production are hypercare: issues are prioritised above everything else, and the team checks in daily.

Post-go-live, establish a rhythm: weekly check-in for the first month, fortnightly for months 2–3, monthly from month 4. This is also when you start measuring the outcomes you defined at the beginning — month-end close time, transaction processing time, reporting turnaround, and whatever other metrics justified the investment.

Measuring ROI at 30, 90, and 180 days

At 30 days, you are measuring stability: how many support tickets per day, how many users actively using the system, and whether the key workflows are running as configured. At 90 days, you are measuring efficiency gains: has month-end close shortened, has procurement cycle time improved, are manual reconciliation hours reduced. At 180 days, you are measuring the business case: what are the actual savings versus the projected savings, and what additional capability has been enabled by having clean, centralised data?

Document these outcomes. They justify the investment to the board, they give the implementation team feedback on what worked, and they set the baseline for the next phase of the platform rollout.