Cost & Budgeting
Modernization7 min read
Telecom migration services: how to plan an OSS/BSS, voice, or network migration without an outage
A carrier network has no maintenance window, customers notice a failed port within minutes, and billing has to stay right throughout. Here is how telecom migrations are planned, what good telecom migration services providers do differently, and the questions to ask before you hire one.
Working on something like this?
Get an estimateThe short version
- Telecom migration covers five different jobs: OSS/BSS, billing, voice and numbers, network, and cloud. Each has its own failure mode, so plan them separately even when they run together.
- There is no maintenance window. Old and new platforms run in parallel, traffic moves in batches, and every batch has a rollback that has been rehearsed.
- Billing is the migration within the migration. Run shadow bill cycles and compare them line by line before any customer is invoiced from the new system.
- Judge telecom migration services providers by how they roll back, not how they cut over. Ask what happened the last time a batch failed.
Telecom operators migrate constantly. Acquisitions bring a second billing system. A vendor ends support for an OSS platform. Copper and TDM switching are retired in favour of IP. Voice moves from on-premises PBX to SIP and cloud. Each of these is a telecom migration, and each carries a risk most IT migrations do not: the service is live, every minute of the day, and customers notice the moment it breaks.
This guide explains what telecom migration services cover, how a migration is planned so it does not cause an outage, the risks that matter, and how to choose between telecom migration services providers. It is written for operators, MSPs, and CPaaS providers planning a platform, network, or billing move.
What telecom migration services cover
"Telecom migration" is used for at least five different jobs. They often run together, but each needs different skills, so a provider strong at one is not automatically strong at the rest.
Cloud migration for telecom has its own constraints, from latency budgets to lawful intercept and CPNI, and we cover those on our cloud migration for telecom page. The rest of this guide covers the planning that applies to every type.
Why telecom migrations are harder than ordinary IT migrations
- No maintenance window. An enterprise system can go offline on a Sunday night. A carrier network cannot, so migration has to happen with traffic running.
- Regulated, coordinated events. A number port is agreed with the losing carrier and has a firm order commitment (FOC) date. It cannot slip quietly, and it cannot be retried at leisure.
- Billing continuity. Usage keeps arriving during the migration. Every call record has to be rated exactly once, by exactly one system.
- Emergency services. Address records for emergency calling have to move with the number. A migration that breaks them is a safety issue, not just a service issue.
- Systems that disagree before you start. Provisioning, billing, and CRM rarely hold the same truth. Migrating without reconciling them first moves the disagreement to the new platform.
Telecom migration planning: the five phases
1
Inventory and reconcile
List every service, number, circuit, rate plan, and integration, then reconcile provisioning, billing, and CRM against each other. This is where hidden services, unbilled lines, and orphaned numbers turn up, and it is far cheaper to find them now.
2
Design the target and the cut plan
Decide what moves, in what order, and what stays. Group customers and services into batches by risk, starting small and low-impact. Write the rollback for each batch before writing the cutover.
3
Migrate data and rehearse
Load the new platform from the reconciled data, then rehearse the cutover in full against a staging environment. Rehearse the rollback too. A rollback that has never been run is a hope, not a plan.
4
Run in parallel and cut over in batches
Old and new run together. Traffic and customers move one batch at a time, with checks after each one, and a batch that fails is rolled back on its own rather than stopping the whole programme.
5
Decommission deliberately
Keep the old platform readable until billing has closed cleanly for at least one full cycle on the new one, regulatory records are retained, and nothing still points at it. Then switch it off.
Good telecom migration planning services spend most of their effort on the first two phases. A plan that jumps straight to cutover dates usually means the reconciliation has not been done.
OSS/BSS and billing migration
The standard control for billing migration is shadow billing: run the new system on real usage for one or more cycles alongside the old one, compare invoices line by line, and explain every difference before a customer sees a bill from the new platform. Freeze rate plan changes during the comparison, or you will be chasing differences you caused yourself. For OSS migration, drain or freeze orders in flight at each batch boundary so no order is half on one platform and half on the other.
Number porting and voice migration
Bulk ports go wrong when they are treated as one event. Split them into batches, each with its own FOC date, test calls, and rollback, and dry-run the whole port against a staging environment first. In our telecom OSS/BSS case study, a bulk port-in was rehearsed twice and run as nine batches, each with its own rollback, so a bad batch stayed a bad batch rather than becoming a bad weekend.
Telecom network migration
Telecom network migration solutions, such as moving from TDM to IP or retiring a legacy switch, depend on testing the paths customers actually use: inbound and outbound calls, interconnect routes, fax and alarm lines that do not tolerate compression, and emergency calling. Build the test list from real traffic, not from the design document, because the design document never includes the alarm panel nobody remembers installing.
The risks that matter, and how to control them
How to choose telecom migration services providers
Most telecom migration services providers will describe a similar methodology. The difference shows in the detail of how they handle failure. Ask these questions in the first meeting:
Questions for telecom migration services providers
- Which of the five migration types have you delivered, and on which platforms?
- How do you reconcile our systems before planning, and what do you do with what you find?
- How do you decide batch size and order, and what is your go/no-go check between batches?
- Describe the last time a batch failed. What happened, and how long did rollback take?
- How do you run shadow billing, and who signs off on the differences?
- How do you handle emergency calling records and number porting coordination with the losing carrier?
- What monitoring is in place from the first batch, and who is on call during cutover?
- Who stays with us after cutover, and for how long?
Telecom migration consulting, delivery, or staffing?
Telecom migration consulting services providers range from advisers who write the plan to teams who deliver all of it. Decide which you need before you compare them.
If staffing fits, our IT staff augmentation for telecom screens engineers for OSS/BSS, mediation, and protocol experience. Our guide to staff augmentation vs a managed team explains the trade-off in more detail.
How long a telecom migration takes
Longer than a comparable enterprise migration, and almost all the difference is parallel running. The main drivers are how much reconciliation the inventory needs, how many billing cycles of shadow comparison the business wants, how many batches the risk profile calls for, and how long the old platform must stay readable afterwards. A provider who quotes a timeline before seeing the inventory is guessing. The same cost and timeline drivers appear in our guide to cloud migration cost.
Telecom migration support from Centricone
Centricone Technologies builds and integrates the software layer of telecom businesses: OSS/BSS integration, order-to-activate flows, rating and billing, SIP and VoIP engineering, and the monitoring around them. Migration work starts the same way as our other telecom software development engagements, by tracing one order end to end and reconciling the systems before anything moves.
If you are planning an OSS/BSS, billing, voice, or network migration, talk to our team. We will start with your inventory and your rollback plan, not a cutover date. You can also read how we approach the wider telecommunications industry.
Working through this on a real project?
Tell us what you are building. You will get a scoped estimate and an architecture you own, not a capability deck.
Common questions
Telecom migration services plan and carry out the move of telecom systems and services from one platform to another: OSS/BSS platforms, billing and rating, voice and phone numbers, network infrastructure such as TDM to IP, and telecom workloads moving to cloud. The work includes inventory and reconciliation, migration planning, data migration, batched cutover, and decommissioning.
By running old and new in parallel and moving traffic in small batches, each with its own tested rollback and a go/no-go check before the next. Rehearse the full cutover and rollback in a staging environment first, and monitor activation, call quality, and billing from the first batch so problems show up before customers report them.
Building a complete inventory of services, numbers, and integrations; reconciling provisioning, billing, and CRM; designing the target platform; grouping services into batches by risk; writing a rollback for each batch; rehearsing; and setting a decommissioning plan. Most of the effort belongs in inventory and reconciliation, before any dates are set.
With shadow billing. The new system rates real usage alongside the old one for one or more cycles, invoices are compared line by line, and every difference is explained before customers are billed from the new platform. Rate plan changes are frozen during the comparison, and each batch has a single cutover point for rating so no usage is billed twice or missed.
Ask which migration types they have delivered, how they reconcile your systems before planning, how they size batches, and what happened the last time a batch failed. Ask how they run shadow billing and handle number porting and emergency calling records. A provider who answers the rollback questions in detail has done this before.
Use consulting when you have a delivery team and need the plan, reconciliation approach, and risk review. Use an end-to-end delivery team when the migration is a one-off and your engineers are busy running the network. Use telecom engineering staffing when you will lead the migration yourselves but are short of OSS/BSS, billing, or SIP specialists.