Feature Parity
What Is Feature Parity in Telecom Migration?
Feature parity in telecom migration means the destination platform delivers the calling features and behavior customers rely on in the legacy platform. The goal is equivalent functionality, such as the same call routing, voicemail and hunt-group behavior, not an identical configuration. Parity is confirmed by mapping features and testing how they behave.
How is feature parity different in telecom migration?
In product management, feature parity usually means matching a competitor's feature list. In a telecom platform migration, it means something narrower: a business customer moved from one platform to another should be able to place, receive and route calls the way they did before. Any changes in behavior or user experience are identified, so customers can be guided through them.
The aim is parity for the features customers depend on, rather than automatically recreating unused or obsolete legacy settings.
How do providers achieve feature parity?
Inventory. Record which features are assigned and, where usage information is available, identify which features customers actively rely on.
Feature mapping. Match each source feature to the appropriate services and configurations on the destination platform.
Classify gaps. Mark each feature as a direct match, an equivalent with a different setup, a documented exception or a candidate to retire.
Agree exceptions. Review any feature that will behave differently with the provider and, where needed, the customer.
Test behavior. Place test calls to confirm features work, rather than relying on configuration alone.
Which features should be checked in a voice platform migration?
Feature | What parity looks like | What to test |
|---|---|---|
Hunt groups and call queues | Calls ring the same members in the same order | Ring strategy, overflow and no-answer routing |
Auto attendants | Callers hear the same menus and reach the same destinations | Menu options, after-hours schedules, holiday routing |
Voicemail | Messages are delivered and retrieved as before | Greetings, voicemail-to-email, message waiting indicators |
Call forwarding and find-me | Forwarding rules still apply | Busy, no-answer and unconditional forwarding |
Shared lines and busy lamp field | Users see colleagues' line status | Line appearance and pickup on each supported device model |
Paging and intercom | Paging groups reach the same phones | Group membership and device support |
Call recording | Recording applies to the same users and calls | Policy, storage and retrieval |
Emergency calling (E911) | Location data is correct for each number | Address records and test calls where permitted |
What happens when parity is not one-to-one?
Some legacy features have no direct equivalent or work differently on the new platform. A paging configuration or a custom routing rule may need a different setup. In these cases, the right outcome is a documented exception with an approved resolution before cutover, rather than a surprise afterward. Our NetSapiens migration data validation checklist covers how to record and resolve these exceptions.
Many commonly used Metaswitch and BroadWorks capabilities have equivalents in NetSapiens, but the platforms do not model every feature the same way. During discovery, Vox Matic maps the existing environment, and settings that need a different treatment in NetSapiens are flagged for engineering review and discussed with the provider before cutover.
Frequently asked questions
Does feature parity mean features must work identically?
No. It means the features customers depend on deliver the same result. A hunt group may be configured differently on the destination platform and still ring the right people in the right order.
What is the difference between feature parity and feature mapping?
Feature mapping is the process of matching source features to destination services and configurations. Feature parity is the outcome: confirmed, tested equivalence for the features customers use.
What happens to unused legacy features?
Features that are assigned but not used may be candidates for retirement during migration, with the provider's approval. Removing them simplifies the new environment and avoids carrying legacy complexity forward.
Related terms
Moving customers to NetSapiens without losing the features they use?
Talk to Vox Matic about mapping and validating your feature set before cutover.
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.