Checklist for Decommissioning an Old Django Server

Problem statement

You moved your Django app to a new server or platform, and the old one is still running "just in case". Old servers are a quiet risk: unpatched software, credentials that still work, cron jobs sending duplicate emails, DNS records that could be hijacked, and a monthly bill. Shutting one down properly means confirming it is truly unused, keeping what you might need, and removing every way it can still act or be abused.

1. Confirm zero traffic and no scheduled jobs: web logs, Celery workers, cron, beat, and outgoing connections.
2. Take final backups of the database, media, configuration, and logs, and verify they restore.
3. Revoke credentials the server held: database users, API keys, cloud IAM keys, SSH deploy keys, and tokens.
4. Remove DNS records, load balancer targets, firewall rules, and monitoring checks pointing at it.
5. Wipe disks or destroy volumes and snapshots per policy, cancel billing, and update documentation.

Checklist

Confirm it is idle

• Web server access logs show no real traffic for several days (only scanners).
• Celery workers, beat, and cron jobs stopped; no duplicate scheduled tasks running elsewhere.
• No outbound connections to databases, Redis, or APIs (ss -tnp) from leftover processes.
• No other systems (reports, scripts, partners) still calling its IP address.

Preserve what you might need

• Final database dump, if this server held a database, restored once to prove it.
• Media files synced to the new storage and counts compared.
• Configuration archived: Nginx, systemd units, environment files (encrypted), crontabs.
• Logs exported if retention policies or audits require them.

Revoke access and credentials

• Database users used by the old server dropped or their passwords rotated.
• API keys and tokens stored in its environment rotated (email provider, payment provider, storage, Sentry).
• Cloud IAM users or instance roles removed; SSH deploy keys deleted from Git hosts.
• Its SSH host key removed from CI known_hosts secrets; its IP removed from database and firewall allowlists.

Remove from infrastructure

• DNS records for the server (and any subdomains pointing at its IP) deleted.
• Removed from load balancer target groups, monitoring, uptime checks, and backup jobs.
• Firewall and security group rules referencing it deleted.

Destroy and document

• Instance terminated; volumes, snapshots, and images deleted or retained per policy.
• For physical or rented servers, disks securely wiped or provider data destruction requested.
• Billing confirmed stopped (static IPs, volumes, and backups often keep billing).
• Runbooks, architecture diagrams, and inventories updated.

Explanation

Servers accumulate dependencies: scheduled jobs, credentials in environment files, allowlist entries, DNS records, and integrations that call them by IP. Turning off the machine without unwinding those leaves security gaps (valid credentials, takeover-prone DNS) and operational surprises (duplicate jobs before shutdown, broken integrations after). A staged decommission, confirm, preserve, power off, revoke, destroy, makes each step reversible until the last one.

Edge cases / notes

• Shared servers. If other apps ran on the same host, inventory them before shutdown.
• Email reputation. If the server sent email directly, update SPF records to remove its IP.
• Compliance. Some regulations require certificates of data destruction for disks with personal data.

Next steps

• If you are still moving, follow Move Django to a New Server.
• Switch traffic with the DNS Cutover Checklist for Moving a Django Site.
• Rotate keys with Respond to Leaked Django Secrets as a reference.

FAQ

How long should I keep the old server after migrating?

Until logs show no real traffic for several days and all jobs run elsewhere; then power it off for a few more days before destroying it.

Why revoke credentials if the server is deleted?

Copies of its environment files, backups, or snapshots may still exist, and the credentials may be valid elsewhere.

What is a dangling DNS record?

A record pointing at an IP you released. Someone else may get that IP and receive your traffic.

Do snapshots keep costing money?

Yes. Volumes, snapshots, static IPs, and backups often keep billing after the instance is gone.