The global transition of the telecom industry to the TM Forum Open Digital Architecture (ODA) is transforming infrastructure modernization approaches, requiring operators to move away from rigid monoliths toward flexible, autonomous, and cloud-native systems. For CTOs and IT architects, the primary challenge remains modernizing legacy BSS/OSS environments without interrupting business processes or risking catastrophic core downtime.
Why classic "rip-and-replace" no longer works in telecom
Attempting to replace the BSS/OSS core using a "rip-and-replace" approach carries critical risks for SLAs. Monolithic architecture tightly couples call processing logic, billing, and customer service. Under these conditions, any change or prolonged downtime can lead to service disruptions and loss of billing data.
Security during such migrations is equally critical. According to the ENISA Threat Landscape 2025 report, digital infrastructure and services accounted for approximately 27.7% of data breaches. Large-scale migrations create vulnerabilities that attackers can exploit, particularly in the fraud domain. According to the CFCA Global Fraud Loss Survey 2025, global losses from telecom fraud are estimated at $41.82 billion. Temporary loss of control over rating during a "hot" system swap increases these risks. Therefore, transformation should be viewed as a multi-year architectural roadmap rather than a one-time implementation.
Anatomy of Open Digital Architecture (ODA): from monolith to components
ODA provides a reference modular architecture that replaces monolithic BSS/OSS with a componentized, API-first structure. It is important to note that ODA is not a plug-and-play solution and does not guarantee the total absence of downtime risks. It is a tool for managing architectural complexity that requires strict adherence to standards.
Success in modernization is measured not by a complete system replacement, but by the successful decoupling of domains. To standardize interaction between different operator domains, TM Forum Open API specifications are used. This makes the internal logic of individual modules independent, laying the foundation for autonomous networks.
Migration algorithm: how to dismantle BSS/OSS without stopping billing
The most viable method is the gradual extraction of individual business functions (e.g., billing or CRM modules) from the monolithic core into independent cloud-native components. The step-by-step migration algorithm is as follows:
- Step 1: Audit and map current connections in the BSS/OSS monolith to define domain boundaries.
- Step 2: Deploy an API-first integration layer (domain decoupling) based on TM Forum Open API standards.
- Step 3: Isolate the first "pilot" domain (e.g., notification module or CRM) and migrate it to a cloud-native component.
- Step 4: Configure parallel operation of old and new components with dynamic traffic routing.
- Step 5: Gradually extract critical transactional systems (billing, MNP routing) and perform the final decommissioning of legacy modules.
API-first integration: connecting VoIP and AI agents via DooxSwitch
During evolutionary migration, there is a need to implement new services without interfering with the legacy core. The telecom practice of the Intecracy Group—an alliance of independent companies linked by partner agreements and share exchanges—offers the use of the DooxSwitch platform for this purpose. It is a carrier-grade VoIP platform (softswitch) with integrated real-time billing, LCR routing, and rating.
In the transition architecture, DooxSwitch acts as an API-first integration layer. It allows for the seamless connection of new VoIP services and AI agents. The platform handles traffic switching and rating, interacting with legacy systems through standardized interfaces. This maintains the functionality of the old BSS/OSS core while simultaneously allowing the operator to launch new services.
Security and compatibility: integration with registries based on UnityBase
Modern BSS/OSS architecture also requires secure integration with external systems, particularly government registries. To build secure enterprise components, develop a unified API contract, and comply with security policies, UnityBase platform mechanisms are used. UnityBase is a joint development by the companies of the Intecracy Group; InBase is a key, but not the only, developer of the platform.
UnityBase is a full-stack JavaScript low-code / model-driven platform. All data, interfaces, and APIs are generated based on a unified Domain metadata model, and the platform provides built-in security mechanisms: role-based access control (RBAC), row-level security (RLS), and detailed audit trails. Thanks to its DBMS-agnostic ORM and automatic REST API generation, the system allows for the standardization of data exchange between internal components and external registries. For high-load systems or those with increased security requirements, Enterprise or Defence editions of the platform are used.
Transitioning to ODA is a long-term architectural process. Combining standardized integration layers (such as DooxSwitch) and a reliable platform foundation (UnityBase) allows this migration to be carried out in a controlled manner, maintaining business continuity and reliably protecting the telecom operator's data.
FAQ
How to transition to ODA without stopping the billing system?
Migration should occur by gradually extracting monolithic functions into cloud-native components. First, a parallel API-first integration layer is deployed, after which individual modules are moved to the new environment with dynamic traffic routing, maintaining the functionality of the old core.
What are the benefits of using TM Forum Open API during OSS/BSS modernization?
TM Forum Open API standardizes interfaces for interaction between operator domains. This allows for the decoupling of the internal logic of different modules and transforms the system into a set of independent components, which significantly reduces architectural complexity.
How to integrate AI agents into a legacy telecom operator contact center?
This is achieved by implementing API-first integration layers (e.g., the DooxSwitch telecom platform). This approach allows new AI services to interact with the legacy BSS/OSS core without the need for deep modification or downtime.