What is a data migration?

A data migration moves data from a source system or platform to a destination one, a legacy database moving to the cloud, one warehouse to another, a CRM to its successor, without breaking what depends on that data: reports, integrations, processes that read it every day. It sounds like a mechanical copy operation, and the copy itself almost always is. The risk sits elsewhere: a migration touches schema, data quality, and downstream dependencies all at once, and it is the downstream dependencies that nobody has ever inventoried in full. That is why the risk in a migration is organizational before it is technical: the transfer tooling has been a solved problem for twenty years, while knowing who reads that data, under which conventions and inside which processes, is knowledge that lives in people's heads rather than in a document. Moving the data is the easy part, guaranteeing that nothing downstream notices the change is the real work.

The phases that decide the outcome

A well-run migration has five phases, and each one exists to catch a specific risk before it becomes irreversible.

Dependency inventory. Who reads this data: which reports, which automations, which external integrations, which spreadsheets somebody updates by hand every Monday. This is the phase that gets skipped almost every time, and it is the one that decides whether cutover is a non-event or a week of phone calls.

Schema mapping. Field by field, from source to destination. This is where you catch schema drift: a field that changes type, a customer code that was text with leading zeros in the source and becomes numeric in the destination, two teams using the same field with different meanings. The technical debt accumulated in the source system, undocumented schemas and verbal conventions, comes due in this phase.

Dry run on a staging environment. The whole migration executed against a copy, with downstream consumers pointed at the new environment. Its purpose is to find out what breaks while breaking is still reversible.

Explicit validation. Comparing counts, checksums, and samples between source and destination, rather than trusting a copy job that finished without errors. This is the phase that catches silent row loss, the kind of problem no log flags and that surfaces months later through a report that does not add up. It is also where a migration exposes data quality problems the legacy system had been hiding for years, simply because nobody had queried it with the new environment's rigor.

Cutover. The window where the two systems are out of sync and someone can write to the wrong one. Decide up front whether it will be dual-write, with both systems running in parallel for a period, or a hard switch: the second option is simpler and riskier, and the choice is a business call, not a technical one.

An enterprise example

A manufacturer moves its item master from an end-of-life ERP to the successor. The copy takes two hours. The project slips by four months because in the old system the item code is a text field where, over the years, three departments entered different conventions: the warehouse put the supplier code in it, production added a revision suffix, sales sometimes left it empty and used the description as the key. The new ERP validates the field and rejects a third of the rows. None of those problems originated during the migration: the migration merely made them visible.

Why it matters for your business

A migration quote estimated from data volume is almost always wrong, because the cost sits in the dependency inventory and the quality cleanup, not in the transfer. Before asking for a proposal it pays to know how many consumers the source system actually has: that is the question that moves the estimate by an order of magnitude, and whoever asks it first has usually watched a migration go wrong already. The same discipline applies to a legacy modernization project or a cloud repatriation: the destination changes, the risk does not.