What is ITIL 4 release management? Release vs deployment, roles, KPIs

Definition

ITIL 4 release management is the service management practice whose purpose is to make new and changed services and features available for use. Release management decides what users get access to and when, while deployment management moves components into the live environment. Release management is one of the 17 service management practices among ITIL 4’s 34 practices, alongside 14 general management and 3 technical management practices.

How often do software releases fail?

Failure rates in software release management run from 5% to 40%, depending on how often an organization ships.

The DevOps Research and Assessment (DORA) program at Google Cloud measures this annually, and the 2024 Accelerate State of DevOps Report sorts respondents into four delivery cohorts.

40%

change fail rate in the lowest-frequency cohort, deploying once per month to once every six months

change fail rate in the highest-frequency cohort, deploying on demand, multiple times per day

25%

of respondents sit in that lowest-frequency, highest-failure cohort

Performance level	Deployment frequency	Change fail rate	Share of respondents
Elite	On demand (multiple deploys per day)	5%	19% (18-20%)
High	Between once per day and once per week	20%	22% (21-23%)
Medium	Between once per week and once per month	10%	35% (33-36%)
Low	Between once per month and once every six months	40%	25% (23-26%)

At the extremes, the lowest-frequency cohort, deploying once per month to once every six months, has a 40% change fail rate, while the highest-frequency cohort, deploying on demand, has 5%. That contradicts a common governance assumption, that releasing less often is safer.

The middle cohorts break the pattern, because Medium sits at 10%, below High at 20%. The report also presents all its ranges as 89% uncertainty intervals, so the data does not prove that faster is always safer. It does place the worst change fail rate with the least frequent deployers.

What is the difference between release management and deployment management?

Deployment management moves components into a target environment. Release management decides which users get access to what, and when. ITIL 4 places the two in different practice categories.

Release management is one of the 17 service management practices, while deployment management is one of the three technical management practices, alongside infrastructure and platform management and software development and management. Both ITSM.tools and the IT Process Wiki list the practices this way.

ITIL v3 had a single Release and Deployment Management process inside Service Transition. ITIL 4 draws the boundary at the point where users gain access, separate from the point where code lands. The activities existed before; ITIL 4 changed how they are grouped and who owns them.

The AXELOS ITIL 4 practice guide defines a release as a version of a service or any other configuration item, or a collection of configuration items, that is made available for use. It then warns that a release unit may be different from a deployment unit, because releases are user-facing. Testing sits outside both practices, in service validation and testing.

AXELOS describes how the two practices can be combined or separated. When they are combined, components become available the moment they reach the operational environment, which is typical for hardware and large monolithic software. When they are separated, a version is deployed first and released later. Without continuous delivery, organizations are more likely to combine release activities with deployment.

	Release management	Deployment management	Change enablement
Question it answers	Who gets the new version, when, and on what terms?	How do components get into the target environment?	Should this change be authorized, and at what risk?
ITIL 4 practice category	Service management practice, 1 of 17	Technical management practice, 1 of 3	Service management practice, 1 of 17
Typical owner	Release manager, or the product or service owner	Platform, infrastructure or endpoint team	The change authority for that change type
Core artifacts	Release management model, release units, packaging rules, push and pull conditions, release schedule	Deployment units, target environments, deployment records	Change records, change models, authorization decisions
Unit of work	Release unit, defined by what users receive together	Deployment unit, defined by what is technically moved together	The individual change, defined by what is being altered
It fails when	Users are switched to a new version with no communication, support or way back	Components land in an environment that does not match what was tested	Authorization turns into a scheduling queue with no real risk decision

What is the difference between release management and change management?

Change enablement authorizes a change; release management makes the result available to users.

They answer different questions at different times, which is why a change can be approved and deployed weeks before a single user is switched onto it.

Change and release management are often confused, partly because of naming. ITIL 4 renamed the practice change enablement; “change management” is the ITIL v3 name and still the term most people search for. The new name describes a practice whose job is to let change happen safely.

According to AXELOS, authorization of changes and releases belongs to change enablement. Testing belongs to service validation and testing. Naming, versioning and control of service components belongs to service configuration management, the practice behind the Configuration Management Database (CMDB). Release management is responsible for what users receive and on what terms.

What is a release unit in ITIL 4?

A release unit is, in the AXELOS definition, a pre-defined set of configuration items or parts of configuration items that is the basic size to be included into a release.

It is the practice’s central design decision, because it fixes how much change users absorb at once. Release units are agreed per product in the release management model, together with packaging rules, push and pull conditions, and verification and acceptance criteria.

A badly sized release unit weakens every control that follows, because the model decides whether a release is a small, reversible change of exposure or an event the service desk has to prepare for. No tool makes that decision for the organization, and Matrix42 has no release unit object; its Configuration Packaging is available only with the Digital Workspace Platform.

Evidence from DORA suggests release units should get smaller as artificial intelligence (AI) raises code volume. The 2024 Accelerate State of DevOps Report found an estimated 7.2% reduction in delivery stability for every 25% increase in AI adoption. It named batch size as part of the mechanism, noting that the research has consistently shown that larger changes are slower and more prone to creating instability.

