What It Actually Means
The first is a schema migration: a small, routine, versioned change to the structure of a database that ships alongside a code change. Adding a column, adding an index. These happen constantly on any active system and are unremarkable.
The second is a data migration: moving the contents of one system into another, usually once, usually as part of a replacement. This is not routine. It is the highest-risk step in most replacement projects and it is where budgets are most often lost.
When someone says migration in a project conversation, establish which one they mean before anything else.
Why It Goes Wrong
Data that has accumulated over years is never as clean as anyone expects. That is not a criticism of the business, it is simply what happens to records maintained by many people over a long period.
Duplicates that were tolerable in a system with loose rules break a system with strict ones. Fields used for something other than their label. Dates in three formats. Notes containing information that was never given a field of its own. Records referring to other records that were deleted years ago.
None of this is visible from the outside, which is why migration estimates made without looking at the actual data are guesses. The single most reliable predictor of a difficult migration is that nobody has yet run a trial import.
What A Safe Migration Looks Like
The pattern that works is unexciting and it is worth insisting on.
The data is profiled before anything is planned, so the problems are known rather than discovered. A trial run is performed into a copy of the new system, and the results are checked by people who know what the data should look like rather than only by developers. Counts are reconciled on both sides: how many customers went in, how many arrived, and an explanation for every one that did not.
Then it is run again, because the first attempt always surfaces things. Migrations that succeed are usually rehearsed two or three times before the real one, and the real one is scheduled with a defined point at which you abandon it and go back.
The old system stays available, readable, for a period afterwards. This is cheap and it is the difference between an awkward week and a crisis.
What To Ask
- Has a trial import been run, and what did it find? Before agreeing a price, not after.
- How will we verify the data is right? Record counts alone are not verification. Someone who knows the business needs to look at real records.
- What is the rollback plan, and how long do we have to use it? There must be a point of no return, and it must be a decision rather than a surprise.
- What is deliberately not being migrated? There is nearly always something, and it should be your decision rather than a discovery.
- How long does the old system stay readable? Longer than feels necessary.
The Part Usually Forgotten
Attachments, documents and free-text notes are where migrations quietly fail. Structured records move cleanly because they map field to field. The eight years of context living in uploaded files and typed notes often has nowhere obvious to go, and it tends to be dealt with last, under time pressure.
If that material matters to how your business operates, and it usually does, it should be scoped at the start alongside the backup and verification plan rather than treated as a tidy-up task. Where the source is an ageing platform, this is also the moment the wider legacy system question has to be answered honestly, because a migration is only as good as your ability to get the data out in the first place.
More terms are in the glossary.
