General discussion

  • Creator
  • #2224844

    ITIL – Change & Release Management


    by vawns ·

    Hi All,

    I?m looking at making some improvements in my current Change Management process and part of this will review the relationship with Release Management and specifically what constitutes a Change versus what constitutes a Release.

    I would love to know how other organisations make the differentiation, how do you decide what?s a change and what?s a release and how do you manage the relationship between the two.

    Any help or feedback would be gratefully received 🙂

    Many thanks & best regards,


All Comments

  • Author
    • #2635285

      ITIL Change <=> Release Mngmnt

      by rob mekel ·

      In reply to ITIL – Change & Release Management

      Any Change made will result in a change in the CMDB. There for will effect your release mngmnt

      As I read your question it comes to mind that the issue you are referring to is more related to Update versus Upgrade or Patch versus Release. As you say “what constitutes a Change versus what constitutes a Release”

      As Changemngmnt has to do with the way you choze to get the changes trough to your organisation / to put them in effect or NOT.
      As Releasemngmnt holds the results of what is the current state. The desicion made on whether or not to go through with a certain change is made in the Changemngmnt proces not in/by the Releasemngmnt proces.

      Changemngmnt therefor is leading Releasemngmnt is the follower even if Releasemngmnt has an issue with certain soft- or hardware it has to follow the route of ITIL to get a OK from Changemngmnt to put it into effect.


      • #2513553

        More control and less ITIL?

        by miquel gantzer ·

        In reply to ITIL Change <=> Release Mngmnt

        Rob’s comments make a lot of sense, although the initial post probably suggests that the processes in place are not as ITILized as they could. Change Management is all about assessing and deciding which Changes will be implemented in the managed systems. Release management might focus on how these changes are going to be grouped (if needed), published, moved into the production environment, or whatever is the right approach depending on the type of system being managed.

        What was probably missing in the initial scenario was some type of CMDB. The Configuration Management Database might allow you to record what changes were suggested, why, when, by whom, and whether they were approved or not (even why that decision was taken). And then in which release (as in when) they were made available. Depending on the complexity of the system maintained, this can be something as easy as a Spreadsheet, or something as ‘terrifying’ as a commercial CMDB from some vendor of ITIL-flavoured suites.

      • #2776425

        ITIL Process Assessment Survey

        by itsm consultant ·

        In reply to ITIL Change <=> Release Mngmnt

        Get practical information on the effectiveness of your ITIL processes and customized recommendations for improvements.

        Click Here to take survey

    • #2665390

      Relationship between Change and Release Management

      by itsm consultant ·

      In reply to ITIL – Change & Release Management

      It looks like you’ve already gotten some good advice from a few people to get you started.

      It is theoretically correct that all changes should result in a update to the CMDB (either to the CI itself or to the attribute of the CI). This depends largely on the level of granularity (detail)captured in the CMDB.

      Initially, the CMDB is more like than not, to be rather limited in scope and detail. Thus, most changes made will be to the attributes of CIs rather than to the CI itself.

      An example: A change to a database table will probably be captured as a modification to the Server, Application or System rather than to the database instance itself.

      Over time, it may become necessary to promote the database instance to CI status and begin to record changes against it.

      Further, not all changes result in Releases. The scope of Release Management is very specific and is limited to modifications to Software (can also include related Hardware documentation necessary to effect SW change) components.

      The scope of Change Management is much broader. Its includes all changes to which may potentially have an impact on the IT Service. This can include changes from batch job scheduling, access priveleges, performance testing and hardware moves to VPN configuration changes and beyond.

      In my experience, it is very important to clearly establish the differences between these processes from the beginning. Failure to do so is likely to cause confusion and duplication of effort.

      Additionally, it is also important to distinguish the differences between Release Management and Project Management.

      Just as not all changes result in releases, not all projects result in release. Release Management should establish the policy for moving Software (and related HW and documentation) from development to production. This includes creating the Release Plan which defines the requirements for testing, acceptance, training, support and deployment.

      Good luck. Please feel free to contact me directly with any other questions you have.

      Also, check out my blog at:

      • #2972309

        About change and release management

        by adydashora ·

        In reply to Relationship between Change and Release Management

        Today I got information that, now a days, organizations are breaking off the change and release management. I had an impression that, change and release management are implemented together.

        Please help me to understand the processes of change and release management.

      • #2820875

        Should all change mean a change in CMDB?

        by bamitabh ·

        In reply to Relationship between Change and Release Management

        I have a lingering doubt on whether all ‘changes’ formalized through RFCs imply necessarily a change to the CI or its attributes.Suppose a change affets some not-so-important attribute of a CI, which is not tracked by CMDB. Should that change be formalized as a change and an RFC be raised for that? In the context of ITIL how relevant this change is? Should that be recorded as a change? The IT auditors whould vehemently argue that this change should be recorded and formalized through an RFC.As an application analyst I would disagree. Any opininion or debate on this may be interesting.
        Amit Biswas

Viewing 1 reply thread