The seven most expensive data mapping errors in an ERP migration
In normal operations a wrong mapping costs hours. During an ERP cutover it costs days, sometimes a quarter. We see the same seven errors repeatedly, and each one is preventable.
1. The late mapping
The project plan said the mappings would be done by week six. They were not. The build started anyway, because the schedule said so. Every change to the mapping after week six now requires undoing something already built.
Fix: Treat the mapping as the prerequisite, not as parallel work. Build does not start until the mapping is signed off.
2. The unstable target
The new ERP's structure for accounts, cost centres, customer types is supposed to be defined at the start. Often it is not. Mappings correct on Tuesday are wrong on Friday because the target structure changed.
Fix: Freeze the target schema before mapping starts. Treat target changes as scope changes, not edits.
3. The missing inactive set
The new ERP needs current data and historical data. Historical data references codes no longer active in the source. Someone assumes inactive codes do not need mapping. The first month-end discovers that the prior-year comparatives reference codes that do not exist in the new system.
Fix: Map every code that has ever appeared in the source, active or not. Mark them inactive in the target if needed; do not skip them.
4. The bulk paste with no validation
Mappings during the project are usually built in Excel. Someone pastes a thousand rows from an export. A few have leading zeros that Excel strips. A few have whitespace that does not match the actual source. The migration runs, and the defect log fills with mismatches that all trace back to one paste.
Fix: Validate every paste at write time. If Excel cannot do it, do not build the mapping in Excel.
5. The silent default
The mapping defines what to do with known values. It does not define what to do with unknowns. At cutover, an unmapped value either rejects the row or applies a default. A wrong default applied to thousands of rows is the worst case, because the load did not fail and nobody notices until the report is reviewed.
Fix: Decide explicitly. Reject on unmapped is safer for most fields. If you must accept, default to an "unknown" bucket, never to a real value.
6. The parallel run divergence
During parallel run, mappings need to stay in sync with the source. New codes in the old system need mappings. The old system keeps moving, the mappings do not keep up, and by cutover the gaps have stacked up.
Fix: Make adding a mapping part of the source change process, not a separate batch. The person who adds a code is responsible for its mapping.
7. The post go-live ownership vacuum
The project team built the mappings. The project team disbands at go-live. New codes appear. Nobody owns the addition.
Fix: Name the steady-state owner of each mapping before go-live. Have them do at least one mapping themselves while the project team is still around.
Summary
| Error | Typical cost when it bites |
|---|---|
| Late mapping | Weeks of rework |
| Unstable target | Continuous low-grade rework |
| Missing inactive set | Restated prior-period reports |
| Bulk paste, no validation | Hundreds of unmapped rows post-cutover |
| Silent default | Wrong data in the new system, hard to reverse |
| Parallel-run divergence | Cutover finds the gap, late |
| Ownership vacuum | Continuous data quality decay |
One alone is recoverable. Three or four together turn an eighteen-month project into a thirty-month project.
All seven share a root cause. The mapping is treated as a one-time artefact instead of a living system. Spreadsheet, project-only ownership, no validation, no audit. The fix is the same shape every time: move the mappings into a system that enforces structure, records every change, has a named owner, and exposes the result programmatically. In gridmap, that system is a registry, and it works the same during migration and after, so the post go-live transition disappears.
The cost of getting these seven right is small: better discipline at the start, slightly more scaffolding around the mapping work. The cost of getting any one of them wrong, in a real migration, can be a quarter of slipped timeline plus an unknowable amount of operational damage. The math is rarely close.