Server Decommissioning Checklist: What Gets Missed

Decommissioning gets treated as the easy end of a project and it is where obligations get missed. A server leaving the building carries data, licences and asset records with it, and unpicking that afterwards is considerably harder than doing it in order.

Before anything is powered off

Confirm nothing depends on it. The usual surprises are scheduled tasks, scripts on other machines pointing at it, DNS entries, certificates, licence servers and monitoring. A machine that appears idle may be doing something once a month.

A useful check: leave it powered on but disconnected from the network for a period, and see what breaks. That surfaces dependencies nobody documented.

Capture the configuration. RAID controller settings, network configuration, management controller settings and credentials, firmware versions, and licence keys. Some of this is difficult to reconstruct and occasionally needed later — particularly if data has to be read back from the drives.

Verify the data is somewhere else, and verify by restoring. A backup that exists is not the same as a backup that restores, and this is the last moment the original is available to check against. Our backup guide covers what typically goes wrong.

Retention obligations

Worth establishing before rather than after, because it changes what happens to the drives.

Some data carries a legal or regulatory retention period, and some carries a legal hold that overrides normal disposal entirely. Both apply to the data rather than to the hardware, so decommissioning a server does not end the obligation.

If data must be retained, it needs to be somewhere accessible for the required period, in a form that can actually be read. That last part matters more than it sounds — retained data in a format nothing can open satisfies nobody. For long archives, our tape guide covers the migration problem.

Sanitisation

The obligation people are most likely to be judged on.

Every data-bearing component has to be handled, and that includes more than the obvious drives. Boot media, cache modules with persistent storage, and management controllers holding credentials and configuration all matter.

The method depends on where the media is going. Redeployed internally, sold or recycled, and failed-and-unreadable each call for a different approach, and overwriting is not reliable on flash. Our sanitisation guide covers the detail.

Two points specific to decommissioning.

Do it before the hardware leaves. Once equipment is on a pallet heading to a recycler, you are relying on someone else’s process. Anything sensitive should be sanitised while it is still yours.

Record it. Serial number, method, date, who did it. In a regulated environment, work you cannot demonstrate will be treated as work that did not happen.

Licences and support

Frequently overlooked and occasionally worth real money.

Software licences. Some are tied to hardware and some are transferable. Where they transfer, they can be reused on the replacement rather than repurchased.

Management controller licences. Tied to the system, and relevant to whoever receives the hardware — see our remote management guide.

Support contracts. Cancel or transfer them. Paying support on decommissioned hardware is a surprisingly common and entirely avoidable cost.

Vendor account records. Some platforms tie devices to a customer account, which affects the next owner’s support eligibility.

Asset records

Update them at decommissioning rather than in a later audit.

An asset register that still lists disposed equipment is worse than one with gaps, because it produces audit findings and wasted time looking for machines that no longer exist.

Record what happened to each item: disposed, sold, redeployed internally, or held as a spare. Include the serial number and the date, and attach the sanitisation record to the same entry so the two are not separated.

This is also the moment to remove or update the physical asset tag, particularly on anything being sold — a tag with your organisation’s name and asset number on equipment that has left your control is a small information leak.

Keeping some of it

Not everything decommissioned should leave.

If you are still running similar hardware, decommissioned equipment is the cheapest spares source available. Drives, power supplies, memory and fans from a retired machine are known-compatible with its surviving siblings.

This matters most on end-of-life platforms where the manufacturer no longer supplies parts and the market is thinning. A retired server is frequently worth more as a parts source than as a sale.

If you keep it, sanitise the drives first and label the unit clearly so nobody redeploys it by accident.

Physical removal

Finally, the practical part.

Remove power cables, then data cables, labelling as you go if anything similar remains in the rack. Fit blanking panels in the vacated rack units — an open U is an airflow path that raises inlet temperature for everything around it.

Update rack documentation and power records, since removing equipment changes the circuit load and may free capacity you had written off.

Common questions

If decommissioned hardware is compatible with equipment you still run, keep it as spares rather than disposing of it.