During a NetSapiens migration, voicemail settings are typically recreated, while greetings, announcements and other audio files may be transferred or re-recorded. What can be moved depends on the source platform, file accessibility and the agreed migration scope. For providers migrating from Metaswitch, BroadWorks or other mixed legacy environments into NetSapiens, the first step is identifying what can be recreated automatically, what can be transferred and what customers ma

Device migration is one of the most visible parts of any BroadWorks or Metaswitch to NetSapiens migration. While platforms, databases and configurations run in the background, users immediately notice when a phone, ATA or softphone is not working after cutover. Proper planning, device mapping and automated migration workflows help ensure a smooth transition with minimal disruption. For many end users, their phone or app is a highly visible part of the service. If an endpoint

Exception management in a telecom migration is the process of handling configurations that do not map cleanly from the legacy platform to NetSapiens. Each exception should be identified, classified, assigned a resolution path, and reviewed by the appropriate decision-maker before the affected customer moves to cutover. Many legacy environments include configurations that do not fit a standard mapping: a feature with no direct NetSapiens equivalent, a record with missing data,

A Ribbon to NetSapiens migration starts with defining which Ribbon components are being replaced and which remain in the network. From there, available subscriber, feature, and routing data is mapped into the NetSapiens structure, and cutover is planned around number routing, interworking between platforms, and device redirection. Ribbon is a broad name in telecom networks. Depending on the provider, it may refer to call control and application servers, session border control

After a NetSapiens migration, service providers can reduce day-to-day manual work by automating repeatable operational workflows (such as onboarding, approvals, carrier requests, user changes, and reporting) across the systems their teams already use. The right starting point is the work that is high-volume, rule-based, and spread across several tools. A migration changes the voice platform. It does not automatically change how the rest of the business runs. Once customers ar

Migrating a multi-tenant UCaaS environment to NetSapiens means rebuilding the provider’s hierarchy as resellers, domains, and users, standardizing provisioning with configuration profiles and dial plans, and moving customers in stages that are often organized by reseller or domain. A single-tenant migration moves one organization. A multi-tenant migration moves a whole business model: wholesale partners, their customers, those customers’ sites and users, and the administrativ

Protecting revenue during a NetSapiens migration means keeping billing records, usage data, and invoices aligned as each customer moves. Confirm what each customer is billed for before cutover, plan how call detail records (CDRs) from both platforms will be collected and reconciled, and review charges before the first invoices go out. Platform migrations are usually planned around users, devices, and call flows. Billing often sits outside the voice platform, in a separate sys

In a NetSapiens migration, the service provider typically leads source access, customer communications, business decisions, and cutover approval. The migration partner performs the technical activities defined in the agreed scope and provides migration-specific assistance where required. Responsibilities should be documented during scoping because the exact division varies by engagement. A NetSapiens migration involves more than moving subscriber data between platforms. Servi

Migration timelines are one of the first questions telecom executives ask, and one of the hardest to answer without context. There is no universal timeline for a Metaswitch or BroadWorks migration to NetSapiens. Any estimate provided before understanding your environment is unlikely to be reliable. The direct answer: Migration duration depends on subscriber volume, data quality, feature complexity, integrations, validation requirements, exception handling, wave design, and cu

Post-migration support helps service providers identify and resolve issues after cutover, confirm that customer services are stable, and move the new platform into normal operations. The exact support arrangement depends on the migration and should be agreed before cutover. Go-live is an important milestone, but the work does not always end there. Provisioning exceptions may surface, call flows can behave differently under live traffic, and end users may report issues that we

A strong NetSapiens migration RFP should evaluate more than price and timing. It should examine each vendor's source-platform experience, discovery process, automation capabilities, feature mapping, validation, testing, cutover planning, accountability, and post-cutover support. An incomplete vendor evaluation can contribute to migration exceptions, delays, and subscriber issues that continue after cutover. A structured RFP helps service providers compare methodology, evidenc

To reduce churn during a telecom migration, service providers should segment customers by risk, communicate before each cutover, prepare customers for feature differences, and follow up quickly after go-live. Migration-related churn can come from more than the technical cutover itself. A migration can go well on the platform side and still cost customers if nobody told them what was changing, a feature they relied on behaved differently, or a support ticket sat unanswered in

Choosing a NetSapiens migration partner shapes how quickly you modernize, what the project costs, and how your customers experience the move. NetSapiens now supports more than 8 million users worldwide, and Crexendo reports the platform is growing at twice the rate of its competitors. Before you commit, ask these 12 questions. Key Takeaways Automation-led and manual migration produce different outcomes at scale. Know which one you are buying. Ask for specifics on data transfo

Telecom migration problems often begin with gaps in discovery, configuration, validation, or cutover preparation. For service providers moving from Metaswitch, BroadWorks, or other legacy platforms into NetSapiens, seven recurring risks are worth addressing before the first customer moves: configuration drift, undocumented routing, incomplete inventory, unclear feature ownership, narrow test coverage, weak rollback plans, and inadequate support escalation. Each can be mitigat

Post-migration verification is the final check that NetSapiens is working the way it should once customers are live. Before cutover, you can validate data, configurations, and routing. After cutover, you find out how everything behaves under real traffic. That matters because some issues simply do not show themselves until customers start using the platform. A device may register correctly during testing and then drop later. A call flow may work in one scenario but fail in an

A BroadSoft to NetSapiens migration moves subscriber records, service configurations, devices, and call routing from Cisco BroadWorks into NetSapiens, then validates that everything works before customers are cut over. BroadSoft was the company and BroadWorks is its platform, which Cisco acquired in 2018. Many providers still use the two names interchangeably. Most of the effort goes into translating years of accumulated configuration between two differently built platforms,

Most telecom migration challenges begin long before the first subscriber is moved. Capacity planning—not the migration platform itself, is often what determines whether a program stays on schedule or falls behind. Not because of the platform. Not because of the team. Because nobody sized the program for the actual subscriber base. Waves get too large, exception work stacks up, and by mid-program the team is fighting fires instead of moving subscribers. The timeline that looke

Before a NetSapiens cutover, six categories of data require validation: subscriber records, device templates, dial plans and call flows, emergency-calling (E911) records, feature mappings, and billing-system dependencies. Rollback readiness should be validated as a separate operational control. Each category requires a named owner, documented validation criteria, and a defined response when exceptions are found. A technically sound migration can encounter day-one failures if

Metaswitch: A practical cost comparison. Which path makes the most financial sense over the next 24 to 36 months? That is the decision facing every provider still using Metaswitch. Microsoft ended Metaswitch development on June 3, 2024, laying off the majority of its sales, engineering, and professional services workforce. Alianza acquired the platform on March 4, 2025. Two ownership changes in five years does not provide the stability needed for long-term platform planning.

Subscriber data is one of the most valuable assets involved in a telecom migration. Moving from platforms such as Metaswitch or BroadWorks to NetSapiens requires more than transferring records. Subscriber profiles, feature assignments, routing rules, device configurations, and third-party integrations all need to arrive accurately and function as expected. Data integrity in a telecom migration means ensuring subscriber records, configurations, routing, features, and integrati