Database Migration

A database migration is the most delicate operation in routine software: changing the structure of the database while the system runs on it and the data lives in it — like renovating the building while the business operates inside. Whole engineering practices exist to make migrations boring, and their absence is how systems become impossible to update.

What It Is

A database migration is a controlled, versioned change to a database's schema or data: adding columns, splitting tables, transforming values, backfilling. Mature practice runs migrations as code — each one a scripted, reviewed, testable change recorded in sequence, applicable to a copy first (see staging) and reversible or paired with a rollback plan. The hard cases are long migrations on large live databases (locking a table while it transforms means downtime), handled by expansion-contraction patterns: add the new structure, migrate gradually, then remove the old — never a single risky cutover.

Why It Matters to You

Migration discipline is a direct proxy for operational maturity, in vendors and internal teams alike. Teams with scripted, versioned, rehearsed migrations ship structural change routinely; teams that hand-edit production databases (the legacy habit) accumulate fear, and the fear is rational — every change becomes an event with downtime risk, so change stops, and the system fossilises. In vendor due diligence, ask how schema changes reach production; in acquisition diligence, migration history reveals whether the asset you are buying can still evolve or is a museum piece with users.

When You'll Meet It

In release planning, vendor assessment, and any project that changes what data is captured. Ask for the migration that added the last major feature — rehearsed script or heroic weekend?