A release needs a tested recovery path

An update often changes more than application code. Database structures, background jobs and external interfaces can change as well. Release preparation therefore needs a clear answer to how operations will recover if the change fails.

Treat data and application changes together

• Check whether the previous application version can use the new database structure.
• Actually restore a backup in a separate environment.
• Account for running background jobs and external requests already sent.
• Assign an incident owner and define when activation should be stopped.

A useful acceptance test completes a representative business operation before the update, activates the change and repeats that operation. If switching back is part of the plan, test that path too. Business results matter: an available login page does not establish that orders remain complete and are processed only once.

The recovery path must fit the change. An irreversible data transformation may call for a prepared forward correction. Make and document that decision before publishing the release.