8.515 min read

Migration & Coexistence Patterns

No telco builds BSS/OSS from scratch. Every transformation project starts with a legacy landscape — systems that are running, serving customers, and generating revenue right now. The most technically elegant target architecture is worthless if you cannot get there from where you are today.

This section covers the practical reality of BSS/OSS migration: how to move from legacy to modern without disrupting operations, the patterns that make coexistence manageable, and the mistakes that have derailed some of the industry's most expensive transformation programmes.

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.
— Common telco architect wisdom

The Reality of Legacy BSS/OSS

Before discussing migration patterns, it is essential to understand why legacy BSS/OSS systems are so difficult to replace. This is not simply a technical problem — it is a business continuity challenge.

Why Legacy BSS/OSS Is Hard to Replace

Factor	Reality	Impact on Migration
Customer data volume	Millions of customers with decades of history, orders, bills, interactions	Data migration is measured in months, not days. Data quality issues surface during migration.
Product complexity	Hundreds or thousands of active product offerings, many with custom pricing rules	Legacy catalog semantics must be preserved in the new system. Remodelling is risky.
Integration web	Legacy BSS/OSS has dozens of integrations with network, partners, finance, regulatory	Every integration must be cut over or maintained in parallel during migration.
Tribal knowledge	Critical business rules live in stored procedures, batch jobs, and the heads of senior staff	Undocumented rules surface as bugs during migration. Regression testing is painful.
Revenue risk	Billing errors during migration directly impact revenue. Regulators notice.	Billing migration is typically the last and most cautious phase.
Ongoing operations	The legacy system must continue serving customers during the entire migration period	Parallel operations double the operational burden and support complexity.

The Big-Bang Fallacy

The biggest mistake in BSS/OSS transformation is attempting a "big bang" cutover — turning off the old system on Friday and turning on the new system on Monday. This approach has a catastrophic failure rate in telco. The complexity of data, integrations, and business rules almost guarantees that the new system will not handle every edge case. Always plan for phased, incremental migration with extended coexistence.

Strangler Fig Pattern

Named after the strangler fig tree that grows around a host tree and eventually replaces it, this pattern incrementally migrates functionality from legacy to new systems. New features are built in the new system from day one. Existing features are migrated one by one. The legacy system gradually loses responsibility until it can be decommissioned.

Imagine the legacy BSS handles everything: CRM, catalog, ordering, billing. The strangler fig approach: (1) Put an API gateway in front of the legacy system. (2) Build a new Product Catalog service. Route catalog requests to the new service. (3) Build a new Order Management service. Route order requests to the new service. (4) Continue until billing is the last piece. Migrate billing. (5) Decommission the legacy system. At every step, only the routed functionality changes — everything else continues through the legacy system.

Strangler Fig Migration Sequence

Intercept Layer

Infrastructure

Deploy an API gateway / reverse proxy in front of all legacy system interfaces. All existing consumers (channels, integrations) continue to work unchanged — the gateway passes through transparently.

New Product Catalog

BSS — Catalog

Build the new catalog service. Migrate catalog data. Route TMF620 (Catalog) requests to the new service. Legacy ordering still works — it reads from the new catalog via the gateway.

New Digital Channels

Engagement Layer

Build new BFF and frontend. New channels use the new catalog directly and submit orders via the gateway. Legacy channels continue unchanged.

New Order Management

BSS — Ordering

Build new COM. Route new orders through new COM. Legacy orders in flight continue in legacy system until completion. New products use new COM; legacy products continue through legacy COM.

New Service Fulfilment

OSS — Fulfilment

Build new SOM and ROM. New orders are fulfilled by new OSS. Legacy orders with legacy products continue through legacy fulfilment stack.

Billing Migration

BSS — Billing

Last to migrate. Run parallel billing validation (shadow billing) for months before cutover. Migrate customers in cohorts, not all at once.

The routing layer in a strangler fig migration can route based on multiple criteria:

