When database migrations is worth the effort

The advice here is unglamorous, which is probably why it gets skipped. Database migrations is not free, and pretending otherwise leads to bad decisions.

Code gets read far more often than it gets written, and usually by someone with less context than the author had. Write the reasoning down alongside the decision, because the reasoning is what changes first.

When it is worth it

Migrations should be reversible or provably safe. In practice this is a scheduling problem more than a technical one. If two people in the business would answer this differently, that gap is the actual problem.

When it is not

If nothing downstream depends on it and nobody is complaining, it can wait. There is a version of this that is over-engineered, and it is worth avoiding.

How to decide

Backwards-compatible changes let you deploy without downtime. That sounds obvious written down. It is still the thing most often skipped. Assume whoever inherits this will have half your context and none of your patience.

In practice

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
• 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

None of this needs a rewrite. Most of it is a morning's work once someone decides to do it.