Who Owns What During a NetSapiens Migration? A Responsibility Guide for Service Providers
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. Service providers and migration partners need to coordinate access, discovery, provisioning, validation, customer communications, and cutover decisions. When responsibilities are unclear, even straightforward migration tasks can be delayed.
This guide gives you a practical way to frame that conversation before the project starts.
Key Takeaways
Responsibilities vary by engagement and should be agreed during scoping, not after work begins.
Service providers usually handle the areas tied to their business: source access, customer communications, segmentation, and cutover approval.
Migration partners perform the technical migration activities included in their scope, with automation supporting repeatable extraction, transformation, provisioning, and validation processes.
Exception resolutions, acceptance criteria, and cutover readiness require clearly assigned technical and business decisions.
Unclear responsibilities can create delays, duplicate work, and unnecessary confusion during migration.
What Does a NetSapiens Migration Responsibility Matrix Look Like?
Responsibilities vary by engagement, but the following table provides an example of how work may be divided between a service provider and its migration partner. The exact ownership should be agreed during scoping.
Activity | Primary Responsibility | Migration-Partner Role | Decision or Approval |
Source access | Service provider | Defines required access and verifies connectivity | Access method, security requirements, and timing |
Discovery | Service provider and migration partner | Assesses data, configurations, integrations, and tech requirements | Scope, assumptions, dependencies, and exclusions |
Customer segmentation | Service provider | Advises on technical complexity and migration readiness | Service provider approves migration groups and sequence |
Data transformation and provisioning | Migration partner | Performs or supports automated transformation and provisioning activities included in the engagement | Provider approves applicable configuration standards and profiles |
Exception handling | Assigned according to exception type | Identifies migration-related exceptions and presents available technical options | Provider approves resolutions affecting customers, services, or business requirements |
Validation | Assigned according to the validation plan | Performs automated and technical checks included in the migration scope | Provider confirms business acceptance and authorizes progression |
Customer communications | Service provider | Migration partner (timing and technical detail) | Messaging around cutover dates |
Carrier and number routing | Service provider or its carrier | Coordinates migration dependencies within the agreed scope | Provider authorizes routing changes and timing |
Cutover approval | Service provider | Reports on the readiness of migration activities within its scope | Provider makes the final go/no-go decision |
Post-cutover verification | Provider engineering and support | Assists with migrated data, configurations, transformation rules, or provisioning issues within the agreed scope | Provider confirms acceptance or identifies required follow-up |
This matrix is illustrative. Actual ownership depends on the provider’s operating model, internal resources, technical environment, and the agreed migration and support scope. Responsibilities, decision rights, escalation paths, and acceptance requirements should be documented before work begins.
What Does the Service Provider Usually Handle?
Source access. The migration partner requires the agreed level of source access before extraction, detailed technical assessment, or other access-dependent activities can begin. Credentials, permissions, API access, and data exports usually come from your team, and timely access helps downstream work proceed as planned. Our guide to telecom migration prep covers what to line up early.
Customer segmentation. Grouping customers into migration stages, identifying high-touch accounts, and flagging contractual sensitivities requires business knowledge your team holds. In multi-tenant environments, migration groups may be organized by domain, reseller, customer type, configuration, technical complexity, or operational priority.
Customer communications. Your customers have a relationship with your brand. Communicating what is changing, when, and what they need to do usually stays with you, with your migration partner advising on timing and technical detail. Our guide on how to reduce churn during a telecom migration covers what customers should hear and when.
Carrier routing and cutover approval. Carrier routing, number-porting, and SBC changes may require coordination among the provider, its carriers, platform administrators, and migration partner, depending on the engagement. The decision to proceed with cutover usually rests with you, once technical readiness has been confirmed.
What Does the Migration Partner Usually Handle?
The migration partner performs the migration activities included in the agreed scope and provides technical assistance for migration-specific issues where required.
Otto™, Vox Matic's proprietary automated telecom migration framework, automates repeatable extraction, transformation, provisioning, and validation activities across the migration workflow. By applying automated validation checks to source and target data, Otto can identify discrepancies before cutover.
Depending on the engagement, the provider's engineers can manage the migration workflow and engage Vox Matic specialists when assistance is required with exceptions, testing, complex configurations, validation issues, or cutover planning. Migrated configurations can be built and tested in a sandbox environment, a non-production NetSapiens setup, and validation can include client-side checks in end-user apps such as SNAPmobile. The NetSapiens migration data validation checklist shows what that review covers.
After cutover, the partner typically leads the agreed technical verification activities. The Post-Migration Verification Playbook covers what gets checked once customers are live.
Which Decisions Require Coordination?
Shared activities need the clearest agreements, because each side can assume the other is handling them.
Discovery scope: The partner leads the technical inventory, but you know which accounts have custom or grandfathered arrangements.
Exception decisions: When a subscriber or configuration does not migrate cleanly, the partner presents the options and technical implications. You decide based on business context and customer relationships.
Validation sign-off: The partner runs the technical checks. You confirm that what has been validated reflects what your customers need.
Cutover go/no-go: The partner confirms technical readiness, and you confirm business readiness. Both are required before cutover.
A regular check-in rhythm between both teams helps keep these decisions moving.
When Should Responsibilities Be Agreed?
Before the project starts, ideally during scoping. A clear ownership model can help decisions move on time, reduce duplicated work, and keep customer communications planned rather than reactive. If a prospective partner has not raised the topic, it is worth raising it yourself. Our list of questions to ask a NetSapiens migration partner includes this and other topics to cover before you sign.
For platform-specific detail, see our Metaswitch to NetSapiens migration page and our BroadWorks to NetSapiens migration guide.
Planning a NetSapiens 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 define how migration responsibilities could be structured for your environment.
Request a Migration Assessment:
Discuss your current platform, timeline, and migration objectives.
Identify automation opportunities, project risks, responsibilities, and the most effective migration approach.
It's that simple!
Frequently Asked Questions
Who is responsible if something goes wrong during cutover?
Responsibility depends on the issue and the agreed project scope. Technical problems may involve the migration partner, the provider's engineering team, or the platform vendor. Defining ownership and escalation procedures before cutover helps issues reach the appropriate team quickly.
Can the migration partner handle customer communications on our behalf?
It depends on the engagement. Providers often keep customer communications in-house because the relationship is with their brand, while the migration partner advises on timing and technical detail. Whatever the arrangement, it should be agreed before customers are notified.
What happens when the migration process surfaces an exception?
Exceptions may be identified during discovery, transformation, provisioning, or validation. The migration partner can explain technical options for migration-related exceptions, while the provider approves decisions affecting customers, services, business rules, or operational policy.
How much of my team's time does a NetSapiens migration require?
It varies by engagement. Provider time is often concentrated at key decision points, such as source access setup, segmentation review, exception approvals, and cutover authorization. Automation can reduce repetitive manual work, but the provider still needs to supply technical information and make informed business, acceptance, and cutover decisions.
When should we discuss responsibilities with our migration partner?
During scoping, before work begins. Agreeing the responsibility model early gives both teams a shared reference point when decisions come up mid-project. If your migration partner has not raised it, it is worth starting the conversation yourself.
Comments