The most dangerous server in your fleet is the one nobody uses anymore

Decommissions never happen on a calm day. The box is old, something migrated off it months ago, and it gets powered down between two other emergencies — and then it sits in the rack, or on a shelf, still holding its SSH keys, its .env file, its database dump, and its root password, for years. A server you stopped using but never retired is the breach that needs no attacker skill: it still has valid credentials, it stopped getting patches, and nobody watches its logs. A decommission is a project with a checklist — the same first-30-minutes discipline, run in reverse: instead of restoring a service, you take one apart without leaving a key in the door.

1. Discovery: find out what the server is still doing

• Assume something still depends on it, then prove otherwise. The week before power-off, run the quiet inventory: last to see who logs in, crontab -l and the system cron directories to see what runs unattended, ss -tlnp to see what still listens, docker ps or the service list for what still runs. The cron monitoring checklist exists because forgotten jobs are normal; on a dying server they are the norm, not the exception.
• Search the rest of the fleet for references. Grep other machines' crontabs and scripts for the hostname and IP, check the DNS zone for records that point at it, and look in the monitoring dashboard for checks that would start screaming — or, worse, that stopped screaming months ago because someone silenced them. The DNS runbook habit applies: every record pointing at a dead server is a future support ticket or a hijackable name.
• Ask the humans what they think it does. One message to the team — "this box powers down on Friday; what do you believe it does?" — catches the load-report CSV one manager pulls monthly and the CI runner one developer swore was deleted. Answers that contradict the technical inventory are the finding; resolve them before the plug moves, not after.
• Write the dependency list down before anything is off. A decommission log entry (what it was, what pointed at it, what was migrated where, date) turns the next decommission into a copy-paste exercise and answers the auditor's "where did that system go?" years later.

2. Evacuate the data before the power goes off

• Export first, power off second — never the reverse. Dump the databases, rsync the document shares, export the configs and the logs the business still needs. Then prove the copy works: the restore test applies to decommission backups more than any other — a backup of a server you just wiped that nobody can restore is the same as no backup, with more confidence.
• Check the retention clock before you keep anything. Customer data may have a deletion promise attached, logs have their own retention policy, and an open legal or dispute hold beats every plan. Keeping data "just in case" beyond its policy is how a retired server becomes a liability: the deletion request checklist does not stop applying because the box is under a desk instead of in a rack.
• Move the job, not just the data. Every cron entry and service found in step 1 gets a documented new home — migrated to the new host with an owner, or explicitly killed in writing. "We'll re-create it if anyone misses it" without a written owner is how the monthly billing export silently dies for a quarter.
• Mind the copies nobody centralizes. Local Maildirs, git working directories on someone's home path, one-off database dumps in /tmp, and the export the last admin made "temporarily" — a decommission sweep that only checks the documented paths keeps exactly the files nobody documented.

3. Evacuate the secrets — then rotate everything that lived there

• The server is a keyring. Its disks hold SSH private keys and authorized_keys, API tokens in .env files, database passwords in cron one-liners, VPN and monitoring agent configs, TLS keys, and half a service account's credentials you forgot the service account had. Inventory them before shutdown: the secrets rotation checklist gets a new column that week — "what lived on the decommissioned box."
• Rotate, do not just hope the wipe got it. Any token, key, or password that existed on that machine gets replaced after the wipe, on the assumption the wipe was imperfect. That is the whole point of the API key rotation checklist: credentials die on a schedule and on events, and "we wiped the disk" is an event. Crosslink pass: update the key inventory register so the register stops listing credentials that no longer exist.
• Retire the access you provisioned for it. Its SSH key from the bastion, its service account, its firewall allow-rule, its backup-agent identity, its entry in the monitoring system — a decommissioned server whose credentials still work everywhere is a ghost employee with root.
• Say the quiet part: the disk holds your customers' data. A server leaving your control with intact disks is a data breach that has not happened yet. If the wipe in step 5 cannot be verified, the disks do not leave the building intact — the vendor data-deletion rule applies to hardware as much as to SaaS accounts.

4. Power off in the right order — and keep a parachute

