Migrating Multi-Tenant UCaaS Environments to NetSapiens: Resellers, Domains, and Provisioning
Updated: 3 days ago
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 administrative access each layer depends on.
For service providers moving from BroadSoft (BroadWorks) or Metaswitch into NetSapiens, getting that structure right early shapes everything that follows, from provisioning and validation to how customers are communicated with during cutover.
Key Takeaways
Multi-tenant migrations rebuild a hierarchy, not just a list of users, so the reseller and domain structure should be agreed before provisioning starts.
Legacy structures such as BroadWorks enterprises and groups or Metaswitch business groups can map to NetSapiens resellers, domains, and sites, with the exact mapping confirmed during discovery.
Standard configuration profiles, dial plans, and feature packages make provisioning at scale more consistent.
Migration stages organized by reseller or domain can keep validation, communication, and billing aligned.
Automation helps keep large numbers of configurations consistent across tenants.
What Makes a Multi-Tenant Migration Different?
In a multi-tenant environment, many organizations share one platform but are kept separate from each other. Some providers also sell through resellers or wholesale partners, who manage their own customers.
That adds three layers of complexity:
Hierarchy: Each customer belongs somewhere in a structure that has to be recreated accurately.
Administration: Resellers and customer administrators need the right level of access once they are in NetSapiens.
Scale of consequences: A structural mistake can affect the customers beneath it, not just one user.
This is also why multi-tenant migrations often overlap with telecom platform consolidation, especially when a provider is bringing several legacy environments, or acquired customer bases, into one NetSapiens environment.
How Does the Legacy Hierarchy Map to NetSapiens?
NetSapiens organizes a multi-tenant environment around resellers and domains. A domain typically represents one customer organization, with its own users, dial plan, and settings. Resellers group domains together, for providers that sell through partners or manage customers in separate portfolios.
Hierarchy Mapping at a Glance
Legacy Structure | Possible NetSapiens Mapping | What to Agree During Discovery |
Wholesale partners or service providers within the legacy platform | Resellers | Which partners need their own reseller level |
BroadWorks enterprises and groups | Customer, domain, and site structures, depending on the source hierarchy | Whether each group becomes a domain or a site within one |
Metaswitch business groups | Domains or other appropriate customer structures, depending on the environment | How departments and locations are represented |
Users and assigned services | Users with features and answering rules | Feature packages and naming conventions |
Administrator accounts | Reseller and domain-level administration | Who needs access at each level |
Devices and device customizations | Devices and configuration profiles | Which profiles become the standard |
The exact mapping depends on how the legacy environment was built. Two providers on the same platform can structure customers very differently. Our Metaswitch to NetSapiens migration page and BroadSoft to NetSapiens migration guide cover platform-specific detail.
What Should Be Decided About Resellers and Domains?
A few structural decisions are worth settling before any customers are provisioned:
Reseller structure: Which partners or portfolios need a reseller level, and which customers sit directly under the provider.
Domain naming convention: A consistent format for domain names. Changing names after customers are live adds avoidable work.
Sites and departments: How multi-location customers are represented within a domain.
Administrative access: Which reseller and customer administrators need access, and at what level.
Dial plans: Which dial plan rules are standard, and which customers need exceptions.
These decisions are easier to make with a full inventory from discovery, before the structure is built.
How Do You Provision Consistently at Scale?
Legacy environments built up over many years often contain inconsistent configurations: features assigned differently from one customer to the next, one-off dial plan changes, and devices set up in several different ways. Copying that inconsistency into NetSapiens carries the same operational burden forward.
A migration is a chance to standardize:
Configuration profiles for common device types, so endpoint provisioning follows a known standard
Feature packages that map legacy service packs and bundles to consistent NetSapiens features
Dial plan standards applied across domains, with documented exceptions
Naming conventions for users, devices, call queues, and auto attendants
Standardization should preserve existing customer requirements, with exceptions reviewed and approved before changes are applied. Migrated configurations can be built and tested in a sandbox environment, a non-production NetSapiens setup, before cutover. Configurations that need a different design are flagged and reviewed with the provider.
How Should a Multi-Tenant Migration Be Staged?
Larger migrations may be divided into stages depending on the environment. Migration groups may be organized by domain, reseller, customer type, technical complexity, or operational priority. Organizing stages by reseller or domain has several advantages:
Validation: Domain-level checks confirm that a whole customer works before the next one moves, including client-side checks in end-user apps such as SNAPmobile.
Communication: Resellers can prepare their own customers, since those customers know the reseller rather than the provider.
Billing: Billing changes can follow the same groups, keeping invoices aligned with cutover.
Support: Issues after cutover are easier to trace when the customers who moved together are clearly defined.
Whether a stage is one domain or many depends on customer size, complexity, and the cutover approach agreed with the provider. Our NetSapiens migration data validation checklist covers what to check at each stage.
Where Does Automation Help?
Multi-tenant migrations multiply repetitive work. The same types of users, devices, and features are rebuilt across large numbers of customers.
In a multi-tenant environment, the same structures repeat across every reseller and domain: users, devices, call queues, and auto attendants built to similar patterns. Otto™, Vox Matic’s proprietary automated telecom migration framework, handles that repeatable extraction, transformation, provisioning, and validation work across tenants, applying automated validation checks to source and target data so discrepancies can be identified before each stage moves.
Depending on the engagement, the provider’s engineers can manage the migration workflow and engage Vox Matic specialists when assistance is required with structural decisions, exceptions, testing, or cutover planning.
In one example, Fuse.Cloud moved its business customers from BroadWorks into a single NetSapiens environment. A manual migration was estimated at about 18 months; with Vox Matic, it was completed in about six. Results are specific to that engagement. Read the case study.
Planning a Multi-Tenant Migration?
Vox Matic has completed automated migrations of thousands of subscribers from Metaswitch and BroadWorks environments to NetSapiens. As a NetSapiens Ecosystem Partner, Vox Matic can help you plan your reseller and domain structure before the first customer moves. If you already run NetSapiens alongside a legacy platform, see how Vox Matic helps providers consolidate into NetSapiens.
Request a Migration Assessment:
Discuss your current platform, timeline, and migration objectives.
Identify automation opportunities, structural decisions, project risks, and the most effective migration approach.
It’s that simple!
Frequently Asked Questions
What is a domain in NetSapiens?
A domain typically represents a single customer organization in NetSapiens, with its own users, dial plan, and settings. In a multi-tenant migration, legacy customer structures are often rebuilt as domains, with the exact mapping agreed during discovery.
What is a reseller in NetSapiens?
A reseller groups domains together. Providers that sell through wholesale partners, or manage customers in separate portfolios, can use reseller levels to keep those customers organized and give partners appropriate administrative access.
Can resellers keep managing their own customers after migration?
That depends on how the reseller structure and administrative access are set up. Defining which reseller and customer administrators need access, and at what level, should be part of migration planning.
Should we migrate one reseller at a time?
Organizing stages by reseller or domain often makes validation, communication, and billing easier to manage. The right stage size depends on customer count, complexity, and the cutover approach agreed for the project.
Can we standardize configurations during migration?
Yes. A migration is an opportunity to introduce standard configuration profiles, feature packages, dial plans, and naming conventions, while preserving existing customer requirements. Configurations that do not fit the standard are flagged for review with the provider rather than copied over as they are.
Comments