I've seen a broad range of hardware decommissioning (decomm) processes in my years as a sysadmin. It can be as simple as an email with a dire warning about a soon-to-be decommissioned system all the way up to a multi-layered, multi-month, multi-approver process that makes government red tape seem like a pale pink by comparison.
The process in the last two companies I worked in, decommissioning was a 30-day process that started with notifications, a so-called "Scream" test, and a final shutdown, unracking, and palletizing for disposal. I love the term "Scream" test. This part of the process involves unplugging the system from the network for two weeks to see if anyone screams about a lost service. It's effective and I've had my share of opportunities to reverse a decomm for last-minute file recovery and then to restart the process again.
[ A free course for you: Virtualization and Infrastructure Migration Technical Overview. ]
Even small to medium-sized companies have some sort of governance surrounding server decommissioning. They might not call it decommissioning but the process usually goes something like the following:
- Send out a notification or multiple notifications of system end-of-life to stakeholders
- Make complete backups of the entire system and its data
- Unplug the system from the network but leave the system running (2-week Scream test)
- Shutdown and unplug from power but leave the system racked (2-week incubation period)
- Unracking and palletizing or in some cases recommissioning
I personally loved the decomm process. There's something fulfilling about it. I liked spending time in the data center, DBANning disks, unplugging systems, and filling out unracking requests. I know it's not for everyone but I liked it. I don't get to handle those tasks anymore either directly or indirectly, which is why I'm curious about your process.