How to Migrate Telecom Customers to a New Platform Without Them Noticing
Updated: Sep 11
Service providers can migrate large customer bases from legacy platforms including Metaswitch, BroadWorks, and BroadSoft into NetSapiens while minimizing disruption to the end customer. The platform changes. The experience does not.
Providers can execute the technical cutover correctly and still create churn risk if the customer experience is disrupted.
The core insight: A technically successful migration can still create problems if customers experience disruption. The goal is not simply a clean cutover. It is a transition customers barely notice.
The pressure to migrate is real. So is the risk of getting it wrong.
Key Takeaways
Customer-facing disruption can increase support demand and churn risk.
Big-bang cutovers are high-risk. Staged, batched migrations dramatically reduce subscriber impact.
Automation reduces repetitive manual work and improves consistency.
Pre-migration validation helps identify issues before cutover.
Fuse.Cloud migrated to NetSapiens with Vox Matic and their COO reported: "Our customers barely noticed the transition."
Automation is what separates a repeatable migration process from a one-time engineering effort.
Why Do Customers Notice a Migration in the First Place?
Most migrations are planned as engineering projects. The subscriber experience is treated as a side concern, something to address if problems come up. That's exactly backwards.
Customers may notice a migration because of issues such as:
Credential resets: being forced to re-enter a password or re-authenticate an app
App reinstalls: receiving an IT email asking them to download a new softphone
Feature gaps: a call queue or voicemail behavior that worked differently on the old platform
Degraded call quality: even a day of choppy audio during transition
Lost call history or voicemail: data that wasn't carried over cleanly
Any one of these is enough to prompt a customer to ask: "Why is this happening? Should I be looking at other options?"
The migration isn't the risk. The visibility of the migration is.
The Big-Bang Problem
A "big-bang" cutover moves all subscribers at once on a set date. It's simpler to plan and feels cleaner on paper. The problem is it concentrates all the risk into a single window. If something goes wrong (a misconfigured call route, a failed number port, a device that doesn't register), every customer is affected simultaneously.
Staged migrations solve this by moving subscribers in controlled batches. Issues surface in a small group first, get corrected, and the next batch proceeds with a cleaner configuration. By the time the bulk of subscribers migrate, the process is refined and migration risk is significantly reduced.
What Does a Customer-Invisible Migration Actually Look Like?
Each stage has a specific job to do.
Phase 1: Automated Discovery Before Anything Moves
Before a single subscriber is touched, the source environment needs to be fully understood. At Vox Matic, this is the first step in every engagement. Otto is Vox Matic’s proprietary automated telecom migration framework. Our approach is automation first, expert engineering where required. Automated data extraction captures subscriber records, service configurations, inventories, and migration-relevant platform data from the source environment at scale, normalizing that data and mapping it to the NetSapiens configuration model before provisioning begins. Learn more about Otto and the Vox Matic approach.
Phase 2: Parallel Platform Provisioning
The new platform is built and validated while the old one keeps running. Customers can remain on the legacy environment while the target environment is prepared and validated, helping minimize disruption before cutover. Meanwhile, the target environment is configured, tested, and verified against the discovered baseline.
This parallel approach is what makes staged cutover possible. There is no artificial deadline forcing an early cutover. The migration proceeds when the environment is validated, not when a calendar date arrives.
Phase 3: Controlled, Batched Cutover
Subscribers move in controlled groups based on the provider's environment, migration plan, complexity, and cutover requirements. Each batch is monitored closely. If a configuration issue surfaces, it is resolved before the migration advances.
Each migration phase should include a defined contingency approach based on the provider's environment and cutover requirements.
Phase 4: Post-Migration Validation
After each batch, verify:
Check | What to validate |
Call quality | No reported degradation in audio quality from migrated accounts |
Device registration | Endpoint types tested and confirmed registering to the target platform |
Feature parity | Call queues, voicemail, hunt groups, and auto-attendants behaving as configured |
Routing behavior | DIDs and call flows validated against the source configuration |
Support ticket volume | Monitor inbound issues from migrated accounts for unexpected patterns |
Where Does Automation Change the Equation?
At scale, manual migration requires engineers to recreate and validate large numbers of subscriber records, devices, features, and configurations. The volume is not the problem. The variability is.
Automation changes this in three specific ways:
1. Improved consistency at scale. Subscriber accounts are provisioned using the same transformation logic. This reduces variability from engineer to engineer, minimizes missed fields, and helps prevent configuration errors that would otherwise surface during cutover.fix the links here. Not another Fuse quote but more generic
2. Speed that enables staging. Automation compresses repetitive migration work, making staged execution more practical at larger volumes. The slower manual provisioning is, the more pressure there is to consolidate batches, which increases risk. Automation removes that pressure and keeps the subscriber experience intact.
3. Pre-cutover conflict detection. Automated tools compare the source configuration against the target environment and flag mismatches before anyone moves. This helps identify issues that could cause disruption during cutover, so they are resolved during validation rather than after subscribers are affected.
Together, these change what is realistically achievable. Migrations that would take well over a year of manual engineering can be compressed into months, not by moving faster through the same steps, but by removing the repetitive work that made the timeline long in the first place. The engineering effort shifts from data entry to exception handling and validation, which is where experienced telecom engineers actually add value.
What Should You Tell Your Customers During a Migration?
Most operators underinvest in it. The technical plan gets detailed attention; the customer communication plan gets a template email sent the night before.
The goal of customer communication during a migration is to set clear expectations, reinforce continuity, and give customers a direct contact if anything feels different.
A practical communication framework:
Pre-migration notice (2-4 weeks out): Brief, plain-language message that a platform upgrade is coming. Focus on continuity, what is staying the same, and note any action required from the customer, if applicable.
Cutover confirmation (day of or day before): Short note confirming the scheduled window, the expected timing, and a support contact customers can reach if they notice anything unexpected.
Post-migration confirmation: A brief note that the upgrade is complete. Invite feedback and highlight any new capabilities available on the new platform.
What to avoid: Sending communications that make the migration sound more complex or uncertain than it is. If customers are required to take action, such as downloading an app, resetting credentials, or reconfiguring a device, make sure that is communicated clearly in advance, with straightforward instructions and a support contact.
A well-executed migration is designed to minimize the actions required from subscribers. When that goal is met, communication confirms a smooth experience rather than managing a disruption.
The Migration Checklist: What to Verify Before Any Subscriber Moves
Run through this before your first cutover batch. These are the items most likely to cause a visible disruption if missed.
Routing behavior validated: DIDs and call flows have been tested and confirmed routing correctly on the target platform
Device profiles confirmed: Endpoint types (desk phones, softphones, ATAs) have been tested and confirmed registering to the target platform
Call flows validated: Hunt groups, auto-attendants, call queues, and IVR logic have been validated against the source configuration
Voicemail functionality confirmed: Voicemail routing, greetings, and access have been tested and are functioning as expected
Required features active: Platform features required by the customer (call recording, analytics, conferencing) have been tested and confirmed functioning
Customer configurations reviewed: Complex or custom account configurations have been validated in the target environment prior to cutover
Cutover contingency defined: A contingency approach has been documented and tested based on the provider's environment and cutover requirements
Support team briefed: Your helpdesk knows the migration is happening, what to expect, and how to escalate quickly if needed
Monitoring in place: Visibility into call quality, device registration, and provisioning status is confirmed for the cutover window
Every environment has its own edge cases, but these are the items that generate the most subscriber-visible failures when missed.
Frequently Asked Questions
How long does a telecom customer migration typically take?
Timeline depends on the size of the subscriber base and the complexity of the source environment. Vox Matic's engagement with Fuse.Cloud reduced their expected timeline from approximately 18 months to 6 months using the Otto automation framework.
What is the biggest risk to the subscriber experience during a migration?
Customer-facing disruption can result from configuration differences, feature gaps, device behavior, routing issues, or degraded service during cutover. Pre-migration validation and controlled, staged execution help identify issues earlier and reduce the likelihood of customer impact.
Can we migrate without any downtime for customers?
Vox Matic designs migrations to minimize customer disruption and avoid noticeable downtime wherever possible. Automation, validation, testing, and controlled cutover help reduce migration risk and preserve service continuity. Exact customer impact depends on the source environment, target configuration, and cutover requirements.
How do we handle customers who have complex call flows or custom configurations?
Automated discovery captures configuration data from the source platform, including routing logic, multi-site setups, and custom feature configurations. This data is used to inform target platform provisioning and validate configurations before cutover.
What happens if something goes wrong after a batch moves?
A well-designed migration includes a defined contingency approach for each phase, based on the provider's environment and cutover requirements. Issues that surface after a batch moves are corrected before the migration continues, which is one of the core reasons staged migration reduces overall risk compared to a big-bang cutover.
Is customer communication required during a migration?
Requirements vary by provider and environment. A brief pre-migration notice and post-migration confirmation are good customer service. They set expectations, demonstrate transparency, and give customers a contact point if they notice anything unexpected. A well-executed migration is designed to minimize the actions required from subscribers. When that goal is met, communication confirms a smooth experience rather than managing a disruption.
The Bottom Line
The cutover date is not the ultimate measure of success. The customer experience is.
A migration that finishes on schedule but creates confusion, support tickets, or service disruption falls short of its objective. The most successful migrations are the ones customers barely notice.
Otto is Vox Matic’s proprietary automated telecom migration framework. Combined with our approach of automation first, expert engineering where required, it helps service providers transition customers with confidence while preserving continuity throughout the migration journey.
The platform changes. The experience does not.
It’s that simple!
Comments