ITIL 5 Digital Product and Service Lifecycle: what changed under the new value chain

In early 2026, PeopleCert moved ITIL Version 5 into the open. The Foundation course and exam went live from 12 February 2026. Teams that had lived inside ITIL 4 suddenly saw a new diagram on every briefing slide.

The biggest structural move is straightforward to name and hard to ignore. The six-activity Service Value Chain gives way to an eight-stage Digital Product and Service Lifecycle. The model is more granular on the product-creation side. The stages most exposed to bad configuration data are the same ones that broke under ITIL 4.

That raises a practical question for any shop still running ITIL 4 practices in production. Is this a forced rebuild this quarter, or a planning signal for the next certification and operating-model cycle? This guide covers definition, the eight stages, how the model differs from the old chain, what carries over, and where accurate configuration data still decides outcomes. For runtime context under change and service risk, start with Trusted Runtime Truth.

What is the Digital Product and Service Lifecycle

The Digital Product and Service Lifecycle is the value-chain model that replaces the Service Value Chain inside the Service Value System (SVS). Placement stays familiar. The SVS still holds guiding principles, governance, the value chain, management practices, and continual improvement. Only the chain model is rewritten for product-and-service work.

PeopleCert frames ITIL Version 5 around end-to-end digital products and services, not service management alone. Its ITIL Version 5 overview for certified professionals stresses a phased release. Existing knowledge and certifications remain part of the journey.

The lifecycle is not a fixed waterfall. Stages interconnect and can run in parallel inside organization-specific value streams. A team can be building one release package while still discovering demand for the next offering. Parallel work does not remove the need for a shared picture of what already exists in the live estate.

ITIL Version 5 Foundation launched on 12 February 2026, replacing the Service Value Chain with this eight-stage model.

The ITIL 5 eight stages

Keep the map short. Each stage is one job, not a full practice guide.

• Discover: Explore and prioritize needs and opportunities against strategy and consumer demand.
• Design: Create solutions that meet or exceed agreed requirements, including experience and operating constraints.
• Acquire: Procure or allocate the resources required to build the product.
• Build: Create, configure, and test the technology solution before it enters the live path.
• Transition: Deploy the product into the live environment and handle supplier onboarding or offboarding tied to that move.
• Operate: Run the product to agreed performance and reliability targets.
• Deliver: Provide the digital services based on the live product, including user onboarding and quality standards.
• Support: Restore normal operation when something breaks, including incident and recovery work.

How this differs from the ITIL 4 Service Value Chain

ITIL 4 organized value work around six Service Value Chain activities: Plan, Engage, Design and transition, Obtain/Build, Deliver and support, and Improve. ITIL 5 keeps a value chain inside the SVS (also referred to as the ITIL Value Chain, or PSLM — the Product and Service Lifecycle Model). The chain activities now follow the product and service lifecycle stages above.

The granularity shift is what most teams feel first. Design and transition expands into four stages: Design, Acquire, Build, and Transition. Deliver and support splits into Deliver and Support. Operate sits as its own run-state stage between transition and consumer-facing delivery.

Plan and Improve do not appear as named lifecycle stages in the same way. Continual improvement remains a standing SVS component across value streams, not a single chain box you tick once per release. Engage still happens wherever a value stream touches consumers and stakeholders.

That split helps training diagrams. It does not invent immunity to stale configuration data. Build, Transition, and Operate still consume configuration truth the way Design and transition and Obtain/Build did when the CMDB lagged the estate. The change-and-release split matters more once approvals get mapped to the new stage names. Virima blog post comparing change management and release management under ITIL

For a wider view of how the standard is shifting at framework level, see ITIL 5 framework changes.

What carries over from ITIL 4

Most of the architecture that practitioners already know survives the version label.

The five SVS components stay in place: guiding principles, governance, the value chain, management practices, and continual improvement. The seven guiding principles are retained. The four dimensions remain organizations and people, information and technology, partners and suppliers, and value streams and processes. All 34 management practices remain in the system, with several recategorized rather than deleted.

