Telecoms operators have spent a decade talking about digital transformation. Yet many are still spending a significant proportion of their IT budgets maintaining legacy systems that were never designed for today’s pace of service innovation.
What’s increasingly clear is that the problem is no longer just operational inefficiency. It is missed revenue.
Operators have invested heavily in 5G infrastructure, but many still struggle to launch new enterprise services, onboard partners or commercialise network capabilities quickly enough to capture the opportunity. The bottleneck is often not the network itself. It’s the software architecture behind it.
As a result, the conversation around API-first BSS/OSS has shifted. What was once viewed as a technical modernisation initiative is rapidly becoming a business imperative. Operators that can move quickly are much better positioned to monetise emerging services and partnerships. For operators that cannot afford to watch competitors capture new opportunities first, speed and agility are crucial.
The spending paradox at the heart of telecoms IT
There is a statistic that should focus every CTO and CIO in the telecoms sector. According to EY’s analysis, 98% of telecom operators report they need to modernise their BSS platforms to enable new 5G-driven services. Yet for most, that modernisation is still not happening fast enough because legacy architectures have made change extraordinarily expensive.
For many operators, the challenge is not a lack of investment. Telecom companies collectively spend billions every year on IT transformation programmes. The problem is where that money goes. A significant proportion of technology budgets remains tied up maintaining ageing systems, supporting bespoke integrations and managing technical debt accumulated through years of mergers, acquisitions and incremental upgrades.
The consequences are becoming increasingly visible. New products take longer to launch than expected. Partner onboarding remains resource-intensive. Even relatively simple changes often require multiple teams and lengthy testing cycles. Innovation is not being held back by a lack of ideas but by architectures that make execution slow and costly.
What API-first actually means and what it does not
The term ‘API-first’ has accumulated enough hype to obscure what it actually describes. It is worth being precise.
An API-first BSS/OSS architecture is one in which core capabilities, such as billing, product catalogue, order management, customer data and network inventory, are exposed through standardised, well-documented interfaces that become the primary way of interacting with the system. They drive how users access functionality, how other systems connect, how partners consume services and how automation tools interact with operational data.
This is different from just having APIs. Most operators already have APIs in the sense that they have built integrations between systems. The distinction is whether those APIs are treated as the foundation of the architecture, or whether they are bespoke connectors layered onto tightly coupled systems. In an API-first model, capabilities are standardised and composable, making it easier to support new user journeys, partner models and emerging AI-enabled use cases, including secure access to system data through approaches such as Model Context Protocol (MCP).
The industry is increasingly converging on a standardised API-first BSS/OSS approach, where capabilities are exposed through composable, well-documented APIs rather than tightly coupled integrations.
The industry standard for this is the TM Forum Open API suite, a collection of more than 100 standardised interfaces covering the full range of telecoms business operations. The widespread adoption of these across the industry reflects growing convergence around a common approach to interoperability.
Operators building or procuring systems that conform to TM Forum Open APIs are, in effect, building towards a future where integration is no longer a permanent source of cost and complexity. Instead, it becomes a foundation for agility and innovation.
The 5G and B2B opportunity that brittle systems cannot reach
The timing of this conversation matters.
The real risk for operators is not that their systems are old. It is that competitors with more flexible architectures can turn new network capabilities into revenue faster.
The deployment of 5G infrastructure and the capabilities it enables around network slicing, edge computing and dynamic quality of service are creating significant commercial opportunities. Yet many existing BSS/OSS architectures are structurally unable to support them efficiently.
Network slicing provides a useful example. Delivering these services requires operators to define, price, provision and bill for connectivity with specific performance characteristics, often on demand and potentially for short durations. That level of flexibility was never a design requirement for many legacy product catalogues and billing platforms.
Operators with API-first architectures are better placed to expose these capabilities to enterprise customers and third-party developers through clean, programmable interfaces. Operators without them may face weeks or months of custom integration work every time a new use case emerges.
The same constraint applies to the partner ecosystem model that underpins much of the business case for 5G. Success in enterprise markets depends heavily on collaboration with hyperscalers, system integrators, independent software vendors and sector-specific specialists. These relationships require fast onboarding processes and interfaces that partners can build against without extensive involvement from internal integration teams.
This is where the gap between operators with modern architectures and those still reliant on legacy systems becomes commercially decisive.
Time to market is no longer a secondary consideration. It is becoming one of the primary determinants of which operators capture value from enterprise 5G services and which are relegated to providing commodity connectivity.
Operators with API-first architectures can move from concept to launch far more quickly. Those dependent on brittle, bespoke integrations often find that technical work begins to dominate the timeline before a service ever reaches the market.
The benefits of this shift are already visible in practice. One example comes from OpenNet in Denmark, which has developed a centralised wholesale fibre platform connecting infrastructure owners and service providers through standardised integrations and onboarding processes.
Reflecting on the programme, René Skjøde Andersen, Head of Programme at OpenNet, said:
“We saw an opportunity to transform the fibre market in Denmark. By working with Cerillion, we have created a centralised platform that benefits both Infrastructure Owners and Service Providers, and ultimately delivers greater choice and better service levels to end customers.”
This type of model illustrates the broader direction of travel across the industry: reducing friction between systems, partners and processes to enable faster service creation and delivery. By standardising the way partners connect, onboard and transact, operators can create more scalable ecosystem models without relying on bespoke integration work for every new relationship.
Why transformation projects fail and how to avoid the common traps
It would be misleading to suggest that moving to an API-first architecture is straightforward. The history of BSS/OSS transformation is littered with projects that ran over time, over budget and underdelivered on their objectives.
Understanding why these programmes struggle is just as important as understanding the destination.
The most common failure mode is scope. Operators attempting to replace their entire BSS/OSS stack through a single large-scale transformation programme are taking on a level of complexity that very few organisations can manage successfully.
The integrations that need to be untangled are not always documented. The business processes embedded within legacy environments are not always fully understood until transformation begins. The result is often escalating costs, delayed timelines and programmes that ultimately deliver less than originally intended.
A more reliable approach is incremental modernisation.
This does not mean avoiding difficult decisions. It means identifying which capabilities would generate the greatest business value if exposed through modern APIs and prioritising those first. Product catalogue management and partner onboarding are often strong candidates because they offer high impact, relatively contained scope and measurable outcomes.
Success in these areas can help build organisational confidence while creating momentum for wider transformation efforts.
The second trap is standards drift. Operators that build proprietary API layers, even well-designed ones, risk solving today’s integration challenges while creating tomorrow’s.
The value of aligning with TM Forum Open APIs extends beyond technical interoperability. It provides access to a broader ecosystem of vendors, partners and system integrators already working to the same standards, reducing integration costs and accelerating future innovation.
The third, and perhaps most overlooked, challenge is organisational.
API-first transformation is not solely a technology project. It requires changes to operating models, governance structures and skillsets. Teams accustomed to managing tightly coupled environments must adapt to more modular approaches. Processes built around monolithic release cycles must evolve to support more frequent delivery and change.
Without addressing these organisational factors, the benefits of modern architecture may never fully translate into business outcomes.
What a realistic starting point looks like
For operators that recognise the need for change but are uncertain where to begin, several principles can help.
First, establish an honest assessment of the current environment. This means understanding not only which systems exist, but also how integrations work, what they cost to maintain and which business processes depend on them. Many organisations underestimate transformation complexity because this baseline information is incomplete.
Second, define the target architecture in terms of business outcomes rather than technology choices.
The key question is not which platform to procure. It is what the organisation needs to be capable of achieving in three to five years and what architectural foundations are required to support those goals.
This keeps transformation programmes focused on commercial priorities rather than technology preferences.
Third, prioritise adherence to open standards from the outset.
TM Forum Open APIs provide a mature and widely adopted framework for interoperability. Solutions built around these standards are typically easier to integrate, easier to extend and easier to support over time. They also position operators to participate in broader industry initiatives such as Open Digital Architecture (ODA), which continues to advance the vision of a composable telecoms technology stack.
This foundation is also becoming more important as operators introduce greater automation across sales, service, fulfilment and assurance. AI-enabled tools and agentic workflows can only act reliably when the underlying systems expose consistent, governed and well-documented capabilities. Without that foundation, automation risks becoming another layer of complexity on top of already fragmented systems.
The window is narrowing
Telecoms has historically been an industry that tolerated slow progress on infrastructure modernisation. That tolerance is rapidly disappearing.
The combination of 5G enterprise opportunities, rising ecosystem expectations and growing competition from digital-native providers is compressing the timeframe within which operators can realistically close the gap.
The next telecom divide will not simply be between operators with and without 5G. It will increasingly be between operators that can commercialise new capabilities quickly and those that cannot.
In that environment, API-first architecture stops being an IT modernisation project and becomes a competitive strategy.
Operators that move with clear goals and standards-based platforms will be better positioned to capture the value of the next wave of enterprise connectivity services. Those that wait may discover that the real cost of legacy systems is not only maintenance spending, but the revenue opportunities they were too slow to seize.
