Data migration, explained without the jargon

The version of this that works is simpler than the version most people imagine. Here is data migration without the vocabulary that usually surrounds it.

Data outlives the applications built on top of it, which is why the model deserves more thought than the screens. Budget a little time for it every quarter and it never becomes a project of its own.

The short version

Migrations fail on the data nobody knew existed. The teams that handle this well are rarely the ones with the biggest budgets. Assume whoever inherits this will have half your context and none of your patience.

Why people complicate it

Most of the confusion comes from tooling rather than from the idea itself. That sounds obvious written down. It is still the thing most often skipped.

Run it against a full copy before the real thing. Getting it slightly wrong is survivable. Ignoring it entirely is not. The version that survives contact with a real deadline is the simple one.

Turning this into a decision

Always have a documented way back. The teams that handle this well are rarely the ones with the biggest budgets. If it only works because one person remembers to do something, it does not work yet.

In practice

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
• Migrations fail on the data nobody knew existed — 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.