BroadSoft to NetSapiens Migration
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, at scale, while protecting the customers who depend on you.
Key Takeaways
Cisco's direction for BroadWorks makes this a business model decision as well as a technical one.
BroadWorks and NetSapiens organize subscribers, features, and routing differently, so data has to be mapped and transformed before provisioning.
Sandbox testing and validation before cutover are where customer-facing issues get caught.
Otto™ automates repeatable migration work while senior engineers handle discovery, exceptions, and cutover oversight.
Why Are Service Providers Moving Off BroadSoft?
BroadWorks has served service providers reliably for years. Since acquiring BroadSoft, Cisco has centered its investment on Webex Calling. According to NetSapiens' BroadWorks comparison, Cisco's recommended path for BroadWorks providers is Webex Calling Wholesale, a Cisco-hosted service that providers resell instead of operating their own platform.
For providers whose business depends on owning the platform and the customer relationship, that is a significant change.
NetSapiens is fully white-label and offers a different commercial model:
BroadWorks | NetSapiens | |
Licensing | Per-seat | Session-based (concurrent calls) |
Provisioning API | OCI-P (XML-based) | REST APIs |
Strategic position | Reseller path via Webex Calling Wholesale | Provider owns the platform |
Source: NetSapiens
Timing matters too. The sooner customers move, the sooner BroadWorks licensing and support costs end, and the shorter the period of running two platforms in parallel. Our article on the business case for retiring legacy telecom platforms covers that math in more detail.
What Makes a BroadSoft to NetSapiens Migration Complex?
Because BroadWorks and NetSapiens were built on different architectural assumptions, data cannot simply be copied across.
Scope depends on the source environment, but a few areas usually need close attention.
Provisioning interfaces. The two platforms use different provisioning APIs, so tools and integrations built around BroadWorks need to be rebuilt or replaced.
Account hierarchy. BroadWorks enterprises and groups map to NetSapiens resellers and domains, and that mapping needs deliberate planning.
Call flows and features. Auto attendants, hunt groups, time-of-day rules, and user-level settings are configured differently on each platform. They have to be rebuilt so calls behave the same way after the move.
Accumulated exceptions. Years of custom configurations, undocumented changes, and inactive records surface during discovery. Finding them early keeps them out of the cutover window.
Before live traffic moves, Vox Matic builds and tests migrated configurations in a sandbox environment, a non-production NetSapiens setup. Validation there confirms that features, routing, device registration, auto attendants, and voicemail work as expected, so issues can be caught and fixed before customers are cut over.
Depending on the environment, cutover may run in controlled stages or batches. Our NetSapiens migration data validation checklist covers this step, and the BroadWorks to NetSapiens migration guide goes deeper on the technical side.
How Does Otto Change the Migration?
Done by hand, a BroadWorks project competes with day-to-day operations for the same engineers, and the timeline grows with every subscriber added to scope.
Otto™, Vox Matic's proprietary automated telecom migration framework, takes on the repeatable work: data extraction, configuration transformation, provisioning, validation, and testing.
The model is automation first, expert engineering where required.
Senior telecom engineers handle discovery, architecture, complex exceptions, and cutover oversight.
An Otto-led transition reduces repetitive engineering effort, keeps configurations consistent across thousands of records, and helps providers retire BroadWorks sooner.
For a side-by-side view, see manual vs. automated telecom migration.
Fuse.Cloud used this approach for its own BroadWorks to NetSapiens transition.
A project estimated at about 18 months of manual effort was completed in six months, and Fuse.Cloud reported full ROI in under five months.
"Our customers barely noticed the transition." — Fuse.Cloud
The platform changes. The experience does not.
Planning a BroadSoft to NetSapiens Migration?
As a NetSapiens Ecosystem Partner, Vox Matic helps service providers move off BroadWorks with Otto and experienced telecom engineering. Talk to our team about your environment and timeline.
It's that simple!
Frequently Asked Questions
Is BroadSoft the same as BroadWorks?
BroadSoft was the company and BroadWorks was its platform. Cisco acquired BroadSoft in 2018, and the platform is now marketed as Cisco BroadWorks. Providers use both names, and the path to NetSapiens is the same either way.
How long does a BroadSoft to NetSapiens migration take?
There is no universal timeline. It depends on subscriber volume, configuration complexity, the condition of the source data, and cutover requirements. Automation compresses the repetitive work, while discovery, validation, and controlled execution still need proper planning.
Can a BroadWorks migration minimize customer disruption?
Yes. Thorough discovery, sandbox testing and validation before cutover, and controlled execution help preserve the customer experience. The exact cutover approach, including whether to migrate in stages, depends on the environment and the provider's requirements.
Can Vox Matic help if we already run NetSapiens alongside BroadWorks?
Yes. Many providers already operate NetSapiens while keeping some customers on BroadWorks. Vox Matic helps consolidate those customers into the existing NetSapiens environment so the legacy platform can be retired.
Comments