Data migration: what to get right first
The gap between knowing this and actually doing it is where most teams lose ground. If you only fix one thing about data migration this quarter, make it the first item below.
Data outlives the applications built on top of it, which is why the model deserves more thought than the screens. It rarely shows up as a line item, which is exactly why it slips.
Start here
Migrations fail on the data nobody knew existed. This is the sort of thing that compounds, quietly, in both directions. The version that survives contact with a real deadline is the simple one.
Then this
Run it against a full copy before the real thing. In practice this is a scheduling problem more than a technical one. It is the sort of thing that looks like polish right up until it costs you an enquiry.
Eventually
Always have a documented way back. None of that requires a large budget, only a decision and someone to own it. The practical test is whether someone new to the project could tell, in a minute, that it had been handled.
The short version
Most data problems are ownership problems that turned into technical ones. Three things worth confirming about data migration before you move on:
- Someone can say what the current setup is without going to look
- Always have a documented way back — and you know whether that is true here
- There is a way to tell whether the last change to this helped
Worth checking on your own setup before it becomes someone else's problem to fix.