Learn · Data and content
A migration is a recorded, repeatable change to the shape of a database: adding a column, splitting a table, changing a type. It is written as code and applied in order, so the same change runs identically on a developer's machine, on staging, and in production.
Doing it by hand in a database console is where data goes missing. Nothing records what was run, staging drifts away from production, and the change that worked in testing behaves differently against real rows.
The part people underestimate is that a migration runs while the application is still using the data. A change that locks a large table for a minute is a minute of downtime, which is why serious migrations are often split into several deliberately small steps.
Updated September 2026
Related
A data model is the decision about what things exist in your system, what fields each one has, and how they relate to each other. It takes an afternoon to sketch and it governs what the software can do for years afterwards, which is why skipping it is the expensive option.
Typically: a developer commits code to version control, that triggers an automated pipeline which runs tests and builds the site, and if everything passes, the pipeline deploys it to the host, often first to staging and then to production. Modern setups make this near-instant and repeatable.
You restore one. A backup nobody has ever restored is a file, not a backup. Pick a date, restore it somewhere that is not production, and open the result to check the data is actually there and readable. Until you have done that once, you do not have a backup, you have a hope.