A short guide to database migrations

We end up explaining this on discovery calls often enough that it deserved writing down. Everything we would tell a client about database migrations in the time it takes to drink a coffee.

Most development decisions are really maintenance decisions wearing a different hat. It is the sort of thing that looks like polish right up until it costs you an enquiry.

Why this earns attention

Migrations should be reversible or provably safe. This is the sort of thing that compounds, quietly, in both directions. The teams that stay on top of it are the ones who put it on a calendar rather than a wish list.

What good looks like

Test them against a copy of real data volumes. The reasoning matters more than the rule, because the rule has exceptions. The practical test is whether someone new to the project could tell, in a minute, that it had been handled.

Warning signs

Backwards-compatible changes let you deploy without downtime. Where this goes wrong is almost never a lack of knowledge. Most teams find the first pass takes an afternoon and the maintenance takes minutes a month.

How to tell if yours is fine

The question is rarely whether something can be built, but what it costs to keep running afterwards. Three things worth confirming about database migrations before you move on:

• Someone can say what the current setup is without going to look
• Backwards-compatible changes let you deploy without downtime — 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.