When an ERP launch is postponed, the explanation is often technical: a module was not finished, an integration failed a test, a report looked wrong. Dig one layer deeper and the cause is usually the same. The business data was incomplete, inconsistent or owned by nobody, and nobody discovered that until the week the cutover was supposed to happen.
Migration is not a final logistics task. It is a design constraint that should shape scope, timelines and acceptance criteria from the first week of the project. The mistakes below are the ones that repeatedly turn a planned launch into a sequence of “two more weeks”.
Treating migration as a final step
If migration starts after development ends, every data problem becomes a launch crisis. Mapping, cleansing and dry runs need calendar time of their own, and they need a named owner inside the business who can decide what to keep, merge or discard.
- Assign a business owner for each major data domain: customers, products, stock, open balances, open orders.
- Define which historical records must move and which can stay in archive or read-only storage.
- Schedule at least two full dry runs before the cutover weekend, not one rushed attempt.
Cleaning nothing until the import fails
Duplicate customers, missing product codes, inconsistent units of measure and open balances that do not reconcile will not become clearer under deadline pressure. Clean the source before you transform it. Transformation cannot invent truth that the source never held.
Mapping fields instead of meanings
A spreadsheet that says “old column A becomes new column B” is not a migration design. You need the business meaning: what a status value means, which currency applies, whether a zero balance is real, and which records are still operationally active.
Skipping reconciliation targets
Before cutover, agree the numbers that must match: stock quantities by warehouse, open receivables by customer, open payables by supplier, and the count of active items. If those targets are undefined, nobody can say whether the migration succeeded.
A practical migration sequence
- Inventory the source systems and the records that still matter operationally.
- Name owners and write acceptance numbers for each domain.
- Clean and deduplicate in the source, or in a staging area the business can review.
- Map meanings, not only columns, and document every transform rule.
- Run a dry import, reconcile against the agreed numbers, and fix root causes.
- Repeat until the reconciliation is boring, then lock the cutover checklist.
Teams that treat migration as product work rather than IT logistics usually launch closer to the date they promised. The software can be ready and still unusable if the records that drive daily work are not.