The NetSapiens Migration Data Validation Checklist: Subscribers, Devices, Dial Plans, and Billing

Before a NetSapiens cutover, six categories of data require validation: subscriber records, device templates, dial plans and call flows, emergency-calling (E911) records, feature mappings, and billing-system dependencies. Rollback readiness should be validated as a separate operational control.

Each category requires a named owner, documented validation criteria, and a defined response when exceptions are found. 

A technically sound migration can encounter day-one failures if the underlying data has not been properly validated.

Key Takeaways

• Validation is a structured process with named ownership at every control point, not a single pre-cutover task.

• Subscriber records, dial plans, and billing integrations deserve particular attention because issues in these areas can directly affect customer experience and operations.

• E911 data carries regulatory and liability implications.

• Billing validation belongs before cutover, not after.

• Automation handles repeatable reconciliation work, while human review and sign-off remain essential at each control gate.

  
  

Why Data Validation Determines Cutover Outcomes

Legacy-data issues can be a major source of cutover problems, even when the target platform is operating as designed.

Legacy environments often accumulate years of undocumented exceptions: manually added configurations, unreconciled billing records, and device templates that have drifted over time. A migration can surface many of these issues at once.

Structured pre-cutover validation requires data to be reconciled before it is provisioned in the new environment. When results and approvals are documented, the process also creates an audit trail and establishes a rollback baseline.

The bottom line: problems found during validation are easier and less costly to resolve than problems discovered during the cutover window.

The Pre-Cutover Validation Checklist

Area	What to Validate	Common Exceptions
Subscriber Records	Accounts, users, DIDs, domains, seat types, and service assignments	Duplicates, inactive records
Devices & Templates	Device inventory, model compatibility, firmware requirements, and provisioning templates	Unsupported models, missing devices, outdated firmware, or template drift
Dial Plans & Call Flows	Inbound and outbound routing, hunt groups, auto attendants, queues, time conditions, trunks, and SIP peers	Legacy routing logic with no direct equivalent
Feature Mapping	Source-to-target feature behavior; unsupported features documented and communicated	Call recording behavior differences, paging group configuration gaps
Billing Integration	CDR delivery to billing system in correct format; account codes and rate plans aligned	CDR format mismatches, missing account codes, custom fields with no NetSapiens equivalent
Emergency Calling (E911)	Emergency-location records are accurate and current; applicable technical and jurisdictional requirements are reviewed	Stale, incomplete, duplicate, or incorrectly mapped location records
Rollback Readiness	Legacy platform configuration exported; DNS TTLs reduced ahead of cutover; rollback runbook documented and reviewed	Gaps in configuration export, DNS TTL reduction not completed in time

Emergency-calling data should be validated against current location information, applicable regulatory requirements, and relevant NG9-1-1 standards. Consult the [NENA Standards and Documents Library] for current technical standards, while also confirming the requirements that apply within each jurisdiction. NENA's standards library 

Assign a named individual to each control area. Open exceptions without a documented mitigation carry significant cutover risk.

Three Areas That Deserve Particular Attention

Although every control area matters, subscriber records, dial plans, and billing integrations warrant additional scrutiny because errors in these areas can immediately affect customers, call routing, and revenue operations.

Subscriber Records

Subscriber data sits at the base of everything else. A missing DID, wrong seat type, or incorrect domain assignment causes downstream failures that are hard to diagnose under cutover pressure.

Before any data moves, compare the account inventory with the source platform and confirm which records should be migrated, archived, or removed. Complete this reconciliation before scheduling the cutover.

Dial Plans

Dial plan errors affect call routing broadly. A route that looks correct in configuration can still fail if the underlying trunk or SIP peer is not active. Pre-cutover functional testing confirms actual routing behavior rather than relying solely on a configuration review.

Billing Integration

Leaving billing validation until after cutover creates unnecessary operational and revenue risk.

If the billing system does not receive CDRs in the expected format, rating and invoicing processes may be interrupted or produce inaccurate results. Testing billing data before cutover can help surface CDR or mapping issues early. Account codes, rate plans, and custom fields all need to map correctly before the window opens.

How Automation Changes the Validation Process

At scale, manually reconciling thousands of subscriber records, device templates, and dial-plan elements is slow, error-prone, and difficult to repeat consistently. Vox Matic's Otto automated migration framework supports data extraction, transformation, provisioning, and validation while surfacing exceptions for engineering review before the cutover window opens.

Human judgment remains essential for confirming which accounts to migrate, resolving unsupported legacy features, approving the rollback runbook, and E911 record verification.

For service providers migrating from BroadWorks or Metaswitch, the same validation framework applies. Source data structures will differ by platform, but the control areas and ownership model remain consistent.

Frequently Asked Questions

How can service providers validate subscriber data before a NetSapiens cutover?

Extract all subscriber records from the source platform and compare the source inventory with the approved migration dataset and, once provisioned, the NetSapiens target. Validate required fields, flag inactive accounts for customer review, and check for duplicate or conflicting DID assignments.

How should billing integration be validated before a NetSapiens migration?

The key requirement is that NetSapiens CDRs reach the billing system in the correct format with the correct account codes and rate plan mappings. Otto automates significant portions of migration data extraction, transformation, provisioning, and validation, while engineers review exceptions and integration requirements.

What happens if E911 data is not validated before cutover?

Invalid or outdated emergency-location data can cause an emergency call to be associated with the wrong location or routed incorrectly. Before cutover, providers should confirm that location records are accurate, current, and aligned with applicable regulatory requirements and technical standards. 

How do you handle legacy features that do not exist in NetSapiens?

Feature mapping belongs in the discovery phase. By the time validation begins, each legacy feature should have either a confirmed NetSapiens equivalent or a documented exception with a customer-approved resolution.

What is the rollback baseline and why does it matter?

The rollback baseline is a documented snapshot of the legacy environment and its relevant configurations at the point validation is completed. It gives the migration team a known state to restore if defined cutover criteria are not met. The rollback process, decision authority, and triggering conditions should be established before the cutover window opens.

Ready to Validate Your Migration?

A clean cutover starts with clean data.

Vox Matic combines Otto automation with experienced telecom engineering to help service providers prepare, validate, and execute migrations to NetSapiens. Contact our support and consulting team to discuss your migration timeline and validation requirements.

It's that simple!