Identify the configured database and migration tooling. Obtain a restorable backup and test the exact migration set against a representative protected copy.

1. Generate and review migrations during development. Inspect column removals, type conversions, indexes and data transformations rather than treating generated SQL as automatically safe.

2. Check the migration status in the intended production environment. Verify the database name without printing its credentials.

3. Choose a release sequence compatible with requests and workers that may still run old code. Stage large changes when immediate locks or rewrites would interrupt service.

4. Run the approved migrations once and retain the output. Avoid concurrent deployers attempting to alter the same database.

5. Check schema state and key application workflows before considering the release complete. Keep the backup and recovery decision available until the change is proven.

Create and edit a representative record, run the relevant query and check message consumers that access changed entities. Confirm the migration tracking table reflects the expected versions.

If a migration stops partway through, inspect actual schema state and engine behavior before rerunning. A rollback command may itself lose data or fail to undo an external side effect.

• Deploying Symfony in the production environment
• Planning a backward-compatible database deployment
• Rolling back application files without losing new user data
• Managing Symfony cache pools after deployment

• Symfony databases and Doctrine
• Doctrine migrations