Transformation Strategy
How to get from the legacy estate to the target one: migration and coexistence patterns — strangler fig, cohort and product-by-product migration, anti-corruption layers, parallel run as verification — and a simulation of a product-by-product greenfield migration.
No telco builds BSS/OSS from scratch. Every transformation starts with a legacy landscape — systems that are running, serving customers, and generating revenue right now. The most elegant target architecture is worthless if you cannot get there from where you are today.
The hardest part of BSS/OSS transformation is usually not building the new system — it is keeping the old system running while you migrate away from it.
Why Legacy Is Hard to Replace
The Reality of Legacy BSS/OSS
| Factor | Reality | Migration Impact |
|---|---|---|
| Customer data | Millions of customers with decades of history | Data migration measured in months, not days |
| Product complexity | Hundreds of active offerings with custom pricing | Legacy catalog semantics must be preserved or deliberately simplified |
| Integration web | Dozens of integrations with network, finance, regulatory | Every integration must be cut over or maintained in parallel |
| Tribal knowledge | Critical rules live in stored procedures and senior staff's heads | Undocumented rules surface as bugs during migration |
| Revenue risk | Billing errors directly impact revenue. Regulators notice. | In an order-management- or catalog-first programme, billing usually moves last and most cautiously. A standalone billing replacement is a different programme — billing moves first, with the most rehearsal and reconciliation of any phase |
Migration Patterns
Migration Pattern Options
| Pattern | How It Works | Best For | Key Risk |
|---|---|---|---|
| Strangler Fig | A routing or interception layer (API facade, order router, event interceptor) sits in front of legacy. Capabilities — or slices of traffic — move to the new implementation one at a time and the router is re-pointed as each is proven, until nothing routes to legacy and it is retired. | Estates where a routing boundary exists or can be introduced (e.g. at the order or catalog API) — continuous, reversible migration | The routing layer becomes a critical dependency; state consistency across old and new; the last capabilities are the hardest to move |
| Phased by Cohort (customer-segmented) | Divide customers into cohorts (by segment, product, region). Migrate each cohort independently, starting with the simplest. | Large-scale BSS migration with millions of customers | Dual-stack operations; support must understand both systems |
| New Product Stack (product-by-product) | Launch new products exclusively on the new system. Legacy customers stay on legacy until products are migrated or reach end-of-life. This is not strangler: there is no routing layer moving existing traffic across. | Avoiding data migration risk; proving the new system first | Extended coexistence — legacy may run for years |
In practice
Product-by-Product Greenfield Migration
This is the phased-by-cohort pattern with the product as the cohort. Products move one at a time from a legacy BSS/OSS environment to a modern, catalog-driven target stack. Each needs catalog modelling, workflow implementation, install-base migration, billing migration with financial reconciliation to the ERP ledger, and operational data alignment before it can go live on the new stack.
The legacy stack keeps serving unmigrated products while the target stack takes over — product by product — until legacy can be decommissioned. Run the simulation to watch the dual-stack period play out.
Data Migration Realities
Data migration is the most underestimated part of BSS/OSS transformation. The challenge is not just volume — it is data quality, semantic mapping, and business rule preservation.
Data Migration Strategies
| Strategy | How It Works | Best For |
|---|---|---|
| Big Bang | All data migrated in a single window (e.g., weekend) | Small operators, simple data models |
| Trickle (CDC/ETL) | Data migrated continuously in small batches | Large operators, minimal downtime tolerance |
| On-Demand (Lazy) | Customer data migrated when they next interact | Low-activity customers, gradual transition |
| Rebuild from Source | Ignore legacy structures; rebuild from source-of-truth records | When legacy data quality is poor |
Anti-Corruption Layer (ACL)
An anti-corruption layer (ACL) translates between the legacy model and the new model at the boundary — identifiers, status values, data shapes and protocols (e.g. SOAP to REST) — so legacy terminology and structures do not leak into the new architecture. It translates semantics; it must not re-implement legacy business rules (pricing, eligibility, decomposition). Once it starts deciding rather than translating, it has become the translation layer that recreates legacy logic — the anti-pattern of embedding TMF components into legacy without semantic alignment. Without an ACL, the new system starts incorporating legacy structures, defeating the purpose of modernisation.
Common Migration Pitfalls
- Underestimating data migration — it is planned as an extract-and-load task, when most of the effort is cleansing, semantic mapping, reconciliation and repeated rehearsal at full volume
- Replicating legacy in the new system — migrating every workaround and custom field means you've re-platformed, not transformed
- No rollback plan — every migration step must have a tested rollback capability
- Migrating everything at once — sequential domain migration is safer than parallel
- Ignoring the coexistence period — how will agents handle split customers? How will reports combine data from both systems?
- Freezing legacy too early — the business still needs to launch products and fix bugs during migration
Realistic Timelines
Migration Duration by Operator Size
| Operator Size | Realistic Duration | Common Mistake |
|---|---|---|
| Small (< 500K subs) | 12-18 months | Underestimating integration complexity |
| Medium (500K-5M) | 24-36 months | Underestimating data migration and billing validation |
| Large (5M-20M) | 36-48 months | Scope creep; too many domains in parallel |
| Tier-1 (> 20M) | 48-72 months | Programme fatigue; changing requirements |
Key Takeaways
- Big-bang migration is almost always wrong for BSS/OSS — use incremental strategies
- Strangler Fig routes capabilities or traffic from legacy to new behind a routing layer, one at a time, until legacy is retired — new-customers-only is customer-segmented migration, not strangler
- Parallel run is a verification technique, not a migration strategy — for billing, reconcile both platforms' outputs over several bill cycles before cutover
- Data migration is consistently underestimated — plan it as a workstream with its own budget, rehearsals and reconciliation sign-off, not as a cutover task
- Anti-Corruption Layers prevent legacy data models from contaminating the new architecture
- Every migration step must have a tested rollback plan
- The hardest part is not the new system — it is the coexistence period and data migration