A code rollback is not a database rollback
Deploying an older application version does not automatically reverse a schema migration or recover data deleted by it. Before release, list the old and new code versions, schema changes, background workers and external consumers. Identify which combinations must coexist during a rolling deployment.
Use compatible phases
For a suitable change, introduce the new schema in a backward-compatible form, deploy code that can work during the transition, backfill data with monitoring, and switch reads only after verification. Remove the old field or behavior in a later controlled release once all consumers have migrated.
The exact technique depends on the database and framework. A column rename, type conversion or constraint can still lock tables or affect older code. Test the migration against representative data and concurrent workload, and set a stop condition.
Plan for recovery
Verify backups and the ability to restore to an isolated environment. Decide when rollback remains safe, what happens to writes made after deployment and how to reconcile any partially completed backfill. A down migration may be destructive or may not recreate deleted values.
During release, observe application errors, database locks and migration progress. If a stop condition is reached, follow the rehearsed decision path rather than automatically restoring an old database over new transactions.
Record the final schema version, deployed application version and follow-up cleanup date. Test the old and new application paths before removing compatibility.
Further reading
Read the official documentation. For help applying these checks, explore Clouvenix services.