Confirm RAILS_ENV, database identity, migration history and a verified backup. Review seeds as executable application code that may create or change records.

1. Generate and review migrations in development, then commit them with the release. Inspect destructive changes and large data operations.

2. Check migration status against the intended production database using the application’s supported command and environment.

3. Use the approved deployment operation, such as applying pending migrations, after rehearsing it on a representative copy. Understand what db:prepare does in the installed Rails version before placing it in automation.

4. Prevent concurrent deployment jobs from changing the schema at the same time. Coordinate old and new application code when schema changes are not immediately compatible.

5. Verify the resulting schema and application writes. Retain command output and the backup reference with the release record.

From the intended release directory, with the approved Ruby environment and protected production database configuration already loaded, inspect the migration list:

RAILS_ENV=production bin/rails db:migrate:status

Compare the database identity and migration versions with the release plan. A down migration is pending; an up migration has been recorded as applied. A NO FILE entry needs investigation against the repository and release history, not deletion of migration tracking rows. This status check does not make the proposed changes safe: review the pending migration code and recovery plan before the separately approved migration step. Repeat the status check afterward and verify real application reads and writes.

Read existing data and create a harmless new record through the application. Check workers that use the modified tables as well as the web interface.

If a command fails, inspect which operations committed and the actual database state. Do not run a reset or drop command to make migration status appear clean.

• Planning a backward-compatible database deployment
• Rolling back application files without losing new user data
• Operating Rails background jobs on hosting
• Building and serving Rails production assets

• Rails migrations
• Rails command line