Treat the migration as part of the release
A schema change can outlive the application version that introduced it. Before deployment, identify which running processes, jobs and integrations read or write the affected data. If old and new application versions can run together, both need an understood relationship with the schema. A source rollback is not automatically a data rollback. Put the migration and application deployment sequence in the same release plan.
Prefer a compatibility conversation
Consider replacing a customer-name column with separate given and family names. Ask how older code behaves while the new fields are introduced, how existing records are populated and when the old field can be removed. The example is deliberately simple: real names also resist simplistic splitting. Keep the business transformation distinct from the schema mechanics so a technically successful migration does not silently damage meaning.
Rehearse with representative data
Use a safe copy or synthetic dataset that represents empty values, large records and unusual states. Measure how long the migration takes and whether normal operations are blocked. Do not assume a migration that finishes quickly on ten rows behaves similarly at production scale. Record the revision, dataset characteristics and observed effects. If the environment differs materially from production, state the uncertainty in the release decision.
Define the recovery choice
For each step, decide whether the response to failure is rollback, forward correction or temporarily stopping an affected feature. Identify the point at which reversing a transformation may lose newer information. Agree who can authorise that action. Canary deployment guidance is useful for assessing a release gradually, but a shared database change may affect more than the canary group. Evaluate that limitation before relying on gradual traffic alone.
Retain the sequence with the change
Keep preconditions, migration steps, verification queries and recovery decisions with the reviewed change. Confirm that background workers and administrative tools are included. After deployment, check both customer journeys and data integrity. A useful record explains what was tested and what was observed, making the next migration less dependent on memory or assumptions about what the deployment platform will reverse for you.
Sources & further reading
Reference material for the guidance and examples above. Where included, community discussions provide context rather than verified incident evidence.
Retrospective weekly fieldnote, prepared with AI assistance and published on 12 September 2026. Examples are illustrative; this is not a client case study or a claim about events in the assigned week.