Database migrations: the questions we get asked most

This is one of those topics that looks small until it costs you something. The questions about database migrations that come up most often on our calls.

Code gets read far more often than it gets written, and usually by someone with less context than the author had. It rarely shows up as a line item, which is exactly why it slips.

Do we need to care about this?

Migrations should be reversible or provably safe. Small and consistent beats large and occasional here. If it only works because one person remembers to do something, it does not work yet.

Can it wait until after launch?

Occasionally. More often the post-launch version costs several times the pre-launch one. None of that requires a large budget, only a decision and someone to own it.

How do we know it is working?

Backwards-compatible changes let you deploy without downtime. Getting it slightly wrong is survivable. Ignoring it entirely is not. Assume whoever inherits this will have half your context and none of your patience.

What this looks like day to day

Most development decisions are really maintenance decisions wearing a different hat. Three things worth confirming about database migrations before you move on:

• Someone can say what the current setup is without going to look
• Test them against a copy of real data volumes — and you know whether that is true here
• There is a way to tell whether the last change to this helped

Most of the value here comes from doing the first two things, not all of them.