Server decommissioning: the part that happens at a keyboard, not at a loading dock

Most of decommissioning a server happens before anyone touches the hardware, and the failures that make these jobs memorable are software failures: a service nobody knew about, a backup that could no longer be restored, a drive that left the building with data on it. Here is the order that avoids them.

First, find out what still talks to it

Not what the documentation says depends on it: what actually connects to it. Network connections, authentication requests, scheduled transfers, monitoring checks. A period of observation before the shutdown, with logging turned up, finds the dependency the documentation forgot, and there is almost always one.

Then find what points at it

DNS records, load balancer pools, firewall rules, scheduled jobs on other machines, scripts with the address written in by hand. The server can be perfectly quiet and still be a destination something will try to reach next month. Each pointer removed now is an alert that will not fire at a bad hour later.

Power off is a test, not the end

Shut the machine down and leave it in the rack, powered off but restorable, for an agreed period. If something breaks, the fix is a power button. The mistake this step exists to prevent is the machine that is wiped and shipped the same afternoon it was switched off, discovered to matter a week later.

Backups and retention outlive the server

Retiring the machine does not retire its retention obligations. Decide what the last backup is, where it lives, how long it is kept, and, crucially, what it can be restored onto once the original hardware is gone. A backup that can only be restored to a machine that no longer exists is an archive in name only.

The data does not leave when the power does

The drives, obviously. Less obviously: cache modules on RAID controllers, the management controller with its credentials and network configuration, and any removable media left in the chassis. Every storage device is erased or destroyed with a record per serial number before the chassis goes anywhere, and the method has to match the media type. The methods, and the media each one can address, are set out in which destruction method suits which media. The options and the traps are on the destruction page.

Strike it from the systems of record

The asset register, the CMDB, the monitoring system, DNS, the licence inventory, the support contract. A server that is physically gone but administratively alive costs money and produces confusion in every audit until someone closes the loop. The retirement is finished when the records say so, not when the rack is empty.

The paperwork for a single machine

A one-server retirement deserves the same shape of record as a full exit, in miniature: a signed handover when the chassis leaves your custody, a line per storage device stating the method applied, and a final destination for the unit itself, resold, recycled or destroyed. The same journey at asset level is walked through in one asset followed out of the building. It feels like ceremony for one box. It stops feeling like ceremony the first time an auditor picks one serial number from three years ago and asks what happened to it, because the answer is either on file or it does not exist.

When it stops being a task and becomes a project

One server is an operations task that ends with a collection and a certificate. A row of racks, or a hall, is a different animal: sequencing, floor access, staging space, a chain of custody with many handovers, and a deadline attached to a lease. The physical side of that work is described on the removal page, and the order the whole exit has to follow is in the exit sequence. The discipline in this article does not change with scale. The planning around it does.