Every BSS vendor now claims to be cloud-native. In 2026, that phrase is almost meaningless unless the vendor can explain how the platform behaves during a traffic spike, a failed pod, a partial upgrade, or a regional outage.
The distinction is simple: cloud-hosted means the software runs on cloud infrastructure; cloud-native means the software was designed around cloud operating principles: independent scaling, resilient state management, automated deployment, service-level recovery, and continuous delivery. A legacy system moved to a cloud VM may be useful, but it has not automatically become cloud-native.
The test that actually separates them
Do not begin with the vendor’s Kubernetes diagram. Ask whether rating, charging, mediation, invoicing, catalog, and order management can scale independently. If the entire platform must be scaled and deployed as one unit, it may be a containerized monolith: the packaging has changed, but the architecture has not.
The next question is where session and transaction state lives. If terminating a pod causes an active charging session, pending order, or usage transaction to disappear, compute and state are still tightly coupled. A serious platform should be able to recover processing on another instance, prevent duplicate charging, and replay events safely.
Then ask the vendor to demonstrate an upgrade. Is it a rolling or canary deployment with independently versioned services, backward-compatible APIs, automated rollback, and no full-platform maintenance window? Or does the whole system still go offline for a patch? “We run on Kubernetes” does not answer that question. Kubernetes can restart a process; it does not by itself make application state portable or upgrades risk-free.
The final test is failure handling. Ask what happens when a pod, node, database replica, message queue, or cloud region fails. The vendor should be able to explain recovery behavior, transaction continuity, replay protection, observability, and recovery objectives without retreating into generic language about high availability.
Where vendors appear to land
The market is not divided cleanly into cloud-native and non-cloud-native. Most established vendors have a mixed portfolio, with newer services and releases using more modern architectures than older components.
MATRIXX Software remains one of the more credible cloud-native stories in real-time charging. Its architecture is particularly relevant to 5G, IoT, and other high-volume monetization use cases. That strength should not automatically be interpreted as evidence that every surrounding BSS function has the same level of decomposition.
LotusFlare, Wavelo, Totogi, and similar digital-first platforms are generally more convincing when the requirement is a greenfield digital operator, MVNO, or rapid service launch. Their appeal is usually an API-first, event-driven architecture and faster provisioning rather than the broad functional depth of a traditional Tier 1 suite. Wavelo, for example, is positioned as a cloud-native, event-driven OSS/BSS platform, while LotusFlare describes its platform as built around microservices, containers, and APIs rather than lift-and-shift hosting.lotusflare+1
Amdocs, Netcracker, Ericsson, Nokia, CSG, and Optiva should be assessed more carefully at product and release level. These vendors have substantial cloud, SaaS, and modernization programs, but their portfolios contain different generations of software, deployment models, and acquired technologies. A new cloud-native charging or digital BSS product does not mean that an operator’s existing billing or customer-management stack has the same architecture.
Optiva is a particularly clear example of why release history matters. Newer versions may offer substantially more microservices-based deployment and cloud automation than older Optiva environments. An operator should therefore ask which generation is being proposed, what migration is required, and whether the modernization applies to the actual modules in scope.
For Telgoo5 and TelcoEdge, the key attraction is often speed and simplicity for MVNO and MVNE deployments. That can be valuable, but buyers should verify what is included natively. A platform may be cloud-native in its core commercial and subscriber workflows while relying on third parties for mediation, inventory, orchestration, analytics, or other OSS-adjacent functions.
The recurring cloud-hosted trap
The familiar pattern has not disappeared:
A vendor takes an existing VM-based application, places it on AWS or another hyperscaler, adds a load balancer or Kubernetes wrapper, and updates the marketing language. The operator then discovers during a traffic surge that the platform still scales as one large unit. During an upgrade, the entire system still requires a maintenance window. During a failover, session state remains tied to the failed instance.
The reference architecture usually gives this away. If it mainly shows VMs behind a load balancer, ask why. If Kubernetes is the central selling point but the vendor cannot describe service boundaries, independent scaling, state recovery, or rollback, the platform may be cloud-hosted rather than cloud-native.
That does not necessarily make it a bad product. A stable, well-operated cloud-hosted platform may be a better choice than an immature cloud-native one. The problem is treating both as equivalent when evaluating resilience, operating cost, release speed, and elasticity.
What to ask in procurement
Ask for evidence from the exact product release and deployment model being proposed—not a corporate architecture presentation.
The vendor should be able to show how individual services scale, what happens when an active charging or billing pod is terminated, how events are replayed without double processing, and how one service is upgraded while the rest of the platform remains available. Request the last production upgrade runbook, failure-recovery results, and references using the same version and operating model.
The most revealing question may be this:
“Show us what happens when we terminate the pod handling an active charging transaction.”
A mature vendor will explain the state model, recovery path, idempotency controls, monitoring, and expected customer impact. A weaker one will show another Kubernetes slide.