How to ensure that applications and servers are decommissioned

By ITIL® from Experience©

Having a decommissioning process does not guarantee that it gets done. People may not completely retire applications or servers even when the benefits to do so are compelling (See A server decommissioning process is a low hanging fruit).

Triggers must exist to initiate the removal process. Here are some ideas to ensure that applications and servers actually get archived and turned off.

Make it part of every new initiative’s business case. In other words, cost it up front.
Include decommissioning as a requirement of new technology purchase’s Request For Proposal (RFP). Select suppliers that have experience, methods, processes and services available to help organizations migrate to their technology and clean up the old.
Add "complete" decommissioning as a success criteria of every project. Makes sure that it gets included in the project budget, plan, schedule and that resources are allocated to the task. At minimum, projects should not be closed until the clean-up has been done.
Embed reminders throughout the Project Management process/framework and templates (e.g. Project Charter, Work Breakdown Structure (WBS), budget, Resource Plan, as a Gate approval criteria).
Make the Decommissioning Plan a mandatory deliverable for every Project, Release and Request For Change (RFC).
Add an annual/quarterly performance objective to each IT group and their Manager that they have to reduce technology or Configuration Items (CI) count by x%.
Get senior management to authorize requests for every additional server. Justification such as redundancy, capacity and load balancing should be provided. However, the answer to the following must be provided: "What is it replacing?" (See What does it mean to have CIO and management support).
Add a task at the end of the Change Management process to verify that the decommissioning actually took place. (When, as a fail-safe, the old server is turned off 30 days after the commissioning of its replacement a new RFC should be logged to ensure that it is turned off).
Run a quarterly report on the CMDB to identify:
- The 100 oldest CIs
- All CIs that did not get an incident, RFC, problem or service request logged against them in the last two years to confirm that they are still in production.
Conduct an application portfolio review when planning server life cycles to identify applications to retire. Take the opportunity to sunset some apps instead of simply "lifting and moving" them to new servers.

Even when the organization is process oriented multiple triggers should be used to ensure that a process gets initiated. We recognize that various groups’ buy-in is required to implement some of these ideas.

Unless you're in the disposal or salvage business most people don't like to clean old things. To make decommissioning part of your business it needs to become pervasive in people’s daily reality. Reminders through various means and triggers are required to make it a way of life and part of the culture. Thus, implementing a few of those ideas and being resolved at asking questions like the following go a long way towards ensures that applications and servers are decommissioned.

Where are the discontinuation activities in this plan?
Has this been discontinued?
What are we doing with the old stuff?
This project is not complete since it has not discontinued the old

"If you sweep things under the carpet, the carpet eventually gets too lumpy to walk on." Unknown

More Quotes

Related: