An introduction to ITIL (part 3/5) – Service Transition

Hi all ! In this article I’ll continue the résumé I wrote as a preparation for my ITIL Foundation exam.

Catching up

In the previous post I described the service design stage. The service design stage key aspects were :

  • the identification and description of all services within a company and their proper catalog
  • the establishment of service levels, availability, capacity and security
  • proper supplier management
  • choose of IT service support tools

In the  ITIL service lifecycle, the service transition comes immediately after the service design. Just as a reminder, the ITIL service lifecycle is comprised of the  following stages:

  • Service Strategy
  • Service Design
  • Service Transition (you are here !)
  • Service Operation
  • Continual service improvement

Service Transition

The ITIL service transition stage is the point in the ITIL lifecycle where services are moved into operational use.

Purpose & Objectives

The purpose of this stage is to ensure that new,  modified or retired services meet expectations of business created on previous stages.To meet the business expectations this stage should properly manage :

  1. how new or modified services are deployed and how old services are retired
  2. the risk associated with actions on step 1
  3. the business expectations on the performance of the actions in step 1

In addition,  the service transition stage is also concerned in providing accurate knowledge and information on services and services assets.

Scope & value to the business

In addition to the management activities identified above, the service transition should also consider the transfer of services between service providers. Among the several benefits of proper service transition management, I would point out the following characteristics :

  • better estimation of costs, resource requirements and risks
  • reduced delays from unexpected clashes and dependencies
  • reduced effort spent on managing pilot environments

As a consequence of better management, the stakeholders confidence on a process that will seamlessly add, remove  or re-purpose current services will be higher.

Key principles

ITIL defines several key principles for service transition from which I chose the following 5:

  1. align the service transition plans with the business needs
  2. provide systems for knowledge transfer and business support
  3. plan release packages and anticipate and manage course corrections
  4. establish and maintain relationship with stakeholders and insure and early involvement in the lifecycle
  5. proactively improve the quality during service transition


Transition planning and support

The purpose of the transition planning and support process is to provide overall planning for service transitions and to coordinate the resources that they require.

The inputs and outputs of this process can be summarized below:


Change Management

The purpose of the change management process is to minimize the impacts of change. To minimize the impacts of change, the change management process must ensure that all changes are recorded, evaluated and that authorized changes are prioritized, planned, tested, implemented, documented and reviewed in a controlled manner.

The scope of change management encompasses 4 types of changes:

  • Changes to physical assets such as servers or networks
  • Changes to virtual assets such as virtual servers or virtual storage
  • Changes to agreements or contracts
  • Changes to certain aspects of service design

Nevertheless, each organization should define their own scope for the change management process, excluding business changes such as department reorganizations and operational changes such as a printer repair.

There are 3 major types of change requests:


A standard change is characterized as a pre-authorized change that is low risk, relatively common and follows a procedure or work instruction. These are changes such as password resets. RFCs are not required to implement a standard change process because they are typically logged and tracked using service requests.

An emergency is change that must be put in place as soon as possible. These are changes such as emergency security patches or major incidents. Emergency changes should also follow specific guiding procedures.

A normal change is by definition a change that fits neither of the types above, but that follows the defined steps of the change management process.

The description of a change type, can further be complemented by describing a normal change as major, significant or minor depending on the level of cost and risk involved.

The following definitions are key concepts of the change management process :



To assist the change management process in the assessment, prioritization and scheduling of changes, two groups of people should be defined: those belonging to the Change Advisory Board (CAB), and those belonging to the Emergency  Change  Advisory Board(ECAB).There can be multiple CABs depending on the size of the organization. CAB just plays an advisory role and is often the change authority for one or more categories. The ECAB is typically a smaller board with authority to make emergency decisions.

Remediation planning is also an important part of change management. Every change implementation plan should include milestones for remediation. This would ensure that even if the change is not reversible, we would have an alternative approach ready to use.

The normal change process flow can be depicted in the picture below. It all starts with the “Plan Change” .


The easiest way to remember the major aspects to be considered before approval of any change are the 7rs of change management.  This information should be recorded in the RFCs. The 7r’s can be represented by the picture below:


The 7 R’s are:

  1. Who RAISED the change?
  2. What is the REASON for the change?
  3. What is the RETURN required?
  4. What are the RISKS?
  5. What RESOURCES are required to deliver?
  6. Who will be RESPONSIBLE for build, test and implementation?
  7. What is the RELATIONSHIP with other changes?

