Use case · Any provider with legacy BSS
Modernise BSS/OSS one domain at a time.
The big-bang cutover is why most modernisations fail.
The current stack has reached the end of what it can credibly carry. Every new product is a custom project. The vendor’s roadmap and yours have diverged. The instinct is to replace it, and the fear, justified by every horror story in the industry, is that the replacement programme runs for years, over budget, while the legacy system stubbornly keeps running half the workload. This is the journey that modernises the stack without stopping the business: domain by domain, value first, legacy retired only when the new model has proven itself.
Where you are
The stack works, barely, and it’s holding the business back.
The current BSS or OSS isn’t broken, exactly. It still bills, still provisions, still runs the business. But it’s reached the point where every new product needs custom development, every integration is fragile, and the cost of change has risen to the point where the commercial team has stopped asking for things because they know the answer is “not this quarter.” The platform that was supposed to enable the business has become the thing that constrains it.
The reason modernisation is frightening is that the obvious approach, replacing the whole stack, has a terrible track record. The replacement programme is large, the cutover is risky, and the business can’t stop while it happens. So the modernisation gets deferred, the stack ages further, and the constraint tightens. The way out isn’t a braver big-bang. It’s a different approach entirely.
The real dependencies
Six principles that separate modernisations that work from ones that don’t.
These aren’t novel. The discipline of holding to them when schedule pressure builds is what’s rare.
Coexistence before replacement
The new platform runs alongside the old before either carries the production load. Integration proven during coexistence, not after cutover.
Domain-by-domain migration
Move charging, then catalogue, then customer, then partner operations. Each a discrete project with its own go-live, rollback path, and payoff.
Value first
Sequence the migration so early domains deliver visible value early, funding confidence for the rest. Not the riskiest domain first; the one that proves the model.
Clear cutover criteria
Defined and signed off in advance per domain. The go/no-go is on the criteria, not on schedule pressure.
Data quality before automation
The silent killer of BSS programmes. Legacy data quality issues that teams worked around for years rarely survive contact with a new system. Addressed early, visibly.
Decommission only when proven
The legacy stack keeps paying the bills until the new one is demonstrably doing it better. Retire the old domain only after the new one has earned it.
The sequence
A staged path, each stage standing on its own.
The journey follows the platform’s own adoption pattern: simplify, automate, optimise. Each phase delivers before the next begins.
Phase 1
Assess and architect
Understand the current stack, define the target architecture, and sequence the migration into domains. The BSS/OSS architecture and migration engagement does this work.
BSS/OSS architecture and migrationPhase 2
Simplify (overlay)
fullCIRCLE NEXT runs alongside the existing stack, unifying the catalogue, customer record, and partner view. The complexity once carried in process moves to the platform. Nothing is removed yet.
DeploymentPhase 3
Automate (the first domains)
The first domains migrate to native modules. Often charging to nomia first, where the value is most visible and measurable. Governed by netra, executed by nova at the edge. Each domain proves the model before the next moves.
Phase 4
Optimise (the rest, on your schedule)
Remaining domains migrate as the roadmap allows. The legacy stack winds down domain by domain, retired only as each replacement proves itself. Often runs under a programme assurance overlay.
Programme assuranceA concrete near-term shape
What the first 90 days can look like.
The first 90 days is assessment and the first overlay, deliberately not a cutover:
- Weeks 1 to 6Current-state assessment. Target architecture defined. Migration sequenced into domains with cutover criteria.
- Weeks 7 to 10fullCIRCLE NEXT stood up as an overlay alongside the existing stack. Catalogue and customer view unified.
- Weeks 11 to 13First domain selected and its migration scoped in detail, with coexistence and rollback designed. The business case for the full programme built from the proven overlay.
The commitment is to prove coexistence and sequence the migration before any domain cuts over, so the programme runs on evidence rather than hope.
Platform, consulting, experience
The journey in one view.
Platform: deployment
Deployment and the phased adoption model carry the migration.
See deploymentConsulting: architecture and assurance
BSS/OSS architecture and migration, plus programme assurance.
See architecture and migrationExperience: migration without stopping the business
Operator cores migrated without stopping the business.
Read the experienceTell us what your current stack is doing to your business.
A stack that still works but constrains every new product, a replacement programme that feels too risky to start, and a constraint that tightens with every deferred quarter. The way out is domain by domain, and it starts with an honest assessment.