The art of the server decommission/recycle process

Many of the banks and the enteprise organizations are going through a consolidate exercise; whether it’s upgrading to windows 2003, deploying VMWare and virtualizing the infrastructure, or even consolidating data center space. With this comes the art of the decommission. Of taking the servers that are no longer required and removing them in a way that causes the least disruption in a co-ordinated and time efficient way, I need to get rid of the tin, but I need to backup the data first, depreciate any asset value left, maybe retain any parts? Reclaim the space and power in my data center management tools etc.

The challenges with this can be frustrating, it requires effective communication and with all the planning in the world it is easy to have an ‘unplanned outage’, when someone agreed to a server being decommissioned or removed but changed their mind during or after the event. I’ve experienced, and heard many a story, “Decommission server 47589? We didn’t think you meant now! We need to migrate…. We need another…”

To avoid these kind of things there needs to be an agreed way of decommissioning a server, a set work flow, and quite possibly a team dedicated to this task - granted you might not allocate people to decommissioning forever, but for say a few months to get those servers out the door, in terms of power and data center space, it’s worth it, not to mention in doing so granting new projects the data center space they need.

This process would probably be based around your help desk system, using the Change process to notify the various teams, but during the actual act of switching off and erasing the box, consider that a quick phone call/email to your support team, to the operators helps keep everyone involved in case things go wrong.