To finalize, the inputs and outputs of this process are resumed on the diagram below:


Service Asset and Configuration

The purpose of this process is to ensure that assets are identified, controlled, managed, protected throughout their lifecycle. To different items ITIL refers to are :

  • Service Assets – Resource or capabilities that contribute to the delivery of a service
  • Configuration Items (CI) – any service asset that needs to be managed in order to deliver a service
  • Configuration Records (CR) – set of attributes and relationships of a CI, stored in a CMDB and managed with a CMS.
  • Service Knowledge Management Systems (SKMS) – Sets of tools and databases used to manage knowledge data.

The two major roles involved on service asset and configuration management are the Service Asset Manager and the Configuration Manager.

The inputs and outputs of this process can be summarized below:


Release & Deployment Management

The purpose of the release and deployment management process is to plan, schedule and control the build test and deployment of releases to deliver new functionalities. This process encompasses the systems and functions to package, build and test as well as the deployment of a release into live use.


The following definitions are key concepts of the release and deployment management process :


Missing from the basic definitions above are the concepts of release identification,  release types and release deployment methods.

The release identification refers to the status of a release according to its current environment. The environments in which a release can be categorized are : Development, Test, Live, Archive.

The release types classification changes accordingly to the number of changes to be included in one release. These types can be :

  • Delta Release– just a few changes
  • Full Release – when all parts of a  program are released
  • Package Release – a group of interdependent software released under the same package

There are 3 major release deployment methods:

  • Big Bang vs Phased Approach – on a big bang approach all components are deployed in one go, whereas on the phased approach each component has its own deployement schedule
  • Push vs Pull – if you have a smarphone you already know the difference. Push is for example when google or apple notifies you that an upgrade in your cellphone is going to be installed OTA without you asking for it. Pull is when for example you access the appstore or the google marketplace and you download the software you want.
  • Automated vs Manual

The 4 main activities to be carried out along this process are :

  1. Release and deployment planning  – plans for creating and deploying the release.
  2. Release build and test – baseline release package and check into DML
  3. Deployment – release in DML is deployed to live environment
  4. Review and close – this includes the capture of experience and feedback and the review of performance targets and achievements

The major role in this process is the Release and Deployment Manager who is responsible for planning, design, build, configuration and testing of all software and hardware and to create the release package for the designated service.

The inputs and outputs of this process can be summarized below:


Service Validation & Testing

This process ensures that new or changed services are “fit for purpose”(they will deliver the agreed utility) and “fit for use” (they will deliver the agreed warranty) .

The inputs and outputs of this process can be summarized below:


Change evaluation

This process ensures the definition of the performance of a service change. The actual performance of a service change should be measured against the predicted performance.

By defining the performance of service changes, this process sets the stakeholders expectation correctly and provides good quality outputs so that change management can expedite decisions regarding whether a service change should be authorized or not.

The inputs and outputs of this process can be summarized below:


Knowledge Management

A successful transition depends on the information available and knowledge of users, service desk , support and supplier. The purpose of knowledge management is to improve decision making by ensuring that reliable and secure knowledge, information and data are available. Better knowledge management will also enable the service provider to be more efficient and improve quality of service while reducing costs and increasing satisfaction.


The following definitions are key concepts of the knowledge management process :


Another important definition is the definition of Service Knowledge Management System(SKMS) as a  set of tools and database that is used to manage knowledge, Information and Data. The SKMS includes the CMS and the CMDB.

The inputs and outputs of this process can be summarized below:


Technology Considerations

The tools to support the service transition stage should be

  • configuration management systems and tools  
  • tools for software distribution and installation
  • version control tools
  • build and release tools
  • discovery and audit tools

Final thoughts

All the stages of the service lifecycle are important, but the transition stage is for me is one of the most relevant, because it encompasses the change , deploy and knowledge management which are processes that will either make or break your project implementation. Hope you enjoyed this long reading as much as I enjoyed writing IT.


[1] ITIL Home; The Official ITIL Website ;

[2] OSIATIS ;ITIL –  IT Service Management ;

[3] CISCO ; Change Management Best Practices ;

[4] ITIL Service Management A practical guide to ITIL;7rs of change Management ;