The 2025 State of AI-assisted Software Development report records a partial improvement, because AI adoption is now associated with higher delivery throughput, a shift from the previous year, while it is still associated with more delivery instability. The size of each release unit therefore matters even more as code volume grows.

Does ITIL release management work with DevOps and continuous delivery?

Yes. Because ITIL 4 separates release from deployment, code can reach production at engineering speed while release management controls when users are exposed to it.

Agile release management fits this model, because AXELOS states that new versions of software can be deployed to the live environment before release activities start, and then released to all or some of the users. Deployment can then run at engineering cadence without waiting for a committee, while release management governs exposure.

The DevOps Research and Assessment guidance on streamlining change approval, which measures the alternative, reports that heavyweight external approval processes have a negative impact on software delivery performance. It also reports that no evidence was found to support the hypothesis that a more formal, external review process was associated with lower change fail rates. The stated mechanism matches the performance table, because such processes lead to the release of larger batches less frequently, with a higher impact on production and therefore higher risk.

The release management practice guide names blue/green releases, canary releases and A/B testing under hypothesis testing and experimentation, and quotes Martin Fowler on continuous integration, continuous delivery and continuous deployment. Continuous integration and continuous delivery (CI/CD) determine how fast code reaches an environment; the practice decides who is switched onto it.

The first consequence is that release governance is increasingly built into platforms. The 2025 report found that 90% of organizations have adopted at least one internal platform, and it links a high-quality platform directly to an organization’s ability to get value from AI. Guardrails built into a platform apply to every release; a document discussed in a meeting applies only to the releases someone remembers to bring.

A second consequence is that, for Software as a Service (SaaS), the supplier owns the ship date. AXELOS notes that supplier-managed development and deployment usually introduces constraints, and that an organization may be able to decide whether to include updated components in its services only to a certain extent. Release management still owns what is left, and it is the part users feel: push and pull conditions, communication, and support readiness.

What does a release manager do?

A release manager owns the approaches, models and schedule by which new and changed services reach users.

ITIL 4 names it as the single practice-specific role in release management, then immediately qualifies it: the role is often introduced in organizations where there is a significant volume of releases, especially if they need manual planning and execution. In other organizations the responsibilities may be taken by product or service owners.

Six responsibilities define the role: reviewing and developing release approaches and models, promoting their adoption across the organization, planning complex releases, managing and communicating the release schedule, ensuring alignment with other practices, and continually developing the practice itself. That alignment depends partly on shared data, and Matrix42 runs Release Management, Change Management and Service Configuration Management as separate processes over shared records. Large releases usually arrive through project management, and the handover point is the release itself.

AXELOS assigns the role the competence profile AMCT: administrator, methods and techniques expert, coordinator and communicator, technical expert. Coordination and communication carry particular weight in this role. PeopleCert, the current owner of ITIL, publishes Release Management as a standalone ITIL 4 Practitioner module, separate from Change Enablement.

What are the KPIs for release management?

Release management key performance indicators (KPIs) sit in two tiers: practice-level measures from AXELOS and delivery metrics from DORA.

Tier 1: the AXELOS practice success factors Measures whether your approach to release is working: stakeholder satisfaction with how services are introduced, adoption of the agreed approach, partner and consumer alignment, and audit findings caused by releases.
Tier 2: the DORA delivery metrics Measures what happened to individual release instances: change lead time, deployment frequency, failed deployment recovery time, change fail rate and deployment rework rate.

The first tier is AXELOS’s own, organized around two practice success factors (PSFs). PSF 1 covers establishing and maintaining effective approaches to release. Its metrics are stakeholder satisfaction with the way new and changed services are introduced to users, adoption of the agreed approach across the organization, key partners’ and service consumers’ alignment with release management approaches and models, and audit findings and external compliance issues caused by releases. PSF 2 covers effective release in the context of value streams. Its metrics are stakeholder satisfaction with release instances, the percentage of successful release instances and the number of release errors or failures, and the number and percentage of incidents related to release. Timeliness against the release schedule and release backlog throughput complete the set.

The second tier holds the delivery metrics engineering already reports. As of January 2026 the DORA framework names five of them, one more than the original four, and splits the list above into throughput measures and instability measures. Keeping both tiers legible over time is the job of measurement and reporting.

The two tiers answer different questions, so report them separately: the first shows whether the approach to release is working, the second what happened to individual release instances. Stakeholder satisfaction with how a new service was introduced is as much a relationship management concern as a release one, and a low change fail rate does not show that users were well prepared. When the same defect returns after successive releases, it needs problem management.

Know what is going live, who it reaches, and what it touches

Among release management tools, Matrix42 covers the service management side of a release; it is not a build pipeline.

There is no Definitive Media Library (DML), no code build or test stage, and no named integration with Jenkins, GitLab or Azure DevOps. Release Management and Deployment Management are two separate, individually available processes in the Core and Professional packaging, sitting alongside Change Management, Service Validation and Testing, Service Configuration Management and IT Asset Management on one data model. A release and the practices either side of it share the same records. Matrix42 Enterprise 25.4 is PinkVERIFY-certified by Pink Elephant for Release and Deployment Management, valid until March 3, 2027.

