Look beyond the platform before a voice migration.

Start with the calls the business cannot afford to mishandle

Ask reception, customer service, sales, operations, and facilities to explain how calls move through the organization. Include a normal business day, an after-hours call, a busy queue, and a local outage. Those walkthroughs often expose requirements that an extension count misses.

Record inbound routing, auto attendants, queues, transfers, delegation, shared lines, voicemail, mobile use, and reporting. Add contact-center, CRM or line-of-business integrations and any recording or retention requirements. For each critical workflow, name the owner, expected behavior, failure scenario, and evidence that will demonstrate it works.

Separate the work into business call flows, numbers and carrier services, devices and networks, emergency calling, and ongoing support. Use those requirements to evaluate the combinations of platform, connectivity, and delivery resources that can meet them.

Build a number and dependency inventory

Reconcile bills, carrier records, PBX exports, and the information maintained by local staff. Assign a purpose and owner to each number or service. Treat an unexplained line as a discovery item until someone verifies what it supports.

Give analog and safety-related services their own review

Make a separate decision for each physical service: retain its connection, use a supported adapter and interconnection, or replace it with a suitable arrangement. Test the actual function of fax, paging, door entry, and other attached devices. An ordinary voice-call test is insufficient evidence for those functions.

For alarms, elevator communications, and other safety-related services, involve facilities, the device or monitoring provider, and the relevant authority where required. Confirm compatibility, signaling, supervision, power backup, resilience, and the applicable approvals. Give each service a retain, replace, or migrate decision and an acceptance owner.

For fire alarms specifically, obtain written evidence that the proposed communication service satisfies the applicable code and authority requirements. Ask how backup power, transmission supervision, signaling, and acceptance are addressed. Confirm the adopted code edition and the responsible authority for your location; a generic replacement-service claim does not establish that the arrangement has been accepted.

Sources [1]

Test the paths people will actually use

Check representative offices, home users, Wi-Fi areas, shared devices, and mobile scenarios under relevant load. Review internet and local network paths, firewall and security treatment, VPN behavior, and power dependencies. A satisfactory speed test alone does not establish a reliable real-time voice path.

Measure delay, variation in packet arrival, loss, and congestion along the relevant paths. Internet-community guidance on real-time telephony identifies these as important service characteristics. Have the responsible network and voice teams agree on test conditions, acceptance criteria, and the evidence needed to investigate a poor call.

Exercise the response to a site connection failure, local power loss, and service-provider outage separately. Identify what remains available, how calls are redirected, who receives an alert, and how normal operation is restored. Confirm the behavior with representative users and critical devices.

Sources [2]

Make emergency calling an explicit workstream

For a US multi-line telephone system, review direct 911 dialing, notification, and dispatchable-location requirements under 47 CFR 9.16. The applicable obligations and technical conditions depend on the deployment and device types. Assign responsibility for configuration and validation with your provider and the appropriate customer stakeholders.

Document how location is established for office, shared, non-fixed, and remote devices, what happens when a user moves, who receives the notification, and how callback works. Use the provider’s approved validation process. Arrange any necessary live emergency test with the relevant provider and emergency communications authority in advance.

Sources [3] [4]

Plan porting and service retirement separately

Confirm number eligibility, carrier account information, authorization, required records, and the agreed porting scope before scheduling the move. For a partial port, identify the numbers and services that must remain and have the carriers confirm the resulting account configuration.

The FCC’s consumer guide advises initiating the new service and porting process before terminating the old service. Do not use a simple-port timing rule as an enterprise migration schedule. Agree on the actual port date and escalation process, then validate routing before closing services that are no longer needed. A successful port does not establish that every old charge or bundled dependency has ended.

Sources [5]

Agree on acceptance before the cutover

Translate requirements into test cases with an expected result, a responsible person, and evidence of completion. A pilot should include the difficult workflow or device that could change the design, as well as ordinary user calls.

Give the cutover a decision owner and a realistic fallback

Write down the go/no-go criteria, the person authorized to make that decision, the support bridge, user communication, and the way the business will operate if a critical test fails. Make the fallback specific to the failure. A completed number port may not be immediately reversible, so confirm recovery options with the carriers in advance.

After the move, review quality and unresolved issues over an agreed stabilization period. Confirm administration, support handoff, and the condition for retiring the legacy system. Reconcile bills and the remaining physical services before treating the migration as commercially complete.

Use one complicated workflow to focus discovery

Illustrative starting point: a multi-site organization has a main reception team, after-hours service, and paging at one location. Trace an inbound call through that environment and identify who owns each dependency. The exercise can reveal requirements for the broader migration without beginning with a platform demonstration.

GlobalLinc can help clarify requirements, compare platform and carrier approaches, and bring the right delivery resources into the discussion. Start with your current numbers and contracts, known workflow complications, locations, and the business outcome the migration needs to improve.