ITIL Service Transition Applied to OSS Modernization

Collapsing a fragmented legacy OSS stack onto a unified, AI-ready platform is not, at bottom, a technology problem. It is a controlled-change problem, and most modernization programs treat it as the former while quietly failing at the latter.

Fragmentation in OSS is rarely the result of one bad decision. It accumulates over decades of best-of-breed purchasing, where each new function, provisioning, inventory, assurance, gets its own system because no single platform did everything well at the time it was bought. Mergers and acquisitions compound the problem. At the Data-Driven Telco Summit at MWC 2026, a Wavelo representative recounted a private equity operating partner describing the acquisition of two companies, each carrying $200 million to $400 million in annual system spend, with not one overlapping system between them. That is not an edge case. That is what twenty years of telecom M&A activity tends to produce: parallel stacks, duplicated functions, and integration treated as an afterthought rather than a design constraint.

The financial consequence is stark. By some estimates, a substantial share of total annual OSS/BSS spend now goes toward keeping systems alive that have no future in the architecture, purely because decommissioning them risks disrupting services that are still running on top of them. Operators are not paying to maintain functionality. They are paying rent on risk they have not figured out how to retire.

That risk is acute because live service delivery cannot pause for a cutover. Provisioning, activation, assurance, and inventory functions run continuously, and an uncontrolled change to any of them can cascade into an outage affecting customers who have no idea a modernization program is even underway. Kearney's Christoph Neunkirchen, speaking at the same 2026 summit, noted that several European operators reported needing ten to twelve months to launch a new product, a delay driven entirely by legacy IT constraints. That figure says something important: operational continuity and system fragility are so entangled that even a straightforward product launch becomes a multi-quarter project.

Here is the actual gap. The technical architecture decisions, microservices, APIs, unified data models, AI agents making provisioning decisions, are reasonably well understood across the industry at this point. What is rarely planned with the same rigor is the governance machinery for moving from the old stack to the new one without breaking what customers already depend on. ITIL Service Transition exists precisely to fill that gap. It is a vendor-neutral, decades-tested scaffold for exactly this class of problem: controlled, tested change that reaches production without breaking what is already live. The rest of this piece works through four of its core disciplines, change management, release management, configuration management, and knowledge management, and maps each one to the specific decision points an OSS modernization program has to get through.

What ITIL Service Transition actually covers, and how its scope maps to an OSS modernization program

Service Transition's job, across every version of ITIL, has been to take services shaped in strategy and design and move them into live operation, to modify services already running, and to retire services no longer needed, all while keeping disruption to a minimum. ITIL v3 treated this as its own distinct lifecycle stage. ITIL 4, published in 2019, folded it into "Design and transition," one of six activities inside the Service Value Chain alongside Plan, Improve, Engage, Obtain/build, and Deliver and support. ITIL 5 pulls it back out as a standalone activity. The naming has shifted across three revisions of the framework, but the underlying goal has not: get change into production without wrecking what is already there.

Four disciplines do the actual operational work. Change management evaluates, authorizes, and schedules changes to live environments, with a Change Advisory Board (CAB) weighing benefit against risk and a Change Manager holding final authorization. Release management is a separate function: it packages, tests, and deploys changes in a controlled sequence, distinct from the authorization decision itself. Configuration management maintains an authoritative record of every service component and how those components relate to one another, typically inside a Configuration Management Database (CMDB). Knowledge management captures what gets learned during the transition itself, so the operations team inheriting the new system isn't starting from zero.

OSS modernization is close to a textbook case for why Service Transition exists. These programs run multiple interdependent projects in parallel: upgrading a telecom operator's database, for instance, often requires migrating data from the existing database only after the new database creation project is fully complete, a sequencing dependency that has nothing to do with either project's internal quality and everything to do with how the two are ordered against each other. Add to that the introduction of AI-driven automation into provisioning loops that used to have a human checking every step, plus the simultaneous retirement of legacy systems as the new platform comes online, and the program is managing transition in two directions at once. That is squarely the kind of complexity Service Transition was built to govern.

It's worth being clear about what this framework does not cover. Technology selection, vendor negotiation, and business case construction belong to Service Strategy and Service Design, earlier stages in the ITIL lifecycle. This piece is concerned with the governance of execution, the period after the architecture has been chosen and the vendor contract signed, when the real risk of the program gets realized or avoided.

How change management gates each OSS modernization decision point

An OSS modernization program has a handful of decision points that demand formal change evaluation rather than informal sign-off. Platform cutover, switching live provisioning traffic from the legacy OSS to the new unified platform, is the single highest-risk event in the entire program. Configuration baseline changes, where the existing network inventory record gets replaced with a new unified data model baseline, carry similar weight because everything downstream depends on that baseline being accurate. Activation workflow rollout, where human-supervised provisioning steps get replaced by automated or AI-assisted ones, changes not just the software but who is accountable when something goes wrong. And legacy system retirement, decommissioning a system that still holds reference data or still carries fallback traffic, closes off an escape route the program may still need.