Research In Action ranked Matrix42 first overall at 9.31 in its Vendor Selection Matrix for IT and Enterprise Service Management covering Continental European medium and large enterprises in 2026, ahead of EasyVista at 9.28 and ServiceNow at 9.23. See how release coordination and change enablement share one platform.

Key takeaways

Release and deployment sit in different categories Release management is a service management practice and deployment management a technical management practice, so ITIL 4 governs them separately.
Deployment and release happen at different times Deployment moves components into an environment, and release decides which users are exposed to them, when and on what terms, so a change can be deployed weeks before any user receives it.
The least frequent deployers fail most often In the 2024 Accelerate State of DevOps Report the lowest-frequency cohort ran a 40% change fail rate against 5% for the highest. The middle cohorts break the pattern, with Medium at 10% and High at 20%.
The release unit is the key design decision Release units, packaging rules and push and pull conditions live in the release management model, agreed per product. As AI raises code volume, DORA’s evidence favors smaller units.
Put governance in the release model DORA found no evidence that formal external review lowers change fail rates, and ITIL 4 lets organizations deploy continuously while the release model governs exposure.

Release is the moment users feel the change

A release nobody was told about is not a release. It is an incident with a deployment record.

FAQs

A release policy is an ITIL v3 term. The IT Process Wiki defines it as a set of rules for deploying releases into the live operational environment, defining different approaches depending on the urgency and impact of the release. The phrase does not appear in the AXELOS ITIL 4 release management practice guide. Its ITIL 4 equivalent is the release management model, agreed per product, which sets release units, packaging rules, push and pull conditions, and acceptance criteria.

The Definitive Media Library (DML) is the secure store that holds authorized versions of software media and the licenses that go with them. ITIL v3 introduced the term, and ITIL 4 still refers to it under deployment management, which keeps components in secure locations so they are not modified before deployment. The ITIL 4 release management practice guide does not use it, and naming and versioning of service components belong to service configuration management.

Early life support (ELS) is an ITIL v3 sub-process that resolved operational issues quickly during an initial period after a release was deployed, and removed any remaining errors. The term appears nowhere in the ITIL 4 release management practice guide. ITIL 4 distributes the same work across the service desk, incident management, and service validation and testing, so post-release support is planned with those practices; there is no separate early life support stage.

Push and pull describe who decides when users move to a new version. The AXELOS ITIL 4 release management practice guide describes a push release as one where new components are enabled for users without their specific consent, and a pull release as one where users decide whether to take the new version. A release management model can combine both, offering an opt-in period before a final push date.

Big bang and phased appear in ITIL 4 as deployment approaches under deployment management, while the release management practice guide does not use them for releases. A big bang release makes a new version available to every user at once, and a phased release makes it available to defined groups in sequence. In release management, ITIL 4 expresses the same choice through release units and the push and pull conditions in the release management model.

The organization consuming the service still owns release management, even when it does not control the release date. The AXELOS practice guide notes that supplier-managed development and deployment introduces constraints, and that the organization may be able to decide whether to include updated components in its services only to a certain extent. Ownership moves from deciding when a version ships to deciding how and when users are switched over, informed and supported.

Yes. Because release management is a service management practice and deployment management a technical one, organizations usually give them different owners: a release manager or service owner for release, and platform, infrastructure or endpoint teams for deployment. Under ITIL v3 the two ran as a single Release and Deployment Management process.

Sources

1 AXELOS, “Release management: ITIL 4 Practice Guide,” 2019.axelos.com/resource-hub/practice/release-management-itil-4-practice-guide
2 DORA (DevOps Research and Assessment), Google Cloud, “2024 Accelerate State of DevOps Report,” 2024.dora.dev/research/2024/dora-report
3 DORA (DevOps Research and Assessment), Google Cloud, “State of AI-assisted Software Development 2025,” 2025.dora.dev/research/2025/dora-report
4 DORA (DevOps Research and Assessment), Google Cloud, “Streamlining change approval,” 2025.dora.dev/capabilities/streamlining-change-approval
5 DORA (DevOps Research and Assessment), Google Cloud, “DORA’s software delivery performance metrics,” 2026.dora.dev/guides/dora-metrics
6 ITSM.tools (Sophie Danby), “The 34 ITIL 4 Management Practices,” 2023.itsm.tools/34-itil-4-management-practices
7 IT Process Wiki (IT Process Maps), “ITIL 4,” 2024.wiki.en.it-processmaps.com/index.php/ITIL_4
8 IT Process Wiki (IT Process Maps), “Release and Deployment Management,” 2024.wiki.en.it-processmaps.com/index.php/Release_and_Deployment_Management
9 PeopleCert, “ITIL 4 Practitioner: Release Management,” 2026.peoplecert.org/browse-certifications/it-governance-and-service-management/ITIL-1/itil-4-practitioner-release-management-3798

Products

Why Matrix42?

Marketplace

Solutions

Industries

Services

Partners program

User resources

Learn more

M42 careers

About Matrix42

Contact