The real cost of ignoring database migrations

The gap between knowing this and actually doing it is where most teams lose ground. Nobody bills you for neglecting database migrations. The cost shows up somewhere else.

Most development decisions are really maintenance decisions wearing a different hat. Check it against what you would want a competitor's site to get wrong.

Where the cost lands

• Time spent on work that should not have been necessary
• Enquiries that quietly never arrive
• Migrations should be reversible or provably safe
• Rework, once the problem is finally visible

Test them against a copy of real data volumes. 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.

Making it stick

Backwards-compatible changes let you deploy without downtime. Where this goes wrong is almost never a lack of knowledge. Write the reasoning down alongside the decision, because the reasoning is what changes first.

The short version

Code gets read far more often than it gets written, and usually by someone with less context than the author had. Three things worth confirming about database migrations before you move on:

• Someone can say what the current setup is without going to look
• Migrations should be reversible or provably safe — 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.