A release that changes both application behavior and stored data needs more than a green build. The application and database can move at different speeds, and an older process may continue serving requests during deployment. Before choosing a migration command, establish which versions can read and write each data shape. This guide offers an original review workflow, not a report of a client delivery or a promise of uninterrupted deployment.
Start with a compatibility table
List the application versions that may run at the same time, the schema states they can encounter and the read/write behavior each combination requires. Include background jobs, reporting consumers and administrative tools where they touch the same data. A consumer outside the main repository can make an apparently isolated change a coordinated release.
Use the table to identify the first incompatible combination. Name the owner who can confirm that an old consumer has stopped before a contract is removed. A successful deployment of the new application does not, by itself, establish that every old worker has gone away.
Separate introducing a shape from depending on it
For a hypothetical field replacement, a team could first introduce the new representation while retaining the old one, deploy compatible application behavior, move existing data in controlled work and only later remove the old contract. Whether this sequence is appropriate depends on the database, write paths and consistency requirements. Dual writes add their own failure modes and need explicit reconciliation; they are not a universal safe default.
Agree how progress will be observed and what should stop the transition. Define how to handle a partially completed data operation before starting it. Keep the example in a representative non-production environment until the relevant assumptions have been exercised.
Review the database operation itself
Application compatibility and database execution are separate checks. The PostgreSQL ALTER TABLE documentation describes operation-specific locking and validation behavior. Consult the documentation for the actual deployed database version and inspect the planned operation rather than treating all schema changes as equivalent. Measure a representative rehearsal; this guide does not prescribe a production command or assert that a migration is lock-free.
Record the access needed, expected workload, stop criteria and the person authorized to continue. Test results should refer to the migration and application versions actually being promoted. Keep sensitive values out of the review record.
Make recovery a separate decision
Restoring an application artifact may leave the data in its new state. Before release, distinguish changes that can be reversed, changes that need a forward correction and situations that require a pause while an owner evaluates the data. Define the acceptable recovery path and verify the relevant backups or recovery procedure through an agreed rehearsal. Do not infer recoverability from the existence of a rollback button.
Keep the decision and handoff visible
A useful release record identifies the artifact, migration, compatibility assumptions, checks, receiving owner and remaining limitations. GitHub deployment environments provide documented protection and review controls; exact availability depends on the repository and plan. Choose controls that match the agreed responsibility boundary, and avoid bypassing a failed prerequisite to make a pipeline appear successful.
Connect the release problem to a bounded engagement
For a team in the UK, confirm change windows, communication hours, access and decision authority during scoping. Explore DevOps services for coordinating delivery responsibilities when the work crosses application, data and infrastructure ownership. Agree whether the engagement ends with implementation or includes ongoing operational responsibilities.