Certification continuity matters for hiring and audit narratives. Existing ITIL 4 certifications remain valid. PeopleCert is rolling Version 5 through a phased path, and ITIL 4 stays available in that window. Bridge options cover Foundation holders who need the delta without repeating every topic. Official guidance sits on the ITIL Version 5 transition path from ITIL 4.

The practical read for operating teams is simple. You are not throwing away four dimensions, principles, or the practice library because the chain diagram gained two extra stage names.

Why ITIL 5 configuration data still decides the lifecycle

Here is the differentiator that training decks often skip. Build, Transition, and Operate each assume an accurate picture of the current environment.

Build needs to know which components already exist so configuration work hits real baselines, not last quarter’s spreadsheet. Transition needs the live environment picture before a package lands. That includes shared services, owners, and downstream consumers. Operate needs current data to confirm agreed performance against the estate that is running, not the estate a design workshop remembered.

That is the same risk ITIL 4 teams hit inside Design and transition and Obtain/Build. A decision on stale configuration data produces a plan built on a false picture. Consider a Transition cutover that fails because a decommissioned server is still tagged active in the CMDB — the runbook targets a dependency that no longer exists, and the rollback plan never covers the real one that does. But the failure may look like a process miss. The root is often a missing relationship, a wrong environment tag, or an owner record that never updated after migration.

Federal asset-visibility programs keep pressing the same foundation. CISA BOD 23-01 is one clear example: you cannot govern what you cannot inventory. Release and change work inherit that limit whether the slide says Service Value Chain or Digital Product and Service Lifecycle.

Programs that want those stages to hold treat the configuration management database (CMDB) as an input to build and cutover decisions, not a side archive. For how teams structure that foundation, see CMDB implementation steps. See the CMDB readiness checklist for Build, Transition, and Operate. How to Build an AI-Ready CMDB Checklist for 2026

What this means for teams on ITIL 4 today

There is no forced urgency to rip out a working ITIL 4 operating model because Version 5 Foundation is live. Before the next planning cycle, audit which of your current Build, Transition, and Operate runbooks rely on CI data that hasn’t been verified against the live estate in the last quarter — that gap matters more than which chain diagram is on the wall. Training budgets and bridge exams can move on a deliberate calendar.

Treat the eight-stage model as a signal of direction. Product creation gets more explicit stage names. Deliver, operate, and support are separated so value streams can be drawn with less ambiguity. Continual improvement stays systemic rather than a single chain activity.

So point the planning conversation back to data accuracy. Whichever version a team follows, Build, Transition, and Operate still fail when the CI graph is wrong. High-frequency scheduled discovery cycles refresh configuration and relationship records better than spreadsheet uploads between packages. Agent, agentless, and API collection can feed the same CMDB your ITSM tools already read.

Virima supports that model by discovery-sourcing configuration and relationship data into the CMDB those lifecycle stages already depend on, including paths into ServiceNow, Jira, Ivanti, and other ITSM platforms.

The Framework Changed. The Data Dependency Did Not.

Version 5 rewrote the chain diagram. It did not invent a world where Build can configure against fiction. Transition still cannot deploy into an unknown blast radius. Operate still cannot prove performance without a current estate record.

When the next package or practice refresh hits the calendar, inspect the configuration evidence those stages will use before you debate stage names on a whiteboard. If the record is thin, fix the data path first.

Whichever version your team runs today, the Digital Product and Service Lifecycle only holds up when the CMDB behind it is current. Download the ITIL 4 to ITIL 5 stage-mapping and configuration-data checklist to see where Build, Transition, and Operate depend on data you haven’t verified yet. How to Build an AI-Ready CMDB Checklist for 2026 See how Virima keeps that data discovery-sourced and current. CMDB

Frequently Asked Questions