• Graceful shutdown is a checklist item, not a reflex. Stop the services in dependency order, flush queues, take a final backup, then shut down — the same discipline the rollback checklist brings to releases. A hard-pulled power cable on a database mid-write turns a clean retirement into a corrupted-format mystery.
• Keep a cold parachute for thirty days. One final disk image or VM snapshot, stored offline and labeled with the date, plus a one-paragraph resurrection note (what it was, what the image contains, how to boot it) in the password manager or runbook vault. The month-long window is where "we still need that one file from the old server" surfaces; the starter kit habit is that no decommission deletes its own ability to be undone.
• Name who may resurrect it. One owner, one decision, and a calendar end-date for the snapshot — after which the image itself is deleted like any other copy. A shelf of "just in case" images is a shadow backup estate that no retention policy covers and every future breach will be blamed on.
• Announce the retirement date internally. A one-line message — "old-db goes dark Friday; speak now" — converts the last silent dependency into a reply instead of a post-mortem finding. Silence after the announcement is the evidence that nothing depended on it.

5. The wipe must match what the disks actually are

• Match the method to the medium. Spinning HDDs take a full overwrite pass or two; most SSDs are better served by the drive's own crypto erase (sanitize/secure-erase) than by overwrite utilities that wear-leveling can quietly circumvent. Self-encrypting drives make the erase one command; a Raspberry Pi's SD card and a USB stick are simply destroyed. If you cannot verify the wipe — pull the disks and keep or destroy them; hardware is cheaper than a breach.
• Cloud is a wipe too, just with different buttons. Terminating a VM does not delete its disks, snapshots, machine images, or the object-storage copies the backup job made — and unattached volumes keep billing and keep holding data. Delete the block devices, snapshots, and images deliberately, then verify in the console that nothing with the instance's name remains; the cloud cost runbook exists partly because nobody did.
• Chase the copies: backups and replicas. The backup server still holds months of this machine's data, the DR copy has it, the monitoring archive may hold logs with secrets in them. The decommission is not done until every backup set that includes the server has aged out or been pruned — note the date the last copy expires, and let the calendar enforce it.
• Verify, then write down that you verified. A wipe is complete when someone confirms it — the disk reads empty, the crypto-erase report says done, the drive is physically destroyed — and that confirmation lands in the decommission log with a name and date. "We wiped it" without a line in the log is a claim, not a control; the annual review will ask exactly this question.

6. Close the paper trail — a server is not retired until the map says so

• Update every map that still shows it. The asset register, the network diagram, the monitoring dashboard, the DNS zone, the on-call runbook that mentions its hostname, and the log inventory if it fed a central log. Stale maps are how the next incident wastes twenty minutes on a server that has been gone for a year.
• Cancel the money and the renewals deliberately. Its support contract, its licenses, its monitoring seat, its certificate renewals — cancel in writing and keep the confirmation, the same discipline as the vendor offboarding checklist. A renewal charge for a server that no longer exists is the smallest kind of leak; an auto-renewed SSL cert nobody watches is the certificate expiry checklist finding in reverse.
• Two weeks later, run the quiet check. No alerts mentioning it, no DNS queries hitting its old records, no logins attempted against its accounts, no invoice arriving for it. Anything that still references the dead box is a leftover from steps 1–6 — fix the map, then close the log entry for good.
• Log the whole thing on one page. Date, discovery findings, what was migrated where, what was rotated, wipe method and verification, copies and their expiry, cancellations. The postmortem template fits at half size — and the next decommission starts from a checklist that already knows your environment instead of from memory at 2AM.

A decommission is the reverse of an incident: discovery of what depends on it, export and verified restore of what matters, rotation of everything that lived on it, a graceful shutdown with a thirty-day cold parachute, a wipe matched to the actual disks — cloud disks and snapshots included — and a paper trail closed with a two-week-after check. The Ops Starter Kit ($14) includes the runbooks that structure retirements like this one, and the Automation Starter Pack ($19) schedules the follow-ups (rotation passes, snapshot expiry, the two-week check) so the retired server stays retired.