Articles
Modernizing the digital experience stack without a big-bang cutover
Share it on
Legacy CMS modernization in telecom does not mean putting a freeze on the digital experience stack, stopping business-as-usual releases, or taking months of customer-facing risk on a single, high-stakes cutover weekend. The alternative, the strangler fig pattern, incrementally replaces legacy CMS and digital experience components, routing traffic to new services piece by piece while the old system continues to run underneath, until the legacy platform can finally be retired with nothing left depending on it.
In this article we explain how this approach actually works in a telecom context, how to keep the normal release cadence running through the migration, what to sequence first, and – critically – how to produce real evidence for a claim that most vendors make and almost nobody backs up: that modernization can happen without disrupting the business.
What is legacy CMS modernization in telecom, and why does it matter?
Legacy CMS modernization in telecom is replacing an aging, often monolithic content management system – built years or decades ago to serve a single channel – with a modern, API-driven digital experience platform that can serve web, app, self-care portals and partner channels from a single content layer. For the majority of telecom operators, the legacy CMS in question was never designed for today’s needs. It was designed for a desktop website, not an omnichannel experience across app, web, IVR-linked self-service and partner-branded portals simultaneously.
Why does this matter? Because the CMS is right in the critical path of revenue-generating and support-critical customer journeys – plan changes, billing disputes, service activation, upgrade flows. This layer is a real business risk if you don’t pay attention in your modernization projects which is why so many operators delay legacy CMS modernization so much longer than they do other IT investments. The perceived risk of touching a system that revenue that customers see depends on is greater than the acknowledged cost of continuing to run on it. The strangler fig pattern exists precisely to take that risk out of the equation.
What is the strangler fig pattern, and why is it the right approach for telecom?
The strangler fig pattern is a method of migration, named for the strangler fig vine which slowly wraps around and, in the end, replaces a host tree; in this approach a new system is developed alongside the existing one and gradually takes over certain functions, diverting traffic step by step away from the old system until no one depends on it and it can then be safely turned off. Unlike the rip-and-replace method, the strangler fig pattern never demands a single point at which the entire existing platform is switched off and the new one switched on—this is exactly the moment when most "big bang" telecom modernization projects encounter difficulties.
Want to see how Torry Harris structures a phased migration plan for a system as customer-critical as a telecom CMS or digital experience stack?
Talk to us about a strangler-pattern modernization roadmap
How does the strangler fig pattern work in practice?
In practice, the pattern is built around a routing layer (frequently implemented as an API gateway or reverse proxy) that sits in front of both the legacy CMS and the new platform. At first, that routing layer directs basically all traffic to the legacy system, with the new platform running in parallel and handling only a small, carefully selected portion of traffic: a single page template, a single self-service journey, or a single low risk part of the site. As confidence increases, the routing layer is altered so that it begins to send an increasing amount of traffic to the new platform, one journey or type of content at a time, while the older system keeps on providing all the content that hasn't yet been migrated. Each of these incremental changes can be tested on its own, reversed on its own, and is small enough that if there's a problem with one migrated journey it won't affect anything else. The legacy CMS is only switched off once all the journeys have been migrated and verified — at that stage it had already ceased to serve any live traffic, so the actual decommissioning becomes a low-risk formality rather than a high-stakes event.
Why "Big Bang" cutovers fail in telecom digital experience stacks
Big-bang cutovers fail for structural rather than project-management reasons since they bring all the categories of migration risk — including content parity, integration behaviour, performance under real load, and edge-case customer journeys — together into one moment, without allowing any means of determining which change caused a particular problem should anything go wrong. In the telecommunications sector this risk is greater because the digital experience stack is built directly on top of billing, provisioning, and customer identity systems which a CMS migration project usually does not have direct control over, making it very difficult to fully test integration behaviour in advance. Whenever a big-bang migration of a telecom CMS fails, the failure tends to be both public and immediate, with plan changes failing, self-service journeys breaking, and there being a sharp rise in contact-centre volume exactly when the new platform is least able to be debugged under production load.
How do you maintain BAU release cadence during a legacy CMS migration?
Maintaining business-as-usual release cadence during a legacy CMS migration is one of the most commonly promised and least commonly delivered outcomes in telecom modernization — largely because most migration plans treat the legacy system as effectively frozen for the duration of the project, which is unrealistic for any operator still running active marketing campaigns, regulatory content updates, or product launches during the migration window.
The strangler fig pattern solves this by design, because the legacy system keeps running normally for everything not yet migrated, which means the content and marketing teams responsible for BAU releases can continue publishing through the legacy CMS exactly as before, on whichever journeys haven't yet moved to the new platform. The migration team, meanwhile, works against the new platform independently, with the routing layer as the only shared dependency between the two workstreams. This separation is what allows both workstreams to proceed in parallel without one blocking the other — a marketing team publishing a new tariff page through the legacy CMS on a Tuesday doesn't need to wait for the migration team's next release window, because they're not touching the same system.
The practical requirement this places on the migration team is discipline around routing-layer changes: every traffic shift needs to be treated as a controlled release in its own right, with the same testing, rollback plan, and monitoring as any other production change — not as an implementation detail buried inside a larger migration milestone. Operators that skip this discipline tend to find that the strangler pattern's safety benefits erode, because routing changes start being made ad hoc rather than as governed releases.
What should you migrate first? Sequencing a strangler-pattern rollout
Sequencing is where most of the judgment in a strangler-pattern migration actually lives, and getting it wrong doesn't cause the project to fail outright — it just means the risk-reduction benefit of the pattern is never fully realized. The general principle is to migrate from lowest business risk toward highest, using the early, low-risk migrations to validate the new platform's integration behavior, performance characteristics, and content-parity tooling before committing to journeys where a mistake would be genuinely costly.
Static, informational content — coverage checkers, help articles, general product information pages — is almost always the right starting point, because these pages carry no transactional risk: a rendering issue is embarrassing but not revenue-affecting, and there's no integration dependency on billing or provisioning systems to get wrong. From there, sequencing typically moves toward semi-transactional content, such as tariff and plan comparison pages, where the risk is slightly higher because commercial accuracy matters but the page still isn't executing a transaction directly. Only once the new platform has proven itself across both of these tiers should migration extend into genuinely transactional, integration-heavy journeys — plan changes, upgrades, service activation — where a CMS-layer bug can directly cause a failed billing action or a broken provisioning request.
This sequencing also has a secondary benefit worth stating explicitly for anyone building the business case: because each tier is measurably validated before the next begins, the migration produces demonstrable proof points at every stage rather than asking stakeholders to wait for a single, distant "done" milestone before seeing any evidence the approach is working.
Not sure where your own platform's risk tiers fall, or which journeys should move first?
Get a sequencing assessment from Torry Harris for your digital experience stack
How does AI-assisted migration accelerate telco CMS modernization?
AI-assisted migration addresses the part of legacy CMS modernization that has traditionally been the slowest and most manually intensive: content migration and mapping. A telecom operator's legacy CMS typically holds years of accumulated content — product pages, help articles, legal and regulatory text, localized variants — much of it inconsistently structured, tagged, or templated after years of ad hoc editing by multiple teams. Manually auditing, re-templating, and quality-checking that volume of content against a new platform's content model is historically one of the largest cost and timeline drivers in a CMS migration. AI-assisted tooling changes the economics of that work in several specific ways. It can analyze legacy content at scale to identify structural patterns, duplicate or near-duplicate pages, and outdated or non-compliant content that shouldn't be migrated at all — work that would otherwise require a human content auditor reading through thousands of pages individually. It can assist in mapping unstructured legacy content into the structured content model a modern platform expects, flagging fields it can't map with confidence for human review rather than guessing silently. And it can generate first-pass content-parity checks between a legacy page and its migrated equivalent, surfacing discrepancies for a human reviewer to confirm rather than requiring line-by-line manual comparison across every migrated page.
The important caveat, particularly for regulated telecom content — pricing, contractual terms, compliance-mandated disclosures — is that AI-assisted migration accelerates the audit and mapping work; it doesn't replace human sign-off on anything customer-facing or commercially binding. Used well, it compresses the mechanical part of migration timelines significantly while leaving judgment calls, especially anything with legal or billing implications, with a human reviewer.
How do you prove "No business disruption" during modernization?
This is the claim every vendor makes and almost nobody backs up with evidence, and it deserves a direct answer rather than a reassurance. Proving no business disruption during a legacy CMS modernization means defining, in advance, the specific metrics that would reveal disruption if it occurred, and then actually monitoring and reporting against them throughout the migration rather than only at the end.
The metrics that matter most are directly tied to the risks a big-bang approach concentrates in one moment: conversion and completion rates on migrated journeys, measured against their legacy-platform baseline for the same journey and traffic volume; contact-centre volume and average handling time for issues related to the migrated journeys specifically, isolated from unrelated support drivers; page performance and error rates on the new platform under real production traffic, not synthetic load testing alone; and content-parity audit results, confirming that migrated content matches legacy content in substance even where presentation has changed.
Because the strangler pattern migrates one journey at a time, each of these metrics can be measured on a small, contained slice of traffic before the next journey moves — which means "no disruption" stops being a promise made at the project's outset and becomes a claim with a specific, journey-by-journey evidence trail behind it by the time the migration completes.
Evidence of phased, non-disruptive delivery at telecom scale
The integration architecture transformation done by Torry Harris for the BT Group, that integrated BT, EE, and Plusnet on a common architecture in line with TM Forum’s Open Digital Architecture and Open API standards, was carried out based on this very principle, despite the fact that it was an integration architecture transformation and not a CMS transformation. Instead of the big bang approach, the program was deployed in iterations where each iteration had to be validated with respect to customer traffic before moving to another iteration.
This kind of success, achieved by measuring the results of the programme: #1 CSAT ranking for the Telco industry, self-service usage increase from 50% to 82%, 60% decrease in manual integration burden, and maintaining 100% accuracy in billing during the move, is only possible due to the incremental delivery process. A one-off cut-over could be disastrous in terms of disrupting millions of paying customers.
Case study • BT Group
How BT unified BT, EE and Plusnet on one TM Forum ODA-aligned architecture
What should telecom CIOs and enterprise architects take away?
This one point is the most important lesson that can be transferred to any future situation because "no business disruption" can only be made real through a migration architecture that is inherently resistant to disruption rather than just a project plan for avoiding it. This is the case with the strangler fig approach since it allows for each step of the migration process to include a scenario where whatever the legacy application does that cannot be safely moved to the new architecture will still be done by the old one, where BAU releases continue via the legacy CMS regardless of the migration schedule, and where sequencing is done from low to high business risk.
AI-assisted migration tools could significantly reduce the duration of the content audit and mapping process, yet they work within this framework rather than obviating the need for it – the art of incrementally taking small steps is precisely what makes "without disruption" possible, not the technology used to execute each one.
Related Services
Related insights
ARTICLE
Your BSS isn’t the problem: Your approach to modernization is
ARTICLE
OSS/BSS legacy modernization: Why most telco transformations fail to deliver
ARTICLE
Modernization decisions that matter: A C-suite framework for legacy portfolios
Case study
Three Ireland’s 48 disrupts the market with a unique digital experience
Ready to modernize without a Big-Bang cutover?
Frozen release calendars, high-risk cutover weekends, and a legacy CMS that every revenue journey still depends on. Torry Harris helps telecom operators migrate journey by journey, with BAU releases running and evidence of zero disruption at every stage.
Frequently asked questions
Legacy system modernization is the process of updating outdated software, hardware, and architectures to meet current standards for security, speed, and scale without losing core business logic.
Legacy modernization is the specific process of updating, optimizing, or replacing an organization's outdated, legacy IT systems, software applications, and infrastructure. Because IT Transformation focuses directly on upgrading the technological environment to achieve better operational efficiency and agility, it serves as a direct example of legacy modernization.
Modernizing legacy applications involves assessing current systems and choosing the right transformation approach, such as rehosting or refactoring, to improve performance, security, and scalability.
Maintain a legacy system by conducting thorough architecture audits, applying small incremental changes, and documenting critical operational knowledge. Maintaining older infrastructure involves balancing the hidden costs of maintaining legacy systems with practical, day-to-day stability practices.
Legacy system integration connects older, outdated infrastructure with modern cloud platforms and SaaS tools so they can share data without a full system replacement.