Server Decommissioning Done Properly: Order, Data and Value
Decommissioning is where data leaks and value is lost, usually because it is treated as disposal rather than a process. This covers doing it properly.
Before anything is unplugged
Four things to establish, and the first one catches people out regularly.
What actually depends on this system? Machines are frequently doing something nobody remembers β a scheduled job, a licence server, a DNS entry, an integration. Check what connects to it before assuming it is idle. Our undocumented estate guide covers finding dependencies.
Is the data migrated and verified? Not copied. Verified, with counts and permissions checked, and applications tested against the new location. Our migration guide covers this.
Are there retention obligations? Some data must be kept for a defined period regardless of whether the system stays. Decommissioning the hardware does not end the obligation.
Is there a licence tied to this hardware? Some licences are bound to a machine and can be reclaimed or transferred, and some are simply lost when the machine goes.
Power it down and wait
The single most useful step, and it costs only time.
Shut the machine down and leave it racked and cabled for a period β a few weeks is typical. If something breaks that depended on it, you can power it back on in minutes rather than rebuilding it.
Machines removed and wiped the same day have taken down services nobody connected to them until the failure. Leaving it powered off in place is free insurance.
Data sanitisation
Every drive, every SSD, every device with onboard storage. This includes things people forget: switches with configuration, printers with stored jobs, management controllers with credentials and logs.
Three approaches, and the right one depends on the drive and the requirement.
Cryptographic erase on self-encrypting drives, which deletes the key rather than overwriting. Fast and thorough. Our SED guide covers which drives support it.
Secure erase or overwrite for drives without encryption.
Physical destruction where the requirement demands it or the drive has failed and cannot be erased.
Whichever you use, keep the certificates. Our sanitisation guide covers what each method proves.
And note the awkward case: a failed drive cannot be erased. It still holds data, and it needs destroying rather than returning or discarding.
Record what comes out
Before the machine leaves, record serials, part numbers, configuration and where each item goes.
Two reasons. Asset records need closing, and an asset marked as live that physically left two years ago is a gap in every audit since. And parts have value, which the next section covers β you cannot quote hardware you have not listed.
Our acceptance testing guide covers the equivalent at the other end of the lifecycle.
Decide what is a spare and what is surplus
The distinction that decides value.
A spare is a part for a platform you still run, held deliberately, tested, and recorded. Keeping it saves you a purchase and a lead time.
Surplus is everything else. Keeping surplus "in case" is how storerooms fill with equipment that loses value every month and is eventually scrapped.
Be decisive. Our spares guide covers sizing a holding, and our selling guide covers what surplus is worth and how to prepare it.
The last step: close the loop
Four things people forget after the hardware is gone.
Remove it from monitoring, so nobody chases alerts for a machine that no longer exists.
Remove DNS, DHCP and firewall entries.
Cancel support contracts for hardware you no longer own. This one has a direct cost attached, and it is missed constantly.
Update documentation, including rack diagrams and network documentation. Our documentation guide covers this.
Frequently asked questions
What should I do before decommissioning a server?
Establish what depends on it, verify the data migration rather than assuming it, check retention obligations, and check whether licences are tied to the hardware.
How long should I leave a decommissioned machine powered off?
A few weeks, racked and cabled. If something breaks that depended on it, you can power it back on in minutes rather than rebuilding it. Machines removed the same day have taken down services nobody had connected to them.
What holds data besides the drives?
Switches with configuration, printers with stored jobs, and management controllers with credentials and logs. Anything with onboard storage needs sanitising.
How do I erase a drive that has failed?
You generally cannot, which is the awkward case. A failed drive still holds data, so it needs physical destruction rather than returning or discarding.
Should I keep decommissioned hardware as spares?
Only where it is a part for a platform you still run, held deliberately and tested. Everything else is surplus, and keeping surplus in case is how storerooms fill with equipment that loses value monthly and gets scrapped.
What gets forgotten after the hardware leaves?
Removing it from monitoring, clearing DNS, DHCP and firewall entries, cancelling support contracts for hardware you no longer own, and updating rack and network documentation.
Send us the list of what is coming out and we will tell you what is worth holding as spares and what is worth selling.
