Prepare a verified backup and rehearse against a protected database copy. Identify the production settings and database alias so the management command targets the right database.

1. Generate and review migration files during development. Inspect destructive operations and data migrations, including how they handle existing nulls, duplicates and large tables.

2. Commit the migration files with the code. Review showmigrations and the planned operations on the target before applying them.

3. Choose an order that permits old and new application processes to coexist where needed. A staged additive change can avoid requiring an immediate destructive rename.

4. Run the approved migrate command once using the application virtual environment. Prevent simultaneous deployers from changing the same schema.

5. Verify the migration history and representative application writes. Restart affected workers after the compatible code release is active.

From the correct application environment, inspect the migration history and proposed plan before touching the database. Replace the settings module and interpreter path with those used by your protected staging copy or approved production inspection.

.venv/bin/python manage.py showmigrations \
  --settings=config.settings.production --database=default
.venv/bin/python manage.py migrate --plan \
  --settings=config.settings.production --database=default

The second command displays planned operations; it does not apply them. Check for field removal, large-table rewrites, data migrations and unexpected earlier dependencies. Confirm that the settings module actually points to the intended database before assuming the displayed plan belongs to this release.

Expected result: The release record lists the exact migrations expected, their recovery approach and the affected workflows. Rehearse those operations on a protected copy, then schedule one controlled production migration rather than letting multiple deployment jobs race.

Read an old record, create a new one and run the affected background task. Check for unexpected database locks, failures or changes to existing data.

If a migration fails, inspect what the database committed. Transactional DDL support differs across engines and operations. Do not mark migrations as applied simply to hide a mismatch.

• Planning a backward-compatible database deployment
• Rolling back application files without losing new user data
• Setting Django production settings and secret keys
• Choosing WSGI or ASGI for Django hosting

• Django migrations
• Django: Django Admin

• Django: Django Admin