By product type: New products (launched after migration start) always use the new system. Legacy products stay on legacy until migrated.
By customer segment: Migrate postpaid before prepaid, or consumer before enterprise. Each segment has different complexity.
By API endpoint: Catalog APIs route to new system first; billing APIs route to legacy until billing migration phase.
By geographic region: Migrate one region at a time, using region as the partition key.
Canary routing: Route 1% of traffic to the new system, compare results with legacy, gradually increase percentage.

Coexistence Patterns

During migration, the legacy and new systems must coexist — often for months or years. Several patterns manage this coexistence, each with different trade-offs.

Pattern 1: Parallel Run

Parallel Run

Both legacy and new systems process the same transactions simultaneously. Outputs are compared to validate that the new system produces correct results. The legacy system remains the "system of record" until confidence in the new system is established. Most commonly used for billing migration.

Parallel Run Characteristics

Aspect	Detail
When to use	Critical systems where errors have financial or regulatory impact — primarily billing and rating
How it works	Both systems receive the same input (usage records, orders). Outputs (bills, charges) are compared automatically.
Duration	Typically 2-6 billing cycles (months) before cutover
Cost	High — you are running and supporting two systems simultaneously
Exit criteria	New system produces identical outputs (within tolerance) for N consecutive cycles
Risk	Parallel run can become permanent if differences are never fully resolved — "permanent coexistence" trap

Pattern 2: Phased Migration by Cohort

Phased Migration by Cohort

Customers or products are divided into cohorts. Each cohort is migrated independently, in sequence. Once a cohort is migrated, it runs entirely on the new system. Legacy system handles remaining un-migrated cohorts. This is the most common pattern for large-scale BSS migration.

Phased Migration Sequence

Define Cohorts

Planning Phase

Group customers by segment, product, region, or complexity. Start with the simplest cohort (e.g., new customers, single product).

Migrate Cohort 1 (Pilot)

Pilot Phase

Migrate 1-5% of customers (simplest segment). Full data migration, integration switch, validation. Learn and fix issues.

Migrate Cohort 2-N

Migration Waves

Migrate subsequent cohorts in increasing size and complexity. Each cohort applies lessons from previous cohorts.

Final Cohort (Complex)

Final Wave

Migrate the most complex customers last — enterprise, custom contracts, multi-product bundles. These require the most manual intervention.

Legacy Decommission

Decommission Phase

Once all cohorts are migrated and validated, decommission the legacy system. Maintain read-only archive for regulatory/audit purposes.

Pattern 3: New Product Stack

Instead of migrating existing customers, launch new products exclusively on the new system. Legacy customers stay on the legacy system until their products are end-of-life. This avoids the most painful part of migration — data migration for existing customers.

Pro: No data migration risk for existing customers
Pro: New system proves itself with new products before handling legacy complexity
Pro: Natural attrition moves customers to new products over time
Con: Extended coexistence period — legacy may run for years
Con: Operational burden of supporting two full stacks
Con: Customer support must understand both systems
Con: Some customers may never naturally migrate — forced migration may still be needed

Example: Telco Launches 5G on New Stack

A telco launches 5G FWA (Fixed Wireless Access) on the new BSS/OSS stack while existing fibre and mobile customers remain on the legacy stack. 5G customers are the pilot for the new system. Over 18 months, the new stack is proven. Then fibre customers are migrated in cohorts. Finally, mobile customers are migrated. Legacy stack is decommissioned after 3 years.

Data Migration Strategies

Data migration is typically the most underestimated and most painful part of BSS/OSS transformation. The challenge is not just volume — it is data quality, semantic mapping, and business rule preservation.

Data Migration Approach

Data Migration Strategies

Strategy	How It Works	Best For	Risk
Big Bang Migration	All data migrated in a single window (e.g., weekend cutover)	Small operators, simple data models	High — if migration fails, rollback is complex
Trickle Migration	Data migrated continuously in small batches, synchronised via CDC or ETL	Large operators, minimal downtime tolerance	Medium — complexity of keeping both systems in sync
On-Demand Migration (Lazy)	Customer data migrated when they next interact with the new system	Low-activity customers, gradual transition	Low migration risk, but extended dual-system period
Rebuild from Source	Ignore legacy data structures; rebuild entities from source-of-truth records	When legacy data quality is poor or model mismatch is severe	High effort but produces cleaner data in new system

