Telecom Migration Exception Management: What Happens When Legacy Configurations Don't Map Cleanly?
Exception management in a telecom migration is the process of handling configurations that do not map cleanly from the legacy platform to NetSapiens. Each exception should be identified, classified, assigned a resolution path, and reviewed by the appropriate decision-maker before the affected customer moves to cutover.
Many legacy environments include configurations that do not fit a standard mapping: a feature with no direct NetSapiens equivalent, a record with missing data, or a one-off setup built for a single customer years ago. These are exceptions, and in a Metaswitch or BroadWorks to NetSapiens migration, they should be expected.
Identifying exceptions is the first step. The provider and migration team then need to establish who reviews them, what resolution options are available, who approves the outcome, and when a customer with open exceptions is ready to move.
Key Takeaways
Exceptions are configurations or records that fall outside standard mapping rules, and they are a normal part of legacy migrations.
Classifying exceptions by type can help teams choose a resolution path and route decisions to the appropriate people.
Common resolution paths include mapping to an appropriate NetSapiens service or configuration, redesigning the configuration, standardizing it, correcting the data or retiring it.
Decisions that affect customers, services or business rules should be approved by the provider.
A customer should typically move to cutover only when its exceptions are resolved, accepted or deferred under an approved plan.
What Counts as a Migration Exception?
An exception is any configuration or record that cannot move from the source platform to NetSapiens through the standard mapping. Exceptions typically surface during data extraction, transformation, or validation.
Common Exception Types at a Glance
Exception Type | Example | Common Resolution Paths |
Feature differences | A legacy feature with no direct NetSapiens equivalent | Map to the closest appropriate equivalent or redesign the call flow with the provider |
Data quality | Missing fields, duplicate records, or inactive users still assigned services | Correct the source data or clean it up during transformation |
Custom configurations | A one-off dial plan rule or ring strategy built for a single customer | Rebuild it as a custom configuration or move it to a standard design, where agreed |
Device exceptions | Endpoints that are unsupported or require a different configuration in the intended NetSapiens environment | Apply an appropriate supported configuration or plan for device replacement |
Integration dependencies | A billing or third-party connection tied to legacy identifiers | Review and update the integration as part of the cutover plan, where required |
Scope questions | Services the provider may not want to carry forward | Retire, defer, or confirm them as in scope, as approved by the provider |
Many exceptions trace back to years of undocumented customization. Our guide to why telecom migrations fail covers how these gaps develop.
How Are Exceptions Identified?
Exceptions are typically easier to resolve the earlier they are found.
In Vox Matic's migration process, extracted data is converted into the destination format and presented for review before anything is provisioned in NetSapiens, with the exact sequence depending on the source environment. Data points that cannot be mapped directly are flagged for review. Depending on the provider's requirements, the affected configurations may be transformed, recreated differently, or excluded with approval.
Reviewing exceptions at this stage can help turn them into a planned set of decisions rather than issues discovered during cutover. Our NetSapiens migration data validation checklist covers checks that can help surface them.
What Are the Options for Resolving an Exception?
Different exceptions may need different treatments. The main resolution paths are:
Map to an equivalent: The configuration is mapped to the closest appropriate NetSapiens service or configuration, with any behavioral differences documented.
Redesign: The call flow or configuration is rebuilt in a different way that meets the same business need.
Standardize: A one-off configuration is moved to a standard design, where the customer's requirements still allow it.
Correct the data: Missing or inconsistent records are corrected at the source or during transformation.
Retire or defer: Services the provider decides not to carry forward are retired, or items are deferred to a later stage with the provider's approval.
Standardization should preserve agreed customer requirements. When a change would affect how a customer's service behaves, it should be treated as a decision for the provider rather than a technical fix.
Who Decides How an Exception Is Resolved?
Exceptions can involve both technical and business questions, so decision rights should be clear before the migration starts.
A Practical Split
The migration workflow identifies migration-related exceptions, while the migration team reviews the technical options and outlines the implications of each.
The service provider approves resolutions that affect customers, services, business rules, or operational policy.
Both parties agree on how exceptions are documented and tracked, so each resolution is recorded and followed through.
For each exception, record the affected customer, the configuration involved, its potential service impact, the assigned owner, the agreed resolution, and whether it blocks cutover.
For a broader view of how responsibilities are divided, see our guide to who owns what during a NetSapiens migration.
When Is a Customer Ready for Cutover?
Open exceptions are an important indicator of cutover readiness. Before a customer moves, each exception should typically be in one of three states:
Resolved: The configuration has been rebuilt in NetSapiens and has passed the agreed validation checks.
Accepted: The provider has approved a known difference, and the customer has been informed where needed.
Deferred with an approved plan: The item is scheduled for a later stage, the provider has approved the deferral, and the outstanding issue does not prevent the customer from meeting the agreed cutover requirements.
Depending on the agreed migration approach, customers with unresolved exceptions that affect core services can be moved to a later stage while the rest of the migration continues. This can help prevent one complex account from delaying other customers.
Where Does Automation Help With Exceptions?
Automation does not remove exceptions. When repeatable mapping and provisioning work is automated, engineering time can be focused on the configurations that require review and judgment.
Otto™, Vox Matic's proprietary automated telecom migration framework, automates repeatable data extraction, transformation, and provisioning work. Automated validation checks applied throughout the workflow help identify migration discrepancies for review before cutover.
The provider's engineers manage the migration workflow and can engage Vox Matic specialists when assistance is required with technical mapping, complex exceptions, validation issues, or cutover planning, depending on the agreed engagement.
Planning a Migration With Complex Configurations?
Vox Matic has supported automated migrations involving thousands of subscribers from Metaswitch and BroadWorks environments to NetSapiens. As a NetSapiens Ecosystem Partner, Vox Matic can support migration planning and help identify where your environment may require engineering review.
Request a Migration Assessment
Review your current platform, timeline, and migration objectives.
Identify automation opportunities, potential exceptions, and an appropriate migration approach.
It's that simple!
Otto™ is a trademark of Vox Matic. NetSapiens® is a trademark of Crexendo, Inc. All other third-party names and trademarks are the property of their respective owners.
Frequently Asked Questions
What is an exception in a telecom migration?
An exception is a configuration or record that cannot move from the legacy platform to NetSapiens through the standard mapping. Examples include features without a direct equivalent, incomplete data, and one-off customer configurations.
Are exceptions a sign that a migration is going wrong?
No. Exceptions are expected in legacy environments, especially those built up over many years. The priority is to identify them early, track them, and resolve, accept, or defer them under an approved plan before cutover.
Who approves how an exception is resolved?
The migration partner can explain the technical options, while the service provider approves resolutions that affect customers, services, or business rules. The exact split should be agreed during planning.
Can a migration continue if some customers have open exceptions?
Yes, depending on the agreed migration approach. Customers with unresolved exceptions can be moved to a later stage while others proceed, as long as their open items are tracked with an approved plan.
Can automation resolve exceptions on its own?
No. Automation can help identify discrepancies and handle repeatable mapping work, which may leave more engineering time for exceptions. Resolving them still requires review, and decisions that affect customers are approved by the provider.
Comments