Getting a data migration right: the mistakes to avoid

A data migration is a moment of truth: years of history, implicit rules and accumulated inconsistencies surface within weeks. Across CRM and ERP migrations, the same mistakes recur with remarkable regularity. Knowing them is halfway to avoiding them.

Mistake #1: treating migration as a purely technical topic

The temptation is to hand migration to the integration teams alone: extract, transform, load. But every transformation rule is a business decision in disguise. What to do with customers inactive for five years? With duplicates where both records are partially right? With statuses that no longer exist in the target system?

Without business teams in the loop, these decisions get made by default — and discovered in production.

Mistake #2: discovering data quality at the end of the project

The actual quality of source data is systematically overestimated. Rigorous profiling at framing time — completeness, formats, duplicates, referential consistency — avoids the tunnel effect where quality issues explode during acceptance testing, at the worst possible moment.

Cleansing is a workstream in itself: it must start early, with identified business owners, and be measured with indicators tracked in governance forums.

Mistake #3: one dry run (or none)

The dry run is not optional: it is the dress rehearsal that reveals real volumes, load times, rejects and forgotten edge cases. Serene migrations run several, with reject rates dropping and controls sharpening at each iteration. The final cutover should contain no surprises — everything has already been played out.

Mistake #4: acceptance testing without the users

Checking that volumes match is not enough. Real users must find their customers, their orders, their histories — and be able to run their daily processes on the migrated data. Structured business acceptance testing, with real scenarios and explicit acceptance criteria, is the best investment of the whole project.

Mistake #5: stopping on cutover day

The weeks after go-live are critical: residual cases surface, imperfect rules get corrected, and user trust in the new system is won or lost. Planning an instrumented stabilization period — flow monitoring, an anomaly-handling circuit, daily checkpoints — makes the difference between a cutover and a success.

The common thread: governance

All these practices share one assumption: someone steers the data itself — not just the project. Clear ownership of each data domain, documented rules, traceable arbitrations: governance is what turns a risky operation into a controlled process. And it remains after the migration, as a durable asset of the organization.