“We’ll just take the data over” is one of the most expensive sentences in an ERP migration. Between legacy and target system there is no export button, only a mapping: every source field needs a target field, a transformation rule or a documented decision to leave it behind. Why underestimated data migration sinks projects is covered in the five most common migration mistakes.
The mapping builds on the findings of discovery. Data mapping has been the core task of my integration work for years, from DATEV to Salesforce interfaces, documented in the case studies.
Field by field, with validation rules
The mapping document records source, target, transformation rule, special cases and owner for every field. In parallel, validation rules define what counts as correctly migrated: totals and balances, record counts, defined samples in critical data sets. Without those rules, “migration successful” remains an assertion.
Test runs against real data
Validation happens in test runs with real source data in a production-like environment, not on the drawing board. Every run produces findings that correct the mapping; the next run shows whether the correction holds. Key-user acceptance testing does not replace these system tests; both are needed. In an M&A integration, several complete test runs preceded a cut-over in a single weekend; at a pharma company (250 employees), data quality checks came before the on-schedule two-wave go-live that consolidated three legacy systems onto one SAP.
Acceptance criteria before go-live
Before go-live comes the acceptance list: which data must arrive complete, what deliberately stays out of scope, who signs off. It prevents the completeness debate from happening after go-live. And it is what makes a cut-over calculable.