🏛️
Section 10.5
Migration & Coexistence Patterns
Strategies for migrating from legacy BSS/OSS: strangler fig, parallel run, and anti-corruption layers.
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 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. | Billing migration is always the last and most cautious phase |
The Big-Bang Fallacy
Turning off the old system on Friday and turning on the new system on Monday has a catastrophic failure rate in telco. The complexity of data, integrations, and business rules guarantees edge cases. Always plan for phased, incremental migration with extended coexistence.
Migration Patterns
Migration Pattern Options
| Pattern | How It Works | Best For | Key Risk |
|---|---|---|---|
| Strangler Fig | Put an API gateway in front of legacy. Build new services one at a time. Route traffic incrementally to new services until legacy can be decommissioned. | Most transformations — provides continuous, reversible migration | Routing complexity; extended coexistence period |
| Phased by Cohort | 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 | Launch new products exclusively on the new system. Legacy customers stay on legacy until products are end-of-life. | Avoiding data migration risk; proving the new system first | Extended coexistence — legacy may run for years |
| Parallel Run | Both systems process the same transactions. Outputs are compared. Legacy stays as SoR until confidence is established. | Billing migration — run 2-6 billing cycles before cutover | High cost; can become permanent if differences aren't resolved |
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 |
The 80/20 Rule
~80% of records migrate cleanly through automated rules. The remaining 20% require manual investigation — but consume 60-70% of total migration effort. Common issues: orphan records, duplicate customers, inconsistent states across systems, missing mandatory fields, and legacy codes with no target equivalent. Budget 30-40% of programme time for data cleansing and exception handling.
Anti-Corruption Layer (ACL)
An ACL is a translation layer between the new system and legacy, preventing legacy data models, terminology, and quirks from "leaking" into the new architecture. It maps between legacy and new domain models in both directions — translating entity IDs, status values, data shapes, and protocols (e.g., SOAP→REST). Without an ACL, the new system inevitably starts incorporating legacy structures, defeating the purpose of modernisation.
Common Migration Pitfalls
- Underestimating data migration — teams allocate 10-15% when the real effort is 30-40%
- 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 |
Section 10.5 Key Takeaways
- Big-bang migration is almost always wrong for BSS/OSS — use incremental strategies
- Strangler Fig incrementally replaces legacy by routing traffic to new components one domain at a time
- Parallel run is essential for billing — compare outputs for months before cutover
- Data migration is consistently underestimated — budget 30-40% of programme effort
- 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