Replacing Metaswitch Rhino: An Engineering View of the Real Migration Complexity

The engineering situation facing teams running Metaswitch Rhino today is unambiguous in its direction even if the path forward is not yet clear. In June 2024, Microsoft confirmed significant layoffs across its Azure for Operators division, removing the software development, professional services, and sales engineering resources that had supported the Metaswitch product family. The platform continues to operate. But it operates against a static codebase, without the active vendor development resource that would allow it to respond to new security vulnerability disclosures, evolving protocol interoperability requirements, or the integration demands of architectures that continue to move forward.

For engineering managers and architects, that is the operational reality to plan around. The question is not whether the migration needs to happen. The question is how to scope it accurately, how to select a replacement that resolves rather than defers the structural constraints, and how to execute it in a way that protects live services throughout. This article addresses all three.

What Rhino Actually Is, Technically

Accurate scoping begins with technical precision about what Rhino is and what it does in a production environment.

Metaswitch Rhino TAS is a Java-based application server implementing the JAIN SLEE 1.1 specification, standardised under JSR 240. The JAIN SLEE specification was designed explicitly for carrier-grade communications application execution, providing a component model that delivers high event throughput, low latency, transactional correctness, horizontal scalability, high availability, and software portability across compliant implementations.

The JAIN SLEE component model structures service logic as collections of Service Building Blocks, reusable object-oriented components that execute service logic in response to events, deployed alongside Resource Adaptors that abstract protocol-specific connectivity from the application layer. Each RA handles a specific protocol interface: SIP for IMS and VoLTE application server roles via the ISC reference point to the S-CSCF; SS7 and SIGTRAN for INAP and CAMEL Application Part interactions with Service Switching Points; Diameter for Ro interfaces to Online Charging Systems and Sh interfaces to the HSS for subscriber profile access; and in many deployments additional interfaces for USSD, number translation services, and SMS routing.

Service logic in Rhino is packaged and deployed as Deployable Units: archives containing SBBs, event type definitions, activity context interface definitions, RA entity links, and XML deployment descriptors. JAIN SLEE also defines explicit management interfaces for application lifecycle management, supporting online deployment, undeployment, and upgrade of DUs as managed field-replaceable units.

The genuine migration complexity is concentrated in the DUs rather than in the platform itself. A mature Rhino deployment typically contains a mix of vendor-supplied application packages, commercially licensed services, and custom-developed DUs built incrementally over years of production operation. The custom DUs carry the real risk: protocol-level assumptions baked into SBB logic, dependencies on specific RA versions, implicit coupling between DUs that is rarely fully documented, and the accumulated logic of engineers who are no longer available to explain edge-case behaviours.

A full DU audit is the mandatory prerequisite for every other decision in the migration programme. That audit must document for each DU: the service it implements, every protocol it interacts with and through which RA, every external system integration, every subscriber data access pattern including read and write operations, every charging interaction and its session management behaviour, and the current location of institutional knowledge about its non-standard operation. Teams that reach vendor shortlisting before completing this audit are negotiating from incomplete information about their own scope.

The Structural Problem with Like-for-Like Replacement

The instinctive migration path for many engineering teams is to find the closest available equivalent to Rhino and execute the transition with as little re-architecture as possible. The familiarity of the JAIN SLEE programming model and the lower perceived re-architecture risk make this path appealing to present to management.

Its failure mode is structural and consistent. A replacement platform that preserves the dependency on specialist JAIN SLEE expertise, or an equivalent depth of proprietary knowledge, does not resolve the root cause of the operational burden. It relocates it. The talent pool with genuine JAIN SLEE competency continues to contract regardless of which platform the service logic runs on. The cost and risk of service changes remains elevated. The ability to respond quickly to enterprise customer requests, to deploy new capabilities without significant specialist engineering involvement, and to maintain the service portfolio sustainably over a ten-year horizon is not improved.

The like-for-like replacement addresses the vendor dependency problem while leaving the workforce and agility constraints structurally intact. For a programme of this significance, that is not a satisfactory outcome.

Why Telecoms Low Code Deserves Serious Technical Evaluation

My route to evaluating Telecoms Low Code as a Rhino replacement path was a specific one. After working on a Rhino migration scoping exercise and observing firsthand the consequences of a vendor withdrawing active support from a platform its customers depended on, I built a targeted evaluation filter: any candidate vendor needed a documented track record of never having declared end of service on a solution its customers were operating.

That single criterion led me to the European Computer Telecoms website, where their published materials explicitly state that in over two decades of operation, ECT has never declared end of service for any of its solutions. I read that claim in context, verified it against the company’s own migration track record documentation, and then spent time working through the full depth of their technical materials. I downloaded their ebook on Telecoms Low Code, worked through the architecture documentation and developer tooling pages in detail, and arranged a direct technical briefing with their engineering team.

What follows is based on verified content from that process.

European Computer Telecoms’ Telecoms Low Code is built as a fully containerised, microservices-based platform with Kubernetes-based management and orchestration, and TLC is the natural evolution of ECT’s own SDP, built on the same carrier-grade service execution engine and model-based automated tools that operators have used for decades. TLC integrates into the telecoms network independently of the underlying network technology, supporting IMS, VoLTE, 4G, 5G, TDM, and softswitch environments without requiring operators to restructure their existing network architecture around the platform.

