Running an MVNO is often described in terms of network wholesale costs, subscriber acquisition, pricing, and customer support. Those are visible expenses. The less obvious cost sits underneath the operation: the amount of time and manual effort required to make an old BSS stack keep working as the business changes.
Legacy BSS platforms can continue processing subscribers and invoices for years. The problem is that the cost of keeping them running isn't limited to software licenses. It appears in integration work, manual operations, slow product launches, reconciliation, support tickets, and the engineering effort required to connect newer services to older systems.
TM Forum has repeatedly highlighted the limitations of legacy BSS, including operational inefficiency, missed revenue opportunities, and difficulty supporting new commercial models. More recent TM Forum work is looking specifically at how CSPs can transform legacy BSS into more modular and AI-enabled architectures.
The Cost Isn't Just the BSS License
An MVNO may look at its BSS budget and see licensing, hosting, maintenance, and support costs. Those numbers are easy to put into a spreadsheet.
The harder costs are distributed across the organization. A product manager may wait for IT before launching a new tariff. An operations team may manually reconcile subscriber or usage records. Developers may maintain custom integrations because the BSS doesn't expose the required capabilities cleanly. Customer support may need several systems to investigate what should be a simple billing or activation problem. None of these activities necessarily appears as a line item called "legacy BSS cost." Together, however, they increase the operational cost of every subscriber.
Slow Product Changes Become Commercial Costs
MVNOs compete heavily through plans, bundles, promotions, and targeted offers. That means the product catalog isn't a static database; it is part of the commercial engine. A legacy BSS can make even relatively simple changes dependent on development or vendor intervention.
The workflow can become:
Product Decision
↓
Change Request
↓
BSS Configuration
↓
Development
↓
Testing
↓
Approval
↓
Production
When that process takes weeks, the MVNO loses more than engineering hours. It loses the ability to experiment quickly. TM Forum identifies faster time to market and the ability to support new commercial models as important drivers for BSS modernization. A modern architecture should separate ordinary product configuration from changes that genuinely require software development.
Manual Reconciliation Is an Expensive Hidden Tax
Billing, charging, provisioning, and wholesale network records don't always line up perfectly. A subscriber may be active in one system but missing from another. Usage records can arrive with different identifiers or timing. A plan change may be reflected correctly in the product catalog but incorrectly downstream.
When systems cannot reconcile these situations automatically, people become the integration layer. That means operations teams spend time comparing reports, investigating exceptions, correcting records, and confirming that the correction propagated successfully. At small subscriber volumes, this may be manageable. As an MVNO grows, the same process becomes increasingly expensive.
The technical issue is also architectural: legacy environments can contain tightly coupled systems, batch interfaces, and separate sources of truth. TM Forum migration discussions show why inventory and BSS modernization often require coexistence strategies, routing, synchronization, and carefully controlled migration rather than a simple system replacement.
Every Integration Can Become Technical Debt
Legacy BSS rarely operates alone. An MVNO may need integrations with:
MNO wholesale systems
Charging platforms
Payment gateways
CRM
SIM/eSIM management
Provisioning
Number portability
Customer applications
Data platforms
Fraud systems
Analytics
If the BSS wasn't designed around modern APIs, each integration can require custom middleware or point-to-point development. That creates a maintenance problem. When one upstream system changes, developers may have to modify several downstream interfaces. Over time, the integration layer becomes another legacy system that the team has to maintain. TM Forum's current modernization work emphasizes modular architectures, APIs, cloud-native platforms, and AI-enabled automation as ways to reduce this type of operational friction.
eSIM and IoT Expose the Weaknesses Faster
Older BSS platforms were often designed around relatively predictable subscription models. Modern MVNOs increasingly have to support eSIM, connected devices, multi-network connectivity, usage-based products, and more flexible commercial models. These requirements put pressure on systems that were designed around older workflows.
For example, an IoT customer might require thousands of devices, different usage thresholds, pooled data, automated activation, and device-level visibility. Trying to force all of that through manual BSS processes creates operational overhead.
The same applies to eSIM. When activation is expected to happen digitally, a workflow that depends on manual intervention becomes a bottleneck. The issue isn't that a legacy platform cannot perform a particular function. It is that the operational model around that function may no longer scale economically.
Support Teams Pay the Price Too
A customer calls because a plan change didn't take effect. The support agent now has to determine whether the problem is in the CRM, product catalog, order system, provisioning platform, charging engine, billing system, or network. If those systems don't share consistent state and visibility, troubleshooting becomes a manual investigation. That increases average handling time and often requires escalation to technical teams.
The customer sees a billing or activation problem. Internally, the company experiences it as a cross-system investigation. This is one of the hidden costs of legacy BSS: every poorly integrated backend process eventually becomes someone else's support workload.
Engineering Time Becomes the Most Expensive Resource
One of the biggest costs is opportunity cost. If developers spend their time maintaining legacy integrations, custom billing logic, batch jobs, and workarounds, that is time they aren't spending on APIs, automation, customer experience, analytics, or new telecom products.
TM Forum's 2026 research makes a similar point in the broader CSP context: many operators have struggled to establish a clear return on investment for replacing or modernizing existing BSS/OSS environments, even though the limitations of those environments constrain innovation.
The question therefore shouldn't be only:
"How much does our BSS cost?"
A better question is:
"How much engineering and operational capacity does our BSS consume just to keep the business moving?"
Modernization Doesn't Have to Mean Rip and Replace
Replacing an entire BSS in one project is risky, particularly for an operating MVNO with active subscribers. A more practical approach can be incremental modernization.
For example:
Legacy BSS
|
+---- Keep stable functions
|
+---- API Layer
|
+---- Modern Product Catalog
+---- Digital Provisioning
+---- New Billing Services
+---- Analytics
+---- Automation
This approach allows the MVNO to modernize the functions creating the most operational friction first. TM Forum's current guidance around composable BSS specifically discusses incremental modernization, allowing operators to modernize high-impact modules without disrupting systems that still perform useful functions.
Where Telecom BSS Platforms Fit
Vendors take different approaches to solving these problems. Amdocs has a broad telecom BSS portfolio spanning customer, commerce, monetization, and network-related capabilities. Optiva focuses strongly on cloud-native monetization, charging, and BSS. MATRIXX Software is particularly associated with real-time charging and monetization. Telgoo5 provides telecom BSS capabilities covering areas such as billing, charging, customer management, product management, and APIs.
TelcoEdge Inc. takes a broader MVNO-platform approach around billing, provisioning, SIM/eSIM operations, API integration, automation, and revenue intelligence.The important point for an MVNO isn't simply choosing a newer vendor. The architecture needs to reduce the number of manual processes and custom integrations that created the original operational burden.
The Real Cost of Legacy BSS
Legacy BSS becomes expensive when the organization starts compensating for its limitations.
The product team waits for configuration changes. Operations reconciles data manually. Developers maintain integration code. Support investigates cross-system problems. Finance handles exceptions. Customers experience slower changes and more complicated service interactions.
Those costs rarely appear on the BSS invoice. They're spread across departments. That's why modernization decisions should consider total operational cost, not just licensing or infrastructure expenses. TM Forum's current work increasingly frames modernization around measurable outcomes such as faster product innovation, productivity, customer experience, and revenue growth. For an MVNO, the goal isn't necessarily to replace every legacy component immediately.
The better target is to identify which parts of the existing stack are slowing down the business, isolate them behind modern interfaces where possible, and gradually replace the areas where operational friction is highest.
The most expensive legacy BSS isn't necessarily the one with the highest license bill. It's the one that quietly makes every other part of the MVNO more expensive to operate.
Top comments (0)