Data migration: the questions we get asked most
Most teams know this matters. Fewer have decided who owns it. The questions about data migration that come up most often on our calls.
Most data problems are ownership problems that turned into technical ones. The version that survives contact with a real deadline is the simple one.
Do we need to care about this?
Migrations fail on the data nobody knew existed. 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.
Can it wait until after launch?
Occasionally. More often the post-launch version costs several times the pre-launch one. The reasoning matters more than the rule, because the rule has exceptions.
How do we know it is working?
Always have a documented way back. Small and consistent beats large and occasional here. If two people in the business would answer this differently, that gap is the actual problem.
How to tell if yours is fine
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 any of that sounds like a description of your current setup, it is fixable.