AI-driven automation entering a previously human-supervised loop is not a routine software release, and treating it as one is a mistake. It changes accountability structures, not just code paths. A CAB evaluating this kind of change has to ask what decisions the AI agent will make autonomously, under what conditions, and what the rollback path looks like if the agent acts incorrectly. That evaluation needs to cover the agent's permission scope, which APIs it is authorized to call, and whether its actions leave behind an audit trail comparable to what a human operator would have produced doing the same job manually. Skipping this step doesn't remove the risk. It just means nobody signed off on it.

Not every change needs the same level of scrutiny, and ITIL's categories reflect that. Standard changes are pre-approved, low-risk, and repeatable, adding a new service definition to the product catalog on the new platform is a reasonable example. Normal changes require full CAB review, activating a new provisioning workflow for a new service type falls here. Emergency changes get an expedited path for unexpected failures during cutover, but even those must be logged and reviewed after the fact, not simply absorbed into the noise of a busy migration.

Without explicit CAB gates at these four decision points, modernization programs tend to "creep live." Changes reach production incrementally, without formal authorization, because each individual step felt small enough to skip the process. The result shows up later, when something breaks and nobody can say with confidence what changed, when, or why, which makes rollback and root-cause analysis far harder than they need to be. Once a change clears authorization, the next question is how it actually gets packaged and sequenced into a live environment without stacking risk on top of risk, and that's release management's job.

Release sequencing when the old stack and the new platform must coexist

A big-bang cutover, switching everything from legacy to new platform in a single event, is rarely viable for OSS. Provisioning, assurance, and activation cannot be suspended while the new platform stands itself up, and legacy systems often hold data that must be migrated before they can be decommissioned, but that migration can't be fully validated until the new platform is actually running and handling traffic. That's a circular dependency, and the only way through it is a phased release plan rather than a single cutover date circled on a calendar.

During the period when both stacks run in parallel, two versions of provisioning logic are active at once: legacy handling existing services, the new platform handling new activations. Any change to shared reference data, network inventory or the service catalog, has to be released to both environments in a controlled sequence, or the two stacks start to diverge, quietly, in ways that are hard to detect until a provisioning error surfaces weeks later. Event-driven architecture can reduce that risk considerably. The TM Forum Catalyst project "Autonomous and sustainable moving IoT ecosystems," in its Phase III run with operator Champions BT, DISH, and Mascom alongside technology participants CGI, NTT DATA, Ribbon, and Wavelo, demonstrated how event-driven architecture can bridge legacy REST-based systems and AI-native platforms without forcing simultaneous decommissioning. Legacy synchronous calls get translated into event streams that both the old and new stacks can consume, which means the two systems don't have to agree on everything at once, just on the event format.

A handful of sequencing principles carry directly over from general release management practice into this specific problem. Define the release boundary clearly: which services migrate in which wave, and what condition has to be met before promotion to the next wave happens. Build a rollback gate into every release, so that if the new platform mishandles a particular service type, the plan allows fallback to legacy without losing data in the process. And test in a staging environment that actually mirrors live traffic patterns, not a synthetic environment that looks tidy on paper but bears no resemblance to real provisioning load at 2 a.m. on a Friday.

FTTH and Carrier Ethernet add a specific wrinkle here. Zero-touch provisioning (ZTP) targets mean activation workflows get released into production without a human reviewing each individual order, so release management has to validate that the automated workflow handles edge cases correctly before ZTP scope expands to cover more of the order volume. Get that validation wrong, and the mistake doesn't surface as one bad ticket, it surfaces as a pattern across however many orders passed through the workflow before anyone noticed. Once the parallel-running period is underway, though, a different problem emerges: knowing, at any given moment, what is actually deployed where across two coexisting stacks. That's a configuration management question.

Configuration management as the foundation for a trustworthy unified data model

A unified OSS data model, the one spanning network qualification, design, provisioning, and activation, is only as reliable as the configuration management discipline underneath it. If the CMDB isn't kept current throughout the modernization, the new platform doesn't escape the legacy stack's data quality problems. It inherits them, repackaged in a cleaner interface. According to Kearney analysis presented at the Data-Driven Telco Summit 2026, data fragmentation is the primary barrier to scaling AI in telecom, and that fragmentation traces back to configuration records that were never reconciled across siloed systems in the first place. A new platform built on top of unreconciled records is still built on unreconciled records.

In an AI-native OSS context, configuration management has to cover more ground than it used to. Network inventory means every physical and logical resource the new platform will manage, fiber spans, OLTs, circuits, VLANs, IP address blocks. Service configurations are the parameters for each active customer service, and if those get migrated inaccurately, activation and assurance break downstream, often in ways that don't show up until a customer calls in. AI agent configurations belong in the same category as any other configuration item, including the version of the agent, the APIs it's authorized to call, its permission scope, and where its audit log lives. And the integration point registry, which systems connect to the new platform, through which APIs, under what data contract, is essential for managing the parallel-running period described above.

