Expand before switching
Start with additive changes, such as a nullable column, a new table, or an index created using the database's supported online method. Deploy code that can tolerate both the old and new schema before relying on the new field.
Backfill existing rows in bounded batches, monitor database load, and make the job resumable. Avoid one large transaction that holds locks for a long time or creates a sudden spike in replication lag.
Contract after verification
Once all running application instances use the new structure, verify data consistency and monitor errors before removing old columns or constraints. Keep the compatibility window long enough for delayed jobs and rollback procedures.
Test the migration against production-like data volume and define a recovery plan. A rollback of application code may not reverse a destructive schema change, so preserving old data or using a forward repair can be safer.