
Cisco BroadWorks to NetSapiens Migration
Move customers from Cisco BroadWorks to NetSapiens through a structured, automated migration process designed for scale, visibility and control.
Moving a large customer base from BroadWorks to NetSapiens can require thousands of customer, user, service, number and device configurations to be reviewed and rebuilt. Performing that work manually can consume internal engineering resources, extend project timelines and introduce avoidable inconsistencies.
Vox Matic uses Otto™, its proprietary automated telecom migration framework, to extract available BroadWorks data, convert it into the required NetSapiens structure and automate repeatable provisioning work. Experienced telecom engineers oversee discovery, feature mapping, exceptions, validation and cutover planning.
The exact migration process depends on the BroadWorks environment, accessible source data, NetSapiens configuration and agreed project scope.
Automate the repeatable work. Apply engineering expertise where it matters.

How Fuse.Cloud Reduced an Estimated 18-Month Migration to Approximately Six Months
Fuse.Cloud needed to move its business customers from BroadWorks into a unified NetSapiens environment without committing its internal engineering team to an estimated 18-month manual migration. Working with Vox Matic, the migration was completed in approximately six months. Fuse.Cloud also reported achieving a full return on its migration investment in less than five months.
“Our customers barely noticed the transition. That's the kind of professionalism we were looking for.”
FUSE.CLOUD
~18
MONTHS: ESTIMATED MANUAL TIMELINE
~6
MONTHS: COMPLETED WITH VOX MATIC
< 5
MONTHS: CUSTOMER-REPORTED ROI
1
UNIFIED NETSAPIENS ENVIRONMENT
Results reflect the specific Fuse.Cloud engagement. Migration timelines, cost reductions and return on investment vary according to the source environment, customer base, configuration complexity, available data, project scope and internal requirements.

How BroadWorks Information Is Rebuilt in NetSapiens
BroadWorks and NetSapiens organize customers, users, services and features differently. During discovery, Vox Matic reviews the available source data, identifies the corresponding NetSapiens configuration and documents how supported information will be converted, recreated or redesigned.
Mappings are agreed before production migration work begins. Not every BroadWorks feature has an exact one-to-one equivalent in NetSapiens, so feature behavior and business requirements must also be considered.
BROADWORKS INFORMATION
TYPICAL NETSAPIENS TREATMENT
Enterprises and groups
→
Reviewed and mapped to the appropriate NetSapiens customer, domain and site structure
Users and assigned services
→
Users, service settings and applicable answering-rule configurations
Service packs
→
Reviewed at the feature level and mapped to the applicable NetSapiens capabilities
Phone numbers
→
Numbers assigned or routed to the appropriate users, queues, auto attendants or other supported destinations
Hunt groups and call centers
→
Reviewed and rebuilt using the appropriate NetSapiens queue or call-distribution configuration
Auto attendants and time frames
→
Rebuilt as auto attendants, menus, schedules and related time-frame rules, where supported and included in scope
Announcements, greetings and voicemail settings
→
Accessible audio assets, greetings and voicemail configurations extracted or recreated according to the agreed scope
Devices, device users and device customizations
→
Supported devices, user assignments, provisioning configurations and device profiles
During discovery, Vox Matic identifies which settings and assets are accessible through the source environment and which can be migrated, converted or recreated. Features that behave differently in NetSapiens are documented and reviewed with the service provider before the applicable customer is scheduled for cutover.
The final result is based on the available source data, supported interfaces, target-platform capabilities and approved migration design.

Visibility at Every Stage
Large BroadWorks migrations are typically organized into controlled phases or customer waves. Vox Matic provides structured reporting so authorized project participants can see what has been prepared, what is scheduled next, what has been completed and what requires attention.
DEPENDING ON THE MIGRATION DESIGN, CUSTOMER RECORDS CAN MOVE THROUGH CHECKPOINTS SUCH AS:
1
Source data received and assessed
2
Customer configuration converted
3
Feature mappings reviewed
4
Exceptions identified and assigned
5
Target configuration prepared
6
Pre-cutover validation completed
7
Operational dependencies confirmed
8
Customer scheduled for migration
9
Post-cutover validation completed
10
Migration status closed
Where included in the migration design, converted configurations can be prepared and validated in a non-production NetSapiens environment before production cutover.
Migration reporting provides current status information for each customer, including the applicable phase, completed work and exceptions requiring attention.
Customers can be organized into phased migration waves or larger scheduled groups based on technical readiness, operational requirements and agreed maintenance windows.
Beyond the Platform: Billing, Routing and Operational Workflows
A platform migration involves more than creating users and services in NetSapiens. Service providers may also need to update billing records, operational tickets, device-routing instructions, carrier routes, SBC configurations and customer communications.
During discovery, Vox Matic identifies the surrounding systems and operational steps that could affect cutover. Compatible workflows may then be incorporated into the migration process where technically available and included in the approved scope.
Depending on the provider's environment and approved scope, this may include:
Updating compatible billing or customer-management systems
Creating operational or customer-contact tickets
Preparing device-redirection or provisioning changes
Coordinating number-routing changes
Updating supported SBC or carrier-routing configurations
Triggering notifications, approvals or completion records
Required carrier and SBC routing changes are identified during planning. Responsibility for performing each change is documented in the cutover plan based on system access, provider requirements, third-party responsibilities and agreed scope.
Cisco BroadWorks to NetSapiens Migration: Frequently Asked Questions
Start with a Clear BroadWorks Migration Plan
Vox Matic has used automation and telecom engineering to migrate thousands of subscriber configurations from legacy communications platforms, including BroadWorks and Metaswitch, into NetSapiens.
The process begins with understanding the source environment, target configuration, surrounding systems, customer base and operational requirements. From there, Vox Matic identifies what can be automated, where engineering review is required and how the migration can be organized into controlled stages.
In an initial migration discussion, Vox Matic will:
Review the size and structure of your BroadWorks environment
Discuss your NetSapiens target environment
Identify available source data and system access
Review customer, service, device and feature complexity
Identify billing, routing and operational dependencies
Discuss scheduling, migration waves and internal resources
Outline potential automation opportunities and project risks
Not ready to plan the project? Read the BroadWorks to NetSapiens migration guide.
Otto™ is a trademark of Vox Matic. Cisco®, BroadSoft® and BroadWorks® are trademarks or registered trademarks of Cisco Systems, Inc. and/or its affiliates. NetSapiens® is a trademark of Crexendo, Inc. Other product and company names are the property of their respective owners. References to third-party products are for identification and interoperability purposes only. Vox Matic's authorized relationship with NetSapiens is described separately on this website.