None of this is optional groundwork. An operator cannot migrate what was never recorded, which means a configuration audit before modernization begins isn't a nice-to-have, it is effectively the first release in the program, whether or not anyone labels it that way. Aligning CMDB structure with established industry data model conventions cuts down the reconciliation work needed both during and after the transition.

Skip this discipline, and the consequence is predictable: the new platform goes live on an incomplete or inaccurate inventory baseline, AI agents start making provisioning decisions on bad data, and the operator has no reliable way to tell whether a service activation failure came from the new platform itself or from a bad configuration record it quietly inherited from the system it replaced. Everything the configuration management discipline captures along the way, the decisions made, the data migrated, the problems hit and fixed, still needs somewhere to live once the transition team disperses. That's what knowledge management is for.

Knowledge management as the bridge between the transition team and the operations team

Modernization programs are typically staffed with a mix of external integrators, platform vendors, and internal architects, a team composition that dissolves the moment the program reaches go-live. The people who understood why a given architectural choice got made are, within weeks, mostly gone. The operations team left holding the new platform has to support AI-native workflows, a unified data model, and new activation logic, none of which existed in the environment they were originally trained on.

Knowledge management during the transition program has to capture several distinct things. A decision log records why each architectural choice was made, particularly the choices that constrained what the new platform can and cannot do, so future operators understand the boundaries rather than discovering them by accident. A known error database tracks every issue hit during testing and parallel running, its root cause, and how it got resolved, functioning as the first line of support once operations takes over. Runbooks for AI-assisted workflows need to spell out what the agent does on its own, what triggers escalation to a human, and how to audit an agent's decision after the fact when something needs explaining. And configuration baseline documentation records what was actually migrated, what got intentionally left behind, and what still sits on legacy systems.

There's a governance dimension to this that goes beyond documentation habits. Governed AI in telecom operations requires that every agent inference or recommendation trace back to the agent version, the input context, and the decision logic that produced it, and that traceability is a knowledge management artifact as much as it is a technical log entry. If the only explainability available sits inside one vendor's system, the operator doesn't actually own its own audit trail. Knowledge management has to ensure decision logs are exportable and retained in the operator's own systems, not locked inside a platform the operator merely licenses. Amdocs aOS, announced February 3, 2026, includes built-in compliance, observability, and governance guardrails, but how an operator documents and retains the output of those guardrails for its own audit purposes is a knowledge management decision, not something the platform settles on its own.

Operations teams that actually understand why the new platform behaves the way it does are in a far better position to extend it, adding new service types, expanding what an AI agent is allowed to do, integrating a new network domain, without reintroducing the fragmentation the modernization program was built to eliminate in the first place. That continuity is the entire point of the discipline.

Applying the full scaffold to FTTH, dedicated internet, and Carrier Ethernet service delivery

These three service types don't present identical transition problems, and treating them as interchangeable is where a lot of programs lose the thread. FTTH runs at high activation volume with zero-touch provisioning targets and real truck-roll cost pressure, which means activation workflows get released at scale, and release management has to validate ZTP logic exhaustively before scope expands further. Dedicated internet is SLA-bound and often enterprise-facing, so configuration management has to keep circuit records accurate, or assurance breaks and SLA penalties follow directly. Carrier Ethernet operates under MEF 3.0, the service framework governing a global CE market estimated at roughly $60 billion, and MEF 59 draws on specifications aligned with current models from ITU-T, ONF, and TM Forum to support orchestration across multi-vendor, multi-technology platforms, which means change management has to account for how any configuration baseline change ripples across multiple vendors, not just one.

FTTH's activation workflow transition needs each core function, activate, suspend, resume, bandwidth modify, delete, tested and released independently before ZTP scope is allowed to cover it. Release management's wave structure should start with new activations, the lowest-risk category since there's no existing customer service to disrupt if something goes wrong, before extending automation to modification and deletion workflows that touch services already in production.

Dedicated internet and Carrier Ethernet put more weight on the configuration and change disciplines than on release sequencing, precisely because the stakes of a bad configuration record are contractual, not just operational. An inaccurate circuit record on a dedicated internet service doesn't just cause an assurance alert, it can trigger an SLA breach with a financial penalty attached. And a configuration baseline change on a Carrier Ethernet service, given the multi-vendor orchestration MEF 59 is built around, doesn't stay contained to one operator's platform. It can ripple across every vendor's equipment participating in that service chain. That's precisely why change management's CAB function, evaluating risk before authorizing a change rather than after discovering the consequences, matters more here than almost anywhere else in the modernization program. Applied consistently, across FTTH, dedicated internet, and Carrier Ethernet alike, the four disciplines of Service Transition are what let an operator collapse a fragmented OSS stack into something unified and AI-ready without the transition itself becoming the outage the program was meant to prevent.