Business and operations support systems are where an operator's products, customers, orders, bills and network resources meet. They are also where decades of mergers, tactical fixes and bespoke customisation accumulate. Most operators run several generations of BSS and OSS in parallel, stitched together by point-to-point interfaces. Launching a new product can mean changes in a dozen systems; retiring an old one can take years.
The cost is visible in how IT money is spent. Operators surveyed by TM Forum said they spend about 80% of their IT budgets on integration and customisation, leaving only 20% for innovation2. That ratio is the strategic problem: it is not that the stack is old, but that it absorbs the capacity needed to change it.
Why big-bang replacements fail
The traditional answer, a multi-year programme to replace the full stack, has a poor record across industries. Research by McKinsey and the University of Oxford found that large IT projects run on average 45% over budget and 7% over time while delivering 56% less value than predicted; every additional year spent on a project increased cost overruns by 15%, and 17% of IT projects went so badly they could threaten the company's existence9. BCG found that 70% of digital transformations fall short of their objectives10.
Large IT programmes overrun on cost and underdeliver on value
Average outcome of large IT projects versus plan, % (%)
Note: Cross-industry research by McKinsey and the University of Oxford on projects with initial budgets above USD 15m.
Source: McKinsey & Company, “Delivering large-scale IT projects on time, on budget, and on value” (2012)
BSS programmes share the classic failure modes: a scope defined as 'replace everything', heavy customisation of a new platform to replicate old behaviour, data migration left to the end, and a single cut-over whose risk grows with every month of delay. Most damaging of all, the old stack is rarely switched off, so the operator ends up running both.
What has changed: standards and cloud
The alternative is incremental, domain-by-domain modernisation behind stable interfaces, and the building blocks now exist. TM Forum's Open API programme has grown from a handful of APIs in 2014 to more than 60 in 20234; its version 4 APIs have been downloaded more than 780,000 times, with 78 organisations gaining conformance certification3. As early as 2021, around 60% of industry RFPs included a mandatory request for conformance with the Open APIs2, and 22,000 people from 1,900 companies were using them1.
The Open Digital Architecture (ODA) goes further, defining standard components and a Canvas, a cloud-native runtime on which they are deployed and managed. The ODA Canvas became available for widespread use in January 2025, and nearly a third of CSPs surveyed said they were making good progress towards an ODA Canvas DevOps environment5. One European operator reported that configuring an API gateway on its Canvas takes three seconds, against two weeks manually5.
Cloud adoption is steady rather than sweeping. In a TM Forum survey of 226 responses from 118 operators, the share that had moved at least half of OSS/BSS workloads to public cloud had more than doubled, from 8% in 2021 to 17%7. On BSS strategy, 45% were taking or planning an aggressive, transformational approach, usually meaning cloud-native systems, while 42% preferred a more cautious improvement of legacy BSS6. The vendor market remains concentrated: Omdia data cited by Light Reading attribute 68% of charging revenues to six vendors8.
Public cloud is growing in BSS/OSS, from a low base
Share of operators that have moved at least 50% of OSS/BSS workloads to public cloud, % (%)
Note: TM Forum survey, 226 responses from 118 operators (2024).
Source: TM Forum Inform, “Telcos opt for a hybrid, multicloud approach to BSS/OSS” (2024)
The product catalogue is usually the right place to start. When every offer, price and bundle is defined once, in a catalogue that order management, charging, billing and channels all consume through standard APIs, new products can be launched without code changes across a dozen systems. Rationalising the catalogue also forces a useful commercial conversation: many operators carry thousands of legacy tariffs that few customers use but every system must still support. Migrating customers off those tariffs is often a precondition for switching off the systems that host them.
The organisational model has to change too. Domain-by-domain modernisation works when a single team owns each domain end to end, including its data, APIs, migration waves and decommissioning, and is measured on business outcomes such as time to launch, order fall-out and cost per customer rather than on programme milestones. Vendor contracts should reward retirement of legacy components as well as delivery of new ones.
AI changes the migration economics
The most expensive part of modernisation has always been understanding and moving what already exists: undocumented business rules, bespoke rating logic, custom interfaces and data. This is where generative AI is having a measurable effect. McKinsey reports that GenAI can drive a 40% to 50% acceleration in technology modernisation timelines and a 40% reduction in costs derived from technology debt; in one case, an orchestrated GenAI approach cut the estimated effort to migrate 20,000 lines of code by 40%11. Google engineers reported that LLM-assisted internal code migrations reduced total migration time by an estimated 50%, with 80% of code modifications in landed changes fully AI-authored12.
These are not telecom results, and BSS logic is harder than a framework upgrade because it encodes commercial decisions. But they change the planning assumption. AI can reverse-engineer business rules from legacy code, generate test cases from production traffic, map legacy data to TM Forum's information model and draft Open API adapters, all under engineering review. The effort shifts from writing code to validating it.
Operators should also be realistic about where AI helps least. It cannot resolve commercial ambiguity (which of three conflicting discount rules reflects current policy) or substitute for business owners deciding which legacy behaviour to keep. It is a powerful accelerator of analysis and code; it is not a replacement for decisions.
- Stabilise the interfaces first. Put Open API facades in front of legacy systems so channels and partners stop depending on internals.
- Modernise by domain and product. Migrate one product family or segment at a time, with live customers moved in waves.
- Treat data as the programme. Reconcile, cleanse and migrate customer, product and inventory data continuously, not at the end.
- Budget for decommissioning. A domain is finished when the old system is switched off, not when the new one goes live.
- Use AI with controls. Every AI-generated rule, adapter or test is reviewed, versioned and traced back to its legacy source.