Direct answer first: ERP migrations fail for four predictable reasons — under-estimated data work, unclear ownership, adoption treated as an afterthought, and the business kept running on the old system while the new one was being built — and each one is preventable with a named countermeasure: the data plan, the project owner, the adoption plan, and the parallel-run rule. This guide walks the migration map in order, the data plan in plain terms, and the mistakes nobody makes twice.
Why migrations fail
Ask around any business community and you will hear the same war story: the ERP project that ran a year late, cost twice the budget, and ended with the team using spreadsheets in parallel anyway. The story repeats because the failures are not technical — the software works. The failures are four, and naming them is the first step to avoiding them:
- The data was the project. The migration plan had two weeks for data, and the data was a swamp: duplicate customers, uncoded inventory, vendors in three formats, and a decade of history that "we should bring over" until someone asked what it was for. Data work is not a step in the migration; it is usually half of it — and the plan that budgets it at 10% is the plan that blows up.
- The project had no owner. The implementation was steered by the vendor ("we have done this before"), with the business's side represented by whoever had time. The vendor has done the software; only the business can decide the process — and a project without a business owner with authority is a project the vendor runs to its own schedule.
- Adoption was an afterthought. The system went live, and nobody had been trained, or the training was a manual, or the team kept using the old tools "just for now". A system that is not adopted is not a migration — it is a licence purchase.
- The business never stopped running. The migration happened in a corner of the business while the real work continued on the old system — and the new system was populated from a snapshot, then diverged, and the go-live was a reconciliation nobody had planned.
Each failure has a named countermeasure, and the rest of this article is those countermeasures in order.
The migration map
The migration is a sequence with gates — each phase finished and approved before the next starts. The shape, in order:
- Process first. The process is documented as it will run in the new system — before the system is configured. This is the phase where the business decides what the software will amplify, and it is the cheapest place to change your mind.
- Data second. The data plan (next section) — extraction, cleanup, mapping, verification — run against the real data, with the rules written down.
- Build and configure. The system is configured to the documented process — not the other way round. Configuration follows process; the vendors who configure first and ask questions later are how businesses inherit processes they never chose.
- Test on real data. The new system is run against the cleaned data with the team doing real transactions — the dry run that finds the gaps while they are still schedule items.
- Parallel run. Both systems run together for a defined period, reconciled at each cutover point — the parallel run is the safety net that makes go-live a decision rather than a gamble.
- Cut over, and close the door. The old system is retired on a date with a rule: no more entries in the old system after cutover, ever. The open door is how "we are still using the old one for a few things" becomes the permanent two-system state.
The data plan, in plain terms
The data plan is where migrations live and die, and it is simpler than the consultants make it sound. Four questions, answered in order:
- What comes over? The rule of thumb that saves years: bring over what the business needs to operate and report from day one — open transactions, balances, master data, contracts in force. The historical depth (five years of completed orders nobody will re-open) is a candidate for archive, not migration. The question "who will actually use this after go-live?" decides every line.
- What is the cleanup? Each master data family is deduplicated and standardised: one customer per record, one code per product, one format for vendors. The cleanup happens in the old system or in a spreadsheet before mapping — never in the new system after go-live, where every correction is a transaction with an audit trail.
- What are the mappings? Every field in the old data mapped to its destination in the new system, written down — the old ledger account to the new chart, the old product code to the new catalogue. The written mapping is the document that makes the migration reviewable and the next migration cheaper.
- How do we know it worked? The verification: balances in the new system tie to the old, counts match, and a sample of records is walked end to end. The verification rule is the same one this site keeps using: any number in the new system must trace to its source in one step.
Migrate what you operate from, archive what you only remember, clean before you map, and verify by tracing — and the data plan stops being the project's risk and becomes its evidence.
Who owns the project
The project needs two owners, and the difference between them is the difference between a migration and a purchase:
- The business owner — a person inside the business with authority to decide process questions (how an order flows, who approves what, what the data standards are) across the functions the system connects. The business owner owns the decisions; the vendor implements them. Without this owner, the process decisions get made by default — usually by whoever the vendor asked last.
- The project manager — the person who runs the schedule, the gates, and the meetings. This can be internal or external; what it cannot be is nobody. The common pattern — "we will manage it ourselves, the vendor will do the work" — is how the schedule slips while everyone assumes someone else is tracking it.
The test of ownership, in one question: if a process decision had to be made on a Friday afternoon, whose phone rings? If the answer is "the vendor's", the ownership is inverted.
The adoption plan nobody skips twice
Teams that have lived through one failed adoption never skip this phase again, and the lessons are consistent:
- Train on the real process. Training that walks the team through the actual transactions they will run — not a manual, not a vendor's showcase of features. The training is the process documentation, taught by doing.
- Name the champions. One person per function who learns the system deeply, answers the daily questions, and reports the friction — the champion network is the difference between adoption and abandonment, because the daily questions are answered at the desk, not in the training room.
- Retire the old tools on the date. The parallel run has a defined end, and the old system is closed with a published date and a rule: no entries after cutover, and access removed shortly after. The teams that "keep the old one for reference" are the teams running two systems a year later.
- Plan the friction month. The first month after go-live is slower, not faster — the team is learning, the exceptions are new, and the reports need adjusting. Scheduling that month honestly (extra cover, fewer other projects) is what separates the adoptions that dip and recover from the ones that dip and never come back.
The failure table
| Failure | Countermeasure | Where it lives in the plan |
|---|---|---|
| Data was the project | The four-question data plan, run before configuration | Phase two — with real time budgeted |
| No business owner | Named owner with authority over process decisions | Phase one — appointed before the project starts |
| Adoption afterthought | Process training, champions, old-tool retirement, friction month | Phases five and six — scheduled, not hoped for |
| Business never stopped | Parallel run with a defined end, and the door closed | Phase five — with the cutover date published |
The table is the whole article compressed: every failure has a named countermeasure and a named home in the plan. A migration that names all four is a project; one that does not is a gamble with a licence.
Where the expertise sits
Migrations are bought and sold as software projects, and the expertise that matters is not the software — it is the sequence: process first, data second, business ownership, adoption with a friction plan. A partner who has run the sequence before brings the value; the software is the last mile. If you are planning a migration, the honest first step is the process documentation and the data questions — both are free, both are yours, and both determine 80% of the outcome before a single licence is signed. Our ERP for growing businesses guide covers the decision that leads here, and the ERP implementation page shows the sequence we run.
The bottom line
ERP migrations fail in four predictable places — data, ownership, adoption, and the never-stopped business — and each has a named countermeasure. Run the map in order, budget the data plan honestly, appoint the business owner, train on the real process, parallel-run with a published cutover, and close the door. The migration is not a software project; it is a process project wearing software — and the businesses that treat it as the former are the ones that tell the war story.
