Migrations · BroadWorks
From BroadWorks to Thirdlane: a real plan, not a sales pitch.
Cisco announced end-of-sale for BroadWorks, with end-of-support timelines pushing operators toward Webex Calling — a platform with a fundamentally different commercial model. For service providers and carriers who built their UCaaS business on BroadWorks’ multi-tenant economics and channel autonomy, “just move to Webex” isn’t a strategy.
Thirdlane preserves what made BroadWorks viable for an operator: true multi-tenancy on one platform, channel-led white-label, and the ability to run your own NOC. What it changes is the licensing floor, the modernization rate, and how much capability ships in the platform vs. arrives as a partner integration.
Bottom line
Migrating from Cisco BroadWorks to Thirdlane runs in four phases — inventory and shape, a parallel Thirdlane platform, tenant-by-tenant cutover on your schedule, then archival of the legacy application servers. It preserves true multi-tenancy, reseller white-label, and NOC control while lowering the per-subscriber licensing floor.
- Phased, tenant-by-tenant cutover — BroadWorks stays live until the last tenant is settled.
- Multi-tenancy, isolation, SBC, STIR/SHAKEN, and OSS/BSS integrations translate across.
- One branded Connect app replaces coexisting UC-One / Webex client lineages.
- Legacy platform moves to read-only archival for retention, then sunsets on your schedule.
Plan your move if…
End-of-sale doesn’t mean tomorrow, but the migration window is finite. Two or more of these usually means it’s already on the near-term roadmap, whether your team has put it on a slide yet.
- Your AS / NS upgrade path now requires re-procurement under Cisco’s post-EoL commercial model.
- You’re being steered toward Webex Calling, which loses the channel autonomy and reseller economics that made BroadWorks viable for you.
- Your reseller hierarchy can’t be replicated 1:1 in the proposed replacement, and your customers know it.
- Your UC-One / Webex client lineage needs replacement regardless of platform — you’re going to ship a new app to your customer base anyway.
- Your CDR and OSS pipeline assumes BroadWorks-shaped data. Any move requires re-plumbing, so doing it twice is worse than doing it once.
- Per-subscriber licensing math no longer works at your tier mix — small tenants are subsidizing the floor.
- Your roadmap conversations with the BroadWorks side of Cisco have gone quieter than they used to be.
What carries over cleanly
BroadWorks operators built deep operational discipline — provisioning automation, CDR pipelines, SBC integration, recording archival. Most of that translates. Some pieces get simpler.
Translates 1:1
Multi-tenant model, per-tenant isolation, reseller-style branding, DIDs/E.911 plumbing, STIR/SHAKEN attestation, integrated SBC, repository-based upgrades, OSS/BSS via APIs and webhooks, recording archival.
Gets simpler
Provisioning interface (one Configuration Manager vs. a fleet of OCI-P/OCI-C scripts), UC client (one branded Connect app, not three coexisting client lineages), AI voice intelligence and CRM (in-platform vs. separate procurements), and SSO (OIDC across every surface).
Mapping table
| Area | BroadWorks | Thirdlane |
|---|---|---|
| Tenancy model | Reseller ↔ group ↔ user hierarchy on a true multi-tenant carrier core. | Tenant ↔ user model with first-class Multi-Site Enterprise grouping for chain customers. Reseller branding via per-tenant white-label. |
| Subscriber footprint | BroadWorks subscribers and DIDs across application servers. | Tenant extensions and DIDs on a single Configuration Manager. Bulk migration via REST API + CSV import. |
| Hunt groups, call centers, IVRs | Hunt groups, Call Center Standard/Premium, Auto Attendants. | Ring groups, Contact Center queues with disposition codes and ACW, IVR + Routing Conditions + visual Call Flow editor. |
| Phones | BroadWorks Device Management System (DMS) with vendor-specific tags. | Phone Models management with per-model templates, multiple provisioning protocols, External Provisioning to retain a customer-managed DMS, S3 transport. |
| Recordings | BroadWorks Recording Server / partner recording platforms. | S3-compatible storage across seven providers (AWS, Wasabi, Backblaze B2, DigitalOcean Spaces, Cloudflare R2, MinIO, Garage). Per-tenant BYOS for compliance-bound customers. |
| UC client | UC-One / Webex variants depending on era. | Connect: voice, video, chat, presence, file sharing, white-labeled per tenant on app stores under your brand. |
| Billing & OSS/BSS | CDR streams, BroadWorks Provisioning API (OCI-P/OCI-C). | OpenAPI 3.1 REST APIs (Organization, CRM, system management, telephony operations) plus webhooks. Separate reporting connection for OSS/BSS reads. |
| Identity | Per-system auth, partial SSO via partner integrations. | OIDC SSO with MFA across Configuration Manager, User Portal, and Connect. Pre-named: Okta, Azure AD, Google Workspace, Keycloak, Authentik, Zoho. Plus any OIDC IdP. |
| Routing & dialplan | Network and group dialplans, translation tables. | Per-tenant dial plans with country-aware E.164 normalization (51 pre-configured plans), per-user/per-trunk overrides, Routing Conditions for schedule/office-mode logic. |
| High availability | Carrier-grade redundant Application Servers, Network Servers, Network Function Manager. | Active/active and active/passive clustering with optional geo-redundancy. Service locations, role-separated management/proxy/PBX servers, tiered config sync, real-time topology view. |
How a migration runs
Operators with thousands of subscribers can’t flip a switch — and shouldn’t. Migrations run in four phases, on a schedule the operator controls.
Phase 1
Inventory & shape
We take an inventory of resellers, groups, subscribers, DIDs, recording footprint, and active integrations. The output is a per-tenant migration shape: what maps 1:1, what gets restructured, and what gets retired (legacy services that haven’t been touched in years are usually a third of the surface area).
Phase 2
Parallel platform
Stand up Thirdlane in your environment alongside BroadWorks. We pre-load tenants, phone templates, dial plans, and recording targets. Connect apps are white-labeled and published under your brand on iOS/Android while BroadWorks remains the active platform.
Phase 3
Tenant-by-tenant cutover
Cutover happens per tenant on a schedule the operator controls. Number routing flips, devices re-provision against Thirdlane (or stay on the customer-managed DMS via External Provisioning), and recordings move to S3. We keep BroadWorks live until the last tenant is comfortable.
Phase 4
Decommission & archive
Once all tenants are cut over, BroadWorks goes into read-only archival. We help you stand up a CDR / recording archive against the legacy platform for retention obligations, then sunset the application servers on your schedule.
Migrating from BroadWorks — frequently asked questions
How do I migrate from BroadWorks to Thirdlane?
Thirdlane migrations run in four phases: inventory and shape (resellers, groups, subscribers, DIDs, recordings, integrations), a parallel Thirdlane platform stood up alongside BroadWorks with tenants and templates pre-loaded, tenant-by-tenant cutover on a schedule the operator controls, then decommission of BroadWorks into read-only archival for retention. It is designed for operators with thousands of subscribers who cannot flip a single switch.
Why are BroadWorks operators migrating?
Cisco has announced end-of-sale for BroadWorks with end-of-support timelines steering operators toward Webex Calling, which uses a different commercial model and loses the channel autonomy and reseller economics that made BroadWorks viable. Thirdlane preserves true multi-tenancy, white-label, and operator-run NOC control while lowering the licensing floor.
What carries over cleanly from BroadWorks?
The multi-tenant model, per-tenant isolation, reseller-style branding, DID/E.911 plumbing, STIR/SHAKEN attestation, integrated SBC, repository-based upgrades, OSS/BSS via APIs and webhooks, and recording archival all translate. Provisioning, the UC client, AI and CRM, and SSO get simpler on Thirdlane.
Can BroadWorks stay running during the migration?
Yes. Thirdlane is stood up in parallel and BroadWorks stays the active platform until each tenant is cut over. BroadWorks remains live until the last tenant is comfortable, then moves to read-only archival for retention obligations before the application servers are sunset on your schedule.
Talk through your inventory
Send us a redacted reseller list, subscriber count, recording footprint, and a list of the BroadWorks add-ons you’ve been licensing. We’ll come back with a per-tenant migration shape, an honest read on what restructures, and a TCO across three years.
BroadWorks is a registered trademark of Cisco Systems. Mentions are for compatibility/migration context only.