Data Quality Challenges

Legacy BSS data quality is almost always worse than expected. Common issues that surface during migration:

Orphan records — orders without customers, services without products, resources without services
Duplicate customers — multiple customer records for the same person, created by different channels over years
Inconsistent states — products showing "active" in billing but "terminated" in CRM
Missing mandatory fields — fields that are required in the new system but were optional (or non-existent) in legacy
Legacy codes and enums — product codes, status values, and categorisations that have no equivalent in the new model
Temporal data — historical records that reference products, prices, or rules that no longer exist in the catalog
Character encoding — legacy systems using different character encodings (Latin-1 vs UTF-8), causing data corruption during migration

Data Migration Non-Negotiables

Three things that must be true for successful data migration: (1) Profile the data first — run data quality analysis on the legacy data before writing a single line of migration code. Understand what you are working with. (2) Build a reconciliation framework — after every migration batch, automatically compare counts, totals, and checksums between legacy and new system. (3) Plan for a data cleansing phase — allocate 30-40% of migration time to data cleansing and exception handling. The migration tool will handle 80% of records; the other 20% require manual investigation.

Data Quality Resolution Strategies

Identifying data quality issues is not enough — you need a systematic resolution strategy for each issue type. The following decision framework prevents ad-hoc handling that introduces new inconsistencies.

Data Quality Issue Resolution