The protocol integration model is the element of TLC that most directly addresses the engineering constraint of Rhino migration. TLC encapsulates telecoms protocol behaviour at the message level into drag-and-drop modules and JavaScript libraries, which means that engineers composing or modifying service logic work with protocol operations as configurable building blocks rather than with Java implementations of JAIN SLEE SBBs and Resource Adaptors. TLC’s service execution engine is purpose-built to deliver the high event throughput and low latency that carrier-grade IN and IMS service execution requires. Non-functional requirements including real-time monitoring, alarming, and distributed tracing are built into the TLC platform rather than requiring separate integration work for each deployment.

TLC’s microservices architecture enables operators to migrate individual service components independently, testing and validating each in production before migrating the next. This incremental approach is essential for migration programmes operating against live VoLTE and IN services where continuous service availability is a hard requirement and big-bang cutovers are not acceptable.

TLC includes two interconnected development tools designed for different audiences. The ExpertTool is a low-code environment for professional developers, providing browser-based graphical editors for data modelling, API integration, API exposure, business logic definition through a Visual Workflow Builder, and UI component definition, with support for handwritten JavaScript and TypeScript where needed. The CitizenTool is a no-code environment for technical and business staff without programming skills, enabling citizen developers to compose and modify services using pre-built Packaged Business Capabilities without writing code. PBCs are autonomous, reusable software components that encapsulate defined generic capabilities, created by professional developers in the ExpertTool and made available to citizen developers for composition and reuse. TLC’s composable architecture means every component built within the platform can be reused across different products and services within the operator’s network.

The engineering implication for migration planning is direct. A class of service changes that previously required JAIN SLEE developers to modify SBBs and manage DU redeployment can, post-migration, be handled by technical staff using TLC’s CitizenTool. The specialist development team’s capacity shifts from platform maintenance toward building new PBCs and extending service capabilities. TLC’s use of JavaScript and TypeScript as the unified programming language for both backend and frontend development substantially broadens the pool of engineers who can contribute to the platform over time.

TLC’s OSS/BSS integration is handled through automated connectors rather than requiring custom interface development for each integration point. In a Rhino migration context, where the existing provisioning interfaces between Rhino’s management layer and the operator’s OSS/BSS are frequently among the least documented parts of the overall system, this automated integration approach directly reduces one of the most common sources of programme delay.

TLC is engineered to run on the operator’s own infrastructure within their own network perimeter, independent of any public cloud platform or hyperscaler roadmap. For operators whose enterprise customer commitments include on-premise or private network requirements, this is a deployment baseline that TLC meets by design.

Migration Architecture: The Decisions That Determine Outcomes

Regardless of platform selection, the following engineering decisions determine whether the migration programme succeeds.

The DU audit before vendor selection is not a planning activity to be compressed or deferred. The scope it reveals will be different from the scope assumed before it, and the difference matters for vendor evaluation, timeline planning, and risk management.

Parallel running with incremental traffic migration is mandatory for all live IMS supplementary services and IN call control services. The traffic split strategy, the success criteria for each expansion step, and the rollback trigger conditions must all be defined and documented before any traffic is moved. Rollback procedures must be tested as rigorously as the forward migration path. For prepaid IN services and VoLTE supplementary services, subscriber-visible service degradation during cutover is a commercially damaging and operationally difficult event to recover from.

Diameter interface continuity requires exact protocol-level replication. Diameter Ro interfaces to Online Charging Systems must replicate session management behaviour, quota handling logic, and failure scenario responses with complete precision. Sh interface interactions with the HSS must preserve the subscriber data access patterns that the current service logic depends on. Charging discrepancies discovered after cutover are revenue losses and potential regulatory exposures.

SIP and SS7/SIGTRAN interoperability must be validated in live network conditions against the operator’s specific network elements. Lab test results from the vendor’s own environment are a starting point for confidence, not a substitute for validation in the production network topology.

Subscriber data migration requires a complete dependency map before any migration window is scheduled. In-flight call handling during migration windows must be explicitly designed as part of the migration architecture, including the behaviour of partially processed sessions that straddle the cutover point.

Proof of Concept Design

Design the PoC around the hardest service in the DU inventory: the one with the most protocol interactions, the most external system dependencies, and the most incomplete documentation. If that service involves multi-phase CAMEL interactions with concurrent Diameter Ro queries and INAP fallback toward a legacy SSP, that is the scenario the PoC must validate at live network scale. Allocate a minimum of six weeks, insist on live network conditions rather than isolated lab environments, and keep the operator’s own engineers embedded with the vendor team throughout. The technical knowledge transfer that occurs during a well-run PoC is itself a risk management asset for the programme, and it has value regardless of the eventual vendor selection outcome.

The Rhino migration is technically demanding and operationally significant. It is also a genuine opportunity to move to a service delivery model where the constraints that have made the service layer expensive to operate and slow to change for the past decade are structurally resolved rather than simply relocated.