Server Decommission Checklist: What to Document Before Pulling a Server
A decommissioned server that still exists in asset tracking is a ghost that haunts the next audit. A drive that leaves the rack without a wipe certificate is worse. Most bad decommissions are not hardware problems — they are documentation problems: nobody wrote down the asset ID, nobody recorded the wipe, nobody released the IP, and six months later nobody can find the server or the paperwork. This is the checklist that keeps a decomm clean.
Before you touch anything: the decomm ticket must answer these
- Authorization. Who approved this decommission and when — ticket, change record, or work order number. "It was on the list" is not authorization you can prove.
- Identity. Hostname, asset tag, serial number, rack and U position. Record all four in the ticket before removal; after the rails slide out, the rack position is gone forever.
- Out of production, verified. Confirm the server is removed from load balancers, monitoring, DNS, and backups before the shutdown. The classic failure: a "retired" web node still answering health checks while its drives are being wiped.
- Data-destruction plan. The approved wipe method for this data classification (secure erase, full overwrite, or physical destruction), which tool performs it, and who verifies the output. The wipe happens while the server is still racked and powered — never after the hardware is gone.
- Destination. Recycle, redeploy to another site, return to leasing/vendor, or internal reuse. If it leaves the building, record the carrier and tracking at this stage.
The shutdown and cable-removal order
- Graceful shutdown first. OS-level shutdown, not a yank of the power cords. Confirm via iLO/iDRAC/iKVM that the host is fully off — standby power can fool you.
- Photograph the cable layout. One phone photo of the rear before anything moves. Cable labels get missed; photos don't lie.
- Label every cable before touching it. Label the far end too — that cable might be a cross-connect someone else owns.
- Power cords first, then data. Disconnect PDU cords, then network/fiber/management cables. Coiling and tagging happens as cables come out, not in a pile by the rack.
- Slide the server out, rails last. Remove server, then rails and blanking panels. Record the final empty-U state for the rack map.
A decommission ticket note that closes cleanly
Decomm: web03 (asset TAG-88412, SN 9X4ZK72, rack C12 U18-U19).
Auth: change record CHG-2291, approved by change board 2026-10-15.
Out of production: removed from LB pool 13:40, DNS retired 13:45,
monitoring silenced 13:50 (verified no health checks since 13:55).
Data destruction: NVMe secure erase via vendor tool, cert #DE-5581
attached; verified 4/4 drives erased 14:30.
Shutdown: graceful, iDRAC confirms full power-off 14:32.
Cables: power first (2x PDU C12-A), then 2x 25G DAC + iDRAC; all labeled,
far ends tagged at patch panel PP-12-04/05.
Hardware: rails removed, blanks installed; server to recycling,
carrier tracking TRK-9918273645. IPs 10.4.12.41-42 released, DNS retired.
The mistakes that make decommissions haunt you
- Pulling hardware before the wipe is documented. Drives without a destruction certificate are an audit finding with a serial number.
- No asset ID recorded before removal. "Rack C12, the one on top" is not an asset record. Serials and asset tags go in the ticket before the server moves.
- IPs and DNS never released. Six months later someone assigns a "free" IP that is still answering on a network no one monitors.
- Monitoring never silenced. The dead host pages the on-call all night and everyone learns to ignore the page.
- Cables unlabeled at both ends. An unlabeled cable at the patch panel becomes somebody else's mystery fault next month.
- No destination on the record. If nobody wrote down where the server went, the asset register keeps depreciating a ghost.
See RackReady Free sample Ticket note examples
Support: support@hasherventures.com
Free tool: turn your decomm checks into a structured ticket note with the RackReady Ticket Builder.