Migration Discovery
What Is Migration Discovery?
Migration discovery is the planning stage of a telecom platform migration where the source environment is inventoried, data access is confirmed and customer configurations are mapped to the destination platform. It identifies exceptions, dependencies and risks before anything moves, and its findings shape the migration approach, wave plan and timeline.
What does migration discovery cover?
Area | What is reviewed | Why it matters |
|---|---|---|
Customers and structure | Customer list, locations, resellers and how accounts are grouped | Decides how customers map to domains and how waves are formed |
Users, features and call flows | Assigned features, hunt groups, auto attendants and voicemail | Shows where feature parity needs a different design |
Numbers and routing | Number inventory, carriers, SIP trunks and SBC routing | Decides whether numbers are re-routed or ported |
Devices | Phone models, firmware and provisioning method | Affects device redirection at cutover |
Data access | Which data can be exported, in what format and from which systems | Affects the level of automation and the engineering review needed |
Supporting systems | Billing, provisioning, voicemail and operational systems | Identifies integrations that need updating |
Undocumented settings | One-off configurations and customer-specific rules | Flags work that may need to be transformed, normalized or rebuilt |
Why does data access matter so early?
How data can be extracted from the legacy environment affects the timeline, the level of automation and the amount of engineering review needed. Depending on the environment, data may come from provisioning interfaces, bulk exports or connected OSS systems. During discovery, it is worth confirming:
Which data can be exported, and in what format
Whether exports are complete or need to be combined from several sources
How current the data is compared with what is configured on the platform
Which customer-specific settings are undocumented
Gaps found early can be planned for. Gaps discovered during or immediately before cutover can delay the migration and increase the risk of service impact.
What comes out of discovery?
An inventory of customers, numbers, users, devices and call flows
A mapping of source structures and features to the destination platform
A list of exceptions to be reviewed with the provider
A wave plan and the cutover requirements for each wave
The third parties involved, such as carriers and SBC administrators
A realistic timeline, confirmed once the environment is understood
In Vox Matic's Metaswitch to NetSapiens process, the Explore step confirms the source environment, customer list and NetSapiens target, and migration waves are planned. Exact mapping is confirmed during discovery, because every environment has its own customizations. See how a Metaswitch to NetSapiens migration works.
Frequently asked questions
How long does migration discovery take?
It depends on the number of customers, the complexity of their configurations and how easily data can be accessed. Its findings are what allow a realistic migration schedule to be set.
Who is involved in migration discovery?
Typically the provider's engineering and operations teams, the migration partner and, where relevant, billing owners. Carriers and SBC administrators may be involved when routing changes are in scope.
What is the difference between a migration assessment and discovery?
A migration assessment is usually the first conversation: a high-level review of the current platform, timeline and objectives. Discovery goes further, into the configuration and data of the environment itself.
Related terms
Start with a Migration Assessment
Review your current platform, timeline and migration objectives, and identify automation-first opportunities and risks.
NetSapiens is a trademark of Crexendo, Inc. Metaswitch and BroadWorks are trademarks of their respective owners. Otto™ and Forge™ are trademarks of Vox Matic. Vox Matic is an independent migration services provider. References to third-party products are for identification and interoperability purposes only and do not imply endorsement, except where an authorized partnership is expressly identified.