How to get data migration right
It comes up on almost every project, usually later than it should. The short answer to data migration is that it is mostly a sequence of small decisions, not one big one.
Numbers get quoted in meetings long after anyone remembers how they were calculated. The failure mode is not doing it wrong, it is doing it once and assuming it stays done.
Why it matters
Migrations fail on the data nobody knew existed. That sounds obvious written down. It is still the thing most often skipped. It is worth deciding this deliberately rather than inheriting whatever the last person set up.
The steps
- Establish what you have today before changing anything
- Run it against a full copy before the real thing
- Always have a documented way back
- Write down the decision so the next person does not re-litigate it
Always have a documented way back. It is worth being explicit about, because assumptions differ quietly. The practical test is whether someone new to the project could tell, in a minute, that it had been handled.
Turning this into a decision
In practice
Data outlives the applications built on top of it, which is why the model deserves more thought than the screens. Three things worth confirming about data migration before you move on:
- Someone can say what the current setup is without going to look
- Run it against a full copy before the real thing — and you know whether that is true here
- There is a way to tell whether the last change to this helped
If you want a second opinion on how yours is set up, ask.