Service Transition in ITIL

Isaac Asimov: “Life is pleasant. Death is peaceful. It’s the transition that’s troublesome.“

Service Transition is the stage IT Service Providers are usually most afraid of. Transition is known to be the source of most service downtimes.

If Operation is living in peace, Transition is like going to war. When we add, change or retire a service, we have to carefully plan, build, test, evaluate and deploy the service in a most controlled manner. And if the enemy shows unexpected resistance, we will retreat gracefully following our backout (rollback) plan.

Purpose and Scope of Service Transition

The purpose, and therefore the scope of Service Transition is to assure that the new or modified services conform to business requirements, and that those services being removed from the service catalog are retired in a controlled manner.


Transition Objectives

The main objectives of Transition are to:

  • Efficiently and effectively plan and manage service changes: what is the cost, when should we do it, what infrastructure will be affected, what other services will be influenced?
  • Manage change risks: What could go wrong? What are the odds? What will we do if it happens? Here we make sure that we address all possible failures and their adverse impacts on business.
  • Release planned changes: We actually implement changes in operative infrastructure. Is the release tested properly? What resources will be utilized for this? Can we implement several changes at the same time? What can be released from the central location, and what releases have to be implemented on site?
  • Manage expectations on new or changed services: We validate, test and evaluate changes.
  • Manage accurate knowledge and info on changed services and assets: When we change something, is the knowledge about this change entered into the Configuration Management Database (CMDB) or Configuration Management System? All other stakeholders need to have accurate info about the new infrastructure state in order to be able to provide the service and support it.

What I see as the main benefit of Service Transition is that we will be more confident that new/changed services will be delivered without unexpectedly affecting other services or stakeholders.

Service Transition Processes

What are the processes defined in Service Transition?

  • Transition Planning and Support – Since Transition is so important, ITIL defines the separate process in order to manage/control changes and releases.
  • Change Management – The key Transition process, and one of the key ITIL processes. Change is usually the main cause of a service disruption, so we want as much control over change as possible. In Change Management we ensure that all changes are provided with minimum downtime.
  • Service Asset & Configuration Management – Previously, it was Configuration Management and dealt with the Configuration Management Database (CMDB). This was a bit too technical, and used to confuse the business people in ITIL. In fact, Conf. Management is about what we have, where it is and how it works.
  • Release and Deployment Management – It was just Release Management in V3, and in my opinion it was the most difficult process to shortly describe to someone out of IT Service Management. If it was called Deployment Management from the beginning, it would be much easier to grasp.  In a nutshell, RDM deals with what Change Management decided to do, with the resources and timeframes available.
  • Service Validation and Testing – This ensures that the service will deliver expected outcomes, and that it is “fit for purpose” and “fit for use.”
  • Change Evaluation was Evaluation in V3, and Change was added in 2011. It is a process that deals with evaluation of change. It is implemented to identify all predicted and unpredicted change effects.
  • Knowledge Management was hyped heavily in the ‘90s! Do you remember the huge amount of resources put into KM back then? Do you know any self-respecting company that has a Knowledge Manager post today? This is my favorite example of adding unnecessary ballast to key ITSM processes in ITIL.

Yesterday we had a large change implemented at the infrastructure of one of our clients. We prepared well; having the service catalog, CMKS and stuff, we knew what and where could go wrong. Everything tested in development and staging development, the backout plan was ready, the maintenance window respected. But, I could see that our legacy before ITIL experience made a mark: all engineers had the “going to war” energy and look in their eyes. Everything went well.

This is one important point where I feel we really benefited from implemented ITIL in synergy with ISO/IEC 20000 service management. The happiness and satisfaction of doing a good job of transition, people being able to return to their families, and no downtime or resulting incidents made us feel proud and happy. It was a real teambuilding experience at no additional cost.

We brought new value to our customer’s business with all bases covered. Isn’t that what it’s all about?

Download free previews of our Transition Planning and Support Process templates to get an overview of activities, roles, and responsibilities.