Run migrations as a release step
Use a deliberate migration command or release job with a single owner, rather than having every web instance race to apply schema changes at startup. Capture its output and make failures visible before routing traffic to code that requires the new schema.
Keep the migration compatible with both the currently deployed code and the next release. This allows instances to be replaced gradually and gives operators time to diagnose a problem without creating a mixed-version outage.
Verify before and after rollout
Take or confirm an appropriate backup according to the database's recovery process, and check that migration duration and locking behavior fit the maintenance window. Do not assume a hosting rollback also restores database contents.
After deployment, inspect application errors and database health, then remove temporary compatibility structures only in a later, separately reviewed migration. Document the order and recovery action so another operator can repeat it.