A server decommissioning process is a low hanging fruit

By ITIL® from Experience©

Decommissioning or the retirement1 a server is not always easy. Often they are poorly documented or the documentation is out-of-date as it was not maintained throughout its life. Many organizations are scared to turn off an old server if the author of the solution is not there to assess the impact.

Turning off a server is like renovating an old house. Replacing the bathroom’s floor covering might end up being a plumbing project. For example, once the old floor covering is removed, it is discovered that water seeped through the underlay and it needs to be changed. Now that the pipes are visible they should be changed to be brought up to today's building code or standards. The same domino effect can happen when turning off a server. However, the cause and effect might not be immediately obvious. For example, an old server was taken off line which stopped one of the corporate application’s data from being updated – which only gets noticed during the month-end process. Tracing the cause to the script that didn’t run to that old server is not obvious without intimate knowledge of the configuration or at least some detective effort.

The main advantage of a server decommissioning process is that it simplifies the environment. Other benefits include:

  • Reduced vulnerability from old software
  • Reduced maintenance and license costs
  • Lower facilities costs (e.g. electricity)
  • Less effort to resolve incidents
  • Faster ramp up of new employees

It also improves:

  • Resolution time since less complexity makes it easier to support
  • Availability
  • Productivity of staff since less time is spent “figuring” things out
  • Accuracy of the I.T. Asset Management (ITAM) records

At the onset the server decommissioning process2 could simply be to route the Request For Change (RFC) to each of the operational groups (including the Service Desk) to see if they have “anything” related to this request that should also be decommissioned34, (e.g. documents, DNS entries, databases, hardware, Active Directory entries like user/service accounts or special group policies). Other non technical aspects should also be considered like: the financial disposition of the asset, the retention of the data to comply with information management policies or the physical destruction of the asset due to privacy concerns.

As the process matures, specific server decommissioning processes may be created for the retirement of an application server, a database server, printer server, etc. All these specific decommissioning processes are excellent candidates for a standard change.

Building a business case to justify the implementation of a retirement process can be simple. The process will be used as many times as servers are life-cycled. In addition, the "Timely cancellation or changes to maintenance contracts for hardware and software when components are disposed or decommissioned" can lead to significant savings.5


From Around the Web:

Implementation > Process

1. Definition of Retire: Permanent removal of an IT service, or other configuration item, from the live environment. Being retired is a stage in the life-cycle of many configuration items. Source: Best Management Practice portfolio: common glossary of terms and definitions. Version 1, October 2012
2. Section 3.7.2 of the 2011 Edition of Service Design mentions the need to archive information on the retired service in a knowledge base in case it needs to be reactivated (p.55).
3. A small section titled "Information on the requirements for retiring services" was added in the 2011 Edition of ITIL's v3 Service Design. Page 47, provides additional guidance.
4. Guidance on what to look for can be found in ITIL® Service Transition (v3, 2007 Edition) Section Perform transfer, deployment and retirement where on page 108 it discusses Decommissioning and service retirement.


Copyright 2013-2015 - ITIL® from Experience - D.Matte

Google Search