Getting started with database migrations
This is one of those topics that looks small until it costs you something. A short on-ramp to database migrations for teams who have not touched it before.
Most development decisions are really maintenance decisions wearing a different hat. The practical test is whether someone new to the project could tell, in a minute, that it had been handled.
What is actually at stake
Migrations should be reversible or provably safe. In practice this is a scheduling problem more than a technical one. It is worth deciding this deliberately rather than inheriting whatever the last person set up.
Your first week
- Find out what is already in place
- Test them against a copy of real data volumes
- Change one thing and measure it
Backwards-compatible changes let you deploy without downtime. 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.
The short version
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
Worth checking on your own setup before it becomes someone else's problem to fix.