Django Go-Live Day Runbook

Problem statement

Launching a Django site, or moving an existing site to new infrastructure, concentrates risk into a few hours. DNS changes propagate unevenly, certificates must be valid before traffic arrives, data must be migrated without losing writes, and everyone involved wants to know whether it worked. Launches that go badly usually fail on coordination rather than technology: nobody owned the DNS change, the rollback step was never written down, or monitoring was set up after the first errors.

A go-live runbook turns the launch into a rehearsed sequence with owners, checkpoints, and decision criteria. This guide provides a template you can adapt for a new site launch or a migration to new servers.

Quick answer

1. T-7 days: lower DNS TTLs, complete the deployment checklist, rehearse data migration and rollback, set up monitoring and alerting.
2. T-1 day: freeze non-essential changes, confirm backups, verify TLS on the new environment, brief the launch team.
3. Launch window: announce start, put the old site into read-only or maintenance mode if migrating data, take a final backup, migrate data, deploy, run smoke tests against the new environment directly.
4. Cutover: switch DNS or load balancer routing, verify from outside, monitor errors, latency, and business events.
5. Decision point: go or roll back based on predefined criteria within a fixed time.
6. After launch: keep enhanced monitoring for 24 to 48 hours, restore normal TTLs, keep the old environment available until confident, hold a short review.

Roles

Assign names before launch day:

One person can hold several roles on a small team, but each role must have an owner.

T-7 days: preparation

Infrastructure and configuration

• Production environment built and deployed with the release candidate.
• python manage.py check --deploy passes with production settings.
• DEBUG = False, correct ALLOWED_HOSTS, CSRF_TRUSTED_ORIGINS, secure cookies, and HTTPS settings.
• Static files collected and served; media storage configured.
• Email sending tested from production configuration with domain authentication.
• Background workers and scheduled jobs running on the new environment (scheduled jobs disabled on the old environment at cutover to avoid duplicates).

DNS

• Lower the TTL on records that will change (for example to 300 seconds) at least one old TTL period before launch, so resolvers pick up the change quickly on launch day.
• Document current record values to restore on rollback.

dig +noall +answer www.example.com
dig +noall +answer example.com

TLS

• Certificates for all launch hostnames issued and installed on the new environment, or issuance planned for a method that does not depend on DNS already pointing at the new servers (for example DNS-01 challenges).
• Test the new environment with the production hostname before DNS changes:

curl -sv --resolve www.example.com:443:NEW_SERVER_IP https://www.example.com/ -o /dev/null 2>&1 | grep -E "subject:|expire date|HTTP/"

Data migration rehearsal

• Perform a full migration into the new environment using a recent copy of production data.
• Time each step: export, transfer, import, verification.
• Write validation queries: row counts for key tables, latest record timestamps, totals for financial data.

SELECT 'users' AS table_name, count(*) FROM auth_user
UNION ALL SELECT 'orders', count(*) FROM orders_order
UNION ALL SELECT 'latest_order', extract(epoch FROM max(created_at))::bigint FROM orders_order;

Monitoring

• Uptime checks for key URLs on the new environment.
• Error tracking receiving events from production.
• Dashboards for requests, error rates, latency, and database health.
• Alert routing tested.

Rollback rehearsal

• Write the rollback steps (step "Rollback" below) and walk through them once.
• Decide rollback criteria in advance, for example: error rate above 5 percent for 10 minutes, checkout failures, data validation mismatch.

T-1 day: freeze and confirm

• Code freeze except for launch fixes.
• Confirm backups of the old environment's database and media are current and restorable.
• Confirm access: DNS provider, registrar, cloud accounts, servers, and third-party dashboards for everyone who needs them.
• Prepare communications: maintenance notice (if downtime is expected), launch announcement, and incident templates.
• Check that third-party integrations (payment webhooks, OAuth redirect URLs, API allowlists) are configured for the new environment's hostnames and IP addresses.

Launch window

Timestamps are relative to the start of the launch window.

00:00 Start. Launch lead announces start in the team channel. Everyone confirms readiness.

00:05 Freeze writes (migrations only). If data moves from an old system, enable maintenance or read-only mode on the old site so no writes are lost:

touch /srv/oldsite/maintenance.on

Confirm that write endpoints are blocked and background jobs on the old system are stopped.

00:10 Final backup. Take and verify a final backup of the old database:

pg_dump --format=custom --file=/var/backups/final-before-launch.dump "$OLD_DATABASE_URL"
pg_restore --list /var/backups/final-before-launch.dump | head

00:20 Data migration. Run the rehearsed migration. Record duration.

00:50 Data validation. Run the validation queries on the new database and compare with the old. Stop and investigate if counts or totals differ unexpectedly.

01:00 Deploy and migrate schema. Deploy the release to the new environment and apply Django migrations:

python manage.py migrate --noinput
python manage.py check --deploy

01:10 Smoke tests against the new environment directly (using --resolve or a hosts file entry, before DNS changes):

• home page, key landing pages, and admin login
• user login and registration
• a full critical flow (for example checkout with a test payment)
• file upload and display
• an email-triggering action
• an API request from a client if applicable

01:30 Go or no-go. Launch lead confirms smoke tests and data validation. If no-go, stop here: the old site remains authoritative; remove maintenance mode.

01:35 Cutover. Change DNS records or load balancer targets to the new environment. Record the exact time.

01:40 External verification.

dig +short www.example.com @1.1.1.1
dig +short www.example.com @8.8.8.8
curl -sI https://www.example.com/ | head -5

Check from a mobile network and a second location. Some users will still reach the old environment until caches expire; keep it in maintenance mode or redirect it to the new environment.

01:45 to 03:00 Enhanced monitoring. Observer watches:

• 5xx rate and latency
• error tracker for new exception types
• database connections and CPU
• background job queues
• business signals: sign-ups, orders, payments

03:00 Decision point. Launch lead declares success or starts rollback based on the predefined criteria.

Rollback

If rollback criteria are met:

1. Announce rollback in the team channel.
2. Revert DNS records or load balancer targets to the documented old values.
3. If writes happened on the new environment after cutover, decide how to handle them: export new records for manual reconciliation, or replay them into the old system. This decision should be pre-agreed for the rollback plan.
4. Remove maintenance mode on the old site.
5. Verify the old site works for key flows.
6. Communicate status to stakeholders and users.
7. Keep the new environment running (without traffic) for investigation.

The longer the new environment accepts writes, the more complex rollback becomes. Keep the decision window short.

After launch

• Keep enhanced monitoring and on-call coverage for 24 to 48 hours.
• Restore normal DNS TTLs after a few days of stability.
• Update third-party integrations still pointing at old endpoints.
• Keep the old environment and final backup available for an agreed period before decommissioning.
• Hold a short review: what went well, what took longer than rehearsed, what to change in the runbook.

Verify

Verification check:

• every runbook step has an owner and expected duration
• data validation queries match between old and new systems
• smoke tests passed before DNS cutover
• DNS resolves to the new environment from multiple resolvers
• rollback steps and criteria were written before launch day

Explanation

A launch combines many small, individually simple changes whose order matters. Rehearsing data migration reveals its real duration, lowering DNS TTLs in advance makes both cutover and rollback fast, and testing the new environment with the production hostname before switching DNS catches certificate and configuration problems while users still use the old site. Predefined decision criteria keep the team from debating under pressure whether to roll back.

Edge cases / notes

Zero-downtime migrations

For systems that cannot accept a maintenance window, use database replication from old to new, switch writes at cutover, and keep the window of dual systems as short as possible. This requires more preparation than a read-only freeze.

CDN and proxy caches

If a CDN sits in front, its origin configuration may need updating instead of (or in addition to) DNS. Purge cached pages that reference old asset URLs.

Search engine considerations

When URLs change during a launch, prepare permanent redirects from old URLs, update sitemaps, and verify that the new site does not block crawlers with a leftover staging robots.txt or noindex header.

Common mistakes

• Lowering DNS TTLs on launch day instead of days before.
• Discovering certificate problems only after switching DNS.
• Running scheduled jobs on both old and new environments after cutover.
• No agreed rollback criteria or reconciliation plan for writes made after cutover.

Next steps

• Complete the technical review with the Django Deployment Checklist for Production.
• Standardize smoke tests with the Post-Deploy Verification Checklist for Django.
• Prepare rollbacks with How to Roll Back a Django Release Safely.
• Set up external checks with Set Up Uptime Monitoring and Alerts for Django.

FAQ

How far in advance should I lower DNS TTLs before a launch?

At least one full old TTL period before the change, often a few days. Resolvers that cached the old record with a long TTL only pick up the lower TTL after it expires.

How do I test a new Django server before switching DNS?

Use curl --resolve or a local hosts file entry to send requests for the production hostname to the new server's IP address, including HTTPS and key user flows.

When should I roll back a Django launch?

When predefined criteria are met, such as sustained elevated error rates, failures in critical flows, or data validation mismatches. Decide the criteria and time window before launch day.

What should happen to the old environment after launch?

Keep it in maintenance or redirect mode and preserve its final backup for an agreed period, then decommission it once the new environment is stable and reconciled.