DNS Cutover Checklist for Moving a Django Site

Problem statement

You are moving a Django site to a new server, a new cloud, or behind a CDN, and the switch happens by changing DNS. DNS changes do not take effect everywhere at once: resolvers cache old answers for the record's TTL, and some ignore it. During that window, some users reach the old host and some the new. Without preparation, users see certificate errors, DisallowedHost pages, or write data to a database that is about to be abandoned.

1. Lower the TTL of the records you will change to 60 to 300 seconds at least one old-TTL period in advance.
2. Prepare the new host completely: certificates for all names, ALLOWED_HOSTS, CSRF_TRUSTED_ORIGINS, static and media files, and data.
3. Decide how to handle writes during the switch: freeze writes, point the old host at the new database, or proxy the old host to the new one.
4. Switch A, AAAA, and CNAME records together (including www and API subdomains), then verify from several resolvers and regions.
5. Keep the old host running and proxying for at least a few days, then raise TTLs again.

Checklist

Before the cutover

• Inventory every DNS record pointing at the old host: apex, www, api, admin, mail-related records, and verification TXT records.
• TTLs lowered to 300 seconds or less, at least 24 to 48 hours (or one previous TTL) before the switch.
• New host deployed and tested via /etc/hosts overrides or a temporary hostname.
• TLS certificates ready on the new host for every name; with HTTP-01 challenges, plan for issuing right after the switch, or use DNS-01 beforehand.
• ALLOWED_HOSTS, CSRF_TRUSTED_ORIGINS, and SECURE_PROXY_SSL_HEADER correct for the new proxy setup.

Data and writes

• Database migrated (dump and restore, or logical replication for minimal downtime).
• Media files synced to the new storage; final sync planned for cutover.
• Write strategy chosen: maintenance mode on the old host, old host connected to the new database, or old host proxying to the new host.
• Celery beat and cron jobs running on exactly one host at a time.

The switch

• Final data sync, then update records: A and AAAA (remove old AAAA if the new host has no IPv6), CNAMEs for subdomains.
• If moving behind a CDN, proxy mode and SSL mode set correctly (for Cloudflare, Full strict).
• Old host switched to its write strategy (maintenance page or proxy).

Verification

• dig +short shop.example.com @1.1.1.1 and @8.8.8.8 return the new address; check from several regions with an online DNS checker.
• HTTPS works on every name with a valid certificate (curl -I https://... and a browser).
• Logins, forms (CSRF), uploads, emails, and background jobs work on the new host.
• Monitoring and uptime checks point at the new host; error rates normal.

After the cutover

• Old host kept running (proxying or in maintenance) for at least the old TTL plus a safety margin, often a few days.
• Old host's logs checked for remaining traffic before shutdown.
• TTLs raised back to normal values (an hour or more).
• Old server decommissioned with data securely deleted (see the decommission checklist).

Explanation

DNS answers are cached by resolvers for the record's TTL, so a change reaches users gradually. Lowering TTLs ahead of time shortens that window, but only after the old, longer TTL has expired from caches. During the transition both hosts receive traffic, which is harmless for reads and dangerous for writes unless they all land in one database. Preparing TLS and Django host settings on the new side before the switch prevents certificate warnings and DisallowedHost errors for the first users who arrive.

Edge cases / notes

• Email records. MX, SPF, DKIM, and DMARC records are separate from web records; do not break email while moving the website.
• Apex CNAMEs. Apex domains cannot be CNAMEs at most providers; use ALIAS/ANAME records or provider flattening.
• HSTS preload. Sites on the preload list must have valid HTTPS on the new host from the first request.

Next steps

• Follow the full move in Move Django to a New Server.
• Set records correctly with Point a Domain to a Django Server.
• Fix certificate errors with Fix SSL Certificate Name Mismatch.

FAQ

How far in advance should I lower the TTL?

At least one previous TTL period before the switch, often 24 to 48 hours.

How long until everyone sees the new server?

Most users within the new TTL; a few resolvers take longer. Keep the old host serving or proxying for days.

What happens to writes during the switch?

Without a plan, they can go to two databases. Use maintenance mode, a shared database, or proxy the old host to the new one.

Do I need certificates on the new host before switching?

Yes, for every name, or users see certificate errors until issuance completes.