Issue	Resolution Strategy	Decision Criteria	Fallback
Orphan records (order without customer, service without product)	Attempt to re-parent by matching on secondary keys (phone number, address, date range). If match confidence > 90%, auto-associate.	If match confidence is low or multiple candidates exist, route to manual investigation queue.	If unresolvable within the cleansing window, quarantine the record. Do not migrate orphans into the new system — they create data debt from day one.
Duplicate customers	Apply match-and-merge rules: match on name + address + date of birth (or business registration number for B2B). Designate the most recently active record as the surviving master.	When duplicates have conflicting data (different email, different billing address), present to a data steward for manual resolution.	If the merge would affect in-flight orders or active billing, defer the merge until those processes complete. Migrate both records with a "pending merge" flag.
Inconsistent states (active in billing, terminated in CRM)	Determine the authoritative source for each entity's lifecycle state (SoR rules). The SoR system's state wins.	If the SoR system's state is ambiguous (e.g., no clear timestamp), use the most conservative state (assume active) and flag for post-migration review.	Create a reconciliation report of all state conflicts. Schedule a post-migration cleanup sprint specifically for these records.
Missing mandatory fields	Apply default values where a safe, deterministic default exists (e.g., country = operator's home country, ipVersion = IPv4). For fields with no safe default, mark as "data incomplete."	If the field is mandatory for fulfilment or billing (e.g., service address), the record cannot be migrated silently. Route to a data enrichment queue.	If enrichment is not possible before migration, migrate with a "requires enrichment" flag and trigger a customer outreach process post-migration.
Legacy codes with no target equivalent	Build a mapping table: legacy code → target catalog entity. Validate the mapping with business stakeholders before migration.	If a legacy product code maps to multiple target entities (ambiguous mapping), resolve by examining the customer's actual service configuration, not just the product code.	If no mapping is possible (truly obsolete legacy product), migrate the customer record without the product link and flag for manual product re-association.

The 80/20 Rule of Data Migration

In every BSS migration, approximately 80% of records migrate cleanly through automated rules. The remaining 20% require manual investigation and resolution — but they consume 60-70% of the total migration effort. Budget and plan for this explicitly. Teams that assume 95%+ automation discover the reality too late, after the programme timeline is committed.

Anti-Corruption Layer Pattern

Anti-Corruption Layer (ACL)

An Anti-Corruption Layer is a translation layer that sits between the new system and the legacy system, preventing the legacy system's data model, terminology, and quirks from "leaking" into the new system. The ACL translates between legacy and new domain models in both directions. It is a critical pattern during coexistence.

Without an ACL, the new system inevitably starts incorporating legacy data structures, legacy field names, and legacy business rule quirks — defeating the purpose of modernisation. The ACL is the immune system that keeps the new architecture clean.

Model mismatch: Legacy uses "subscriber" with a numeric ID; new system uses "customer" with a UUID. The ACL maps between them.
Status mapping: Legacy has 47 order statuses (including "HOLD_FOR_REVIEW_2"); new system has 8 TMF-aligned statuses. The ACL maps the semantics.
Data enrichment: Legacy order references a product code; new system needs a full product offering reference. The ACL looks up and enriches the data.
Protocol translation: Legacy exposes SOAP/XML APIs; new system uses REST/JSON. The ACL translates the protocol.
Business rule translation: Legacy applies VAT differently based on legacy product codes; new system uses standard tax rules. The ACL maps between fiscal treatments.

Dual-Stack Operations

During migration, operations teams must support two systems simultaneously. This "dual-stack" period is the most operationally challenging phase of any transformation. Planning for it explicitly is essential.

Dual-Stack Operational Challenges

Challenge	Impact	Mitigation
Split customer support	Agents must know which system a customer is on and use the correct tools	Unified agent desktop that queries both systems. Visual indicator of which system owns the customer.
Split reporting	Business reports must combine data from both systems for accurate totals	Unified data warehouse that ingests from both systems. Clear source labelling on every metric.
Dual monitoring	Operations must monitor both systems for faults, performance, and SLA compliance	Unified monitoring dashboard. Shared alerting thresholds.
Cross-system processes	Some processes span both systems (e.g., customer on new system orders a legacy add-on)	Orchestration layer that routes sub-orders to the correct system. ACL handles translation.
Dual skill sets	Support teams must be trained on both legacy and new system simultaneously	Dedicated "tiger team" for new system. Legacy team continues BAU.
Change management	Changes to legacy must not break new system integrations, and vice versa	Integration contract testing. Freeze non-essential legacy changes during migration.

Dual-Stack: The Customer View

A contact centre agent receives a call from a customer. The agent desktop queries both systems via the ACL. The screen shows: Customer is on the new BSS for mobile (migrated) but still on legacy BSS for broadband (pending migration). The agent can manage mobile through new BSS screens and broadband through legacy screens — ideally within the same unified desktop. When the customer asks about their total bill, the desktop aggregates billing data from both systems.

Common Migration Pitfalls

BSS/OSS migration programmes have a high failure rate. Understanding the most common causes of failure helps avoid them.

Pitfall 1: Underestimating Data Migration

Teams consistently allocate 10-15% of the programme budget to data migration when the actual effort is 30-40%. Data profiling, cleansing, mapping, migration tooling, reconciliation, and exception handling are each substantial workstreams. Budget and schedule data migration as a first-class programme stream, not a technical footnote.

Pitfall 2: Replicating Legacy in New System

The new system should implement the target operating model, not replicate every legacy quirk. If you migrate every legacy workaround, custom field, and non-standard process into the new system, you have not transformed — you have just re-platformed. Accept that some legacy capabilities will be simplified or dropped. Engage business stakeholders early to agree on what changes.

Pitfall 3: No Rollback Plan

Every migration step must have a rollback plan. If cohort 3 migration fails, can you revert those customers back to the legacy system? If the answer is no, you are taking an unacceptable risk. Rollback capability should be tested as rigorously as the forward migration.

Pitfall 4: Migrating Everything at Once

Attempting to migrate CRM, catalog, ordering, and billing simultaneously multiplies risk. Migrate one domain at a time, stabilise, then move to the next. The strangler fig approach exists precisely because sequential domain migration is safer than parallel domain migration.

Pitfall 5: Ignoring the Coexistence Period

Some programmes plan the target state but not the coexistence period. How will agents handle split customers? How will reports work? How will orders that span both systems be managed? If you cannot answer these questions before migration starts, you are not ready to migrate.

Pitfall 6: Freezing Legacy Too Early

Stopping all development on the legacy system "because we are migrating" sounds logical but is dangerous. The business still needs to launch products, fix bugs, and respond to regulatory changes. Plan for continued (limited) legacy development during the migration period. A full freeze creates business pressure that can derail the entire programme.

Realistic Migration Timelines

Setting realistic timeline expectations is critical for programme governance. BSS/OSS transformations take longer than anyone initially estimates.

Migration Timeline by Operator Size

Operator Size	Scope	Realistic Duration	Common Mistake
Small (< 500K subs)	Full BSS replacement	12-18 months	Underestimating integration complexity with network and finance systems
Medium (500K-5M subs)	Full BSS/OSS transformation	24-36 months	Underestimating data migration and billing validation
Large (5M-20M subs)	Phased BSS/OSS modernisation	36-48 months	Scope creep; attempting too many domains in parallel
Tier-1 (> 20M subs)	Multi-year transformation programme	48-72 months	Programme fatigue; changing requirements; vendor dependency

Source-of-Record During Migration

During coexistence, the most critical question is: which system is the source of record for each entity, for each customer? This must be explicitly defined and consistently enforced.

SoR During Phased Migration (Example)

Entity	System of Record	System of Engagement	System of Reference	Notes
Customer / Party	New CRM (for migrated customers) / Legacy CRM (for un-migrated)	Unified Agent Desktop queries both	—	Master record ownership transfers during customer migration. ACL synchronises both directions during coexistence.
Product Catalog	New Catalog (single source for all products)	CPQ, Digital Channels	Legacy ordering (via ACL)	Catalog is typically migrated first. Legacy ordering consumes new catalog through ACL.
Active Orders (In-Flight)	System where order was created	Channel where order was submitted	—	Orders in flight at migration cutover remain in legacy COM until completed. New orders go to new COM.
Billing	Legacy Billing (until billing migration phase)	Self-Service, Finance	New systems via ACL	Billing is the last migration phase. New COM feeds billing events to legacy billing via ACL during coexistence.
Service Inventory	New Service Inventory (for new services) / Legacy (for existing)	NOC, Service Management	—	Unified service view requires querying both inventories during coexistence.

Migration Success Factors

Executive sponsorship — BSS/OSS transformation is a business transformation, not just an IT project. CTO/CIO sponsorship is mandatory.
Dedicated migration team — not a side job for the BAU team. Migration needs its own team, budget, and governance.
Data profiling first — before writing migration code, profile and understand the legacy data. Find the skeletons early.
Clear exit criteria — for each migration phase, define measurable criteria for "done" (reconciliation thresholds, performance benchmarks).
Incremental migration — migrate in small, reversible steps. Prove each step before proceeding to the next.
Coexistence architecture — design the coexistence layer (ACLs, routing, unified views) as carefully as the target architecture.
Regression testing automation — automated regression tests comparing legacy and new system outputs. Manual comparison does not scale.
Business stakeholder involvement — business teams must validate every migration cohort. They spot issues that technical teams miss.
Realistic timeline — add 50% buffer to the initial estimate. Every BSS migration programme encounters surprises.
Legacy decommission plan — do not forget the endgame. Plan for legacy shutdown: data archival, regulatory retention, licence termination.

Section 8.5 Key Takeaways

Big-bang migration is almost always the wrong approach for BSS/OSS — use incremental strategies
The Strangler Fig pattern incrementally replaces legacy by routing traffic to new components one domain at a time
Parallel run is essential for billing migration — run both systems and compare outputs for months before cutover
Phased migration by cohort (starting with simplest customers) is the safest approach for large-scale migration
Data migration is consistently underestimated — budget 30-40% of programme effort for data profiling, cleansing, and reconciliation
Anti-Corruption Layers prevent legacy data models from contaminating the new architecture
Dual-stack operations require unified agent desktops, combined reporting, and explicit SoR rules per customer per domain
Every migration step must have a tested rollback plan
Realistic timelines: 12-18 months for small operators, 36-72 months for large operators
The hardest part is not the new system — it is the coexistence period and data migration