Solutions
Alepo Digital BSS
Telco Type
Mobile operator
Country
Kingdom of Eswatini
A Zero-Downtime BSS Migration: Eswatini Mobile
A case study of how Eswatini Mobile, the Kingdom of Eswatini’s third-licensed operator offering prepaid and postpaid voice, data, and roaming, replaced an underperforming SaaS BSS with an on-premise digital BSS, and what the placement decision, migration approach, and outcomes suggest for operators weighing the same move.
109 days
full migration, executed entirely remotely
Zero downtime
for the 235,000 subscribers migrated
1M+ subscribers
served on the platform today, 4x the migrated base
Churn reversed
after disruptions and lags were eliminated
Background
Eswatini Mobile, the holder of the Kingdom of Eswatini’s third operator license, was growing. On its legacy SaaS BSS, frequent network disruptions and connection lags were hurting customer satisfaction and driving churn. The operator committed to overhauling the platform before the damage compounded.
The Placement Decision: From SaaS Back to On-Premise
Against the prevailing cloud-by-default assumption, Eswatini Mobile moved its BSS on-premise, close to the mobile core, because for real-time charging and policy, proximity determines performance. Three further decisions shaped the program:
Speed over sequence
Churn from outages made time the critical variable. The migration was scoped for the fastest safe path and completed in 109 days, a fraction of the 9–18 months a full BSS replacement typically takes.
Single vendor, phased
The multi-vendor BSS estate was consolidated to one accountable platform in phases, cutting maintenance cost and resolution time.
Remote by necessity, proven by design
The entire deployment and subscriber migration ran remotely, with no vendor staff on site, supported by a dedicated 24/7 team.
Program Scope
The on-premise digital BSS covers online charging, CRM, policy control, prepaid product catalog, collections, partner and roaming settlement (42 roaming partners), mediation, analytics and BI reporting, and web and mobile self-care: a microservices-based, open-API architecture integrated with the mobile core, with operator-specific customizations built in rather than worked around.
What the Platform Supports
Rapid offer creation
A drag-and-drop policy and catalog interface lets marketing launch plans and promotions as the market moves: happy hours, data passes, zoned bundles, app-specific and roaming plans, enterprise and government tiers.
Customer-controlled services
Subscribers gift airtime and data, freeze accounts to prevent deactivation, and take airtime on loan in emergencies, each policy a revenue or retention lever.
Digital self-care
Web and mobile self-care provide 24/7 support and real-time audience targeting, reducing dependence on assisted channels.
Disciplined revenue operations
Automated bill runs with invoice notifications, advanced dunning for collections, and BI reporting to target offers at the right subscribers.
Outcomes
The on-premise deployment eliminated the network disruptions and lags that had been driving customers away, and churn reversed. Faster service creation and real-time targeting through self-care improved revenue margins within a few months of launch, and the single-vendor convergent platform significantly reduced OPEX within three months of deployment. The platform has since scaled with the operator’s growth and today serves more than one million subscribers, over four times the base it migrated, without replacement.
“Our primary objective is to offer superior customer experience and we’re consistently working on improving our services to meet our customers’ needs. Alepo’s phased approach to digital transformation has helped us bolster our network and services without disruptions. We intend to introduce a host of advanced and innovative plans in the future using the Alepo platform.”
Genius Sihlongonyane, Chief Information Officer, Eswatini Mobile
Placement proved to be a performance decision: for real-time charging and policy, distance from the mobile core shows up as latency the subscriber feels.
Migration speed was an economic choice: the monthly cost of churn set how long the replacement program could responsibly take.
The 235,000-subscriber cutover ran with no vendor staff on site, backed by a dedicated 24/7 team.
What to Verify When Deciding Where Your BSS Should Run
Checks drawn from this program, useful regardless of vendor:
Is your BSS’s distance from the mobile core showing up as latency, lags, or disruptions?
What is churn from network instability costing per month, and what migration speed does that justify?
How many vendors share accountability when your BSS fails, and who owns resolution?
Can your migration be executed remotely, or does your plan assume on-site presence?
What subscriber count and downtime tolerance define “safe” for your cutover?
