SIP Trunk Migration Checklist: Moving Without Disrupting Business Calls

A SIP trunk migration is not simply a change of login details. Business numbers, call routes, PBX configuration, capacity, emergency arrangements and supplier responsibilities all need to move in a controlled order. The safest migration is one in which the new service is tested before live numbers depend on it.

This checklist assumes you already understand the basic service. If not, begin with our guide to SIP trunks for UK businesses.

1. Define the scope and owners

List the sites, PBXs, telephone numbers and departments affected. Name the people responsible for the current provider, new provider, PBX, firewall, connectivity and business testing. Agree an escalation route and the person authorised to make cutover decisions.

Set success criteria such as correct inbound routing, outbound presentation, emergency calling, queue behaviour and call quality. A vague goal to “move the phones” makes it difficult to decide whether the migration is ready.

2. Audit every number and service

Obtain a verified list of geographic, non-geographic and direct-dial numbers. Record the current provider, billing account, installation address and where each number routes. Include numbers used only for campaigns, alarms, door entry, fax or out-of-hours services.

Do not cancel the existing service. Cancellation can cause number loss or prevent a port. A managed business number-porting plan should be agreed before the old account is changed.

3. Confirm PBX and firewall compatibility

Check that the PBX version, licences and SIP implementation are supported by the new provider. Review authentication, codecs, DTMF, encryption, caller-ID formats, registration or IP-based delivery and any session border controller requirements.

Document firewall and NAT changes. Avoid broad, permanent rules created only to make a test pass. Confirm whether SIP ALG should be disabled and how provider signalling and media ranges will be maintained.

4. Size channels and connectivity

Use historic call data to estimate peak concurrent calls, including queues, conferences and forwarded calls. Confirm how limits are applied and what callers experience when capacity is exhausted.

Assess upload bandwidth, latency, jitter and packet loss at each site. The business SIP trunk service and underlying connectivity should be designed together where call availability is important.

5. Build and test before porting

Where possible, configure the new trunk with temporary numbers or controlled test routing. Test inbound and outbound calls, transfer, hold, voicemail, queues, DTMF, conferencing, recordings and calls of realistic duration. Check both fixed and remote users.

Verify caller identification in both directions. Test emergency-call handling and confirm the address information and organisational process that apply. Record test results and resolve intermittent faults before requesting the main port.

6. Prepare the port order carefully

Match the losing provider’s records exactly. Confirm the range holder, main billing number, account name, postcode and whether numbers form part of a range. Submit a complete list and identify services that may cease when the range is ported.

Agree a realistic date only after validation. Inform stakeholders of the window, expected behaviour and contact route for problems. Avoid scheduling a critical port immediately before a major business event or when key technical staff are unavailable.

7. Control the cutover

Freeze unrelated PBX and network changes. Keep current configurations and recovery information available. At the agreed time, test every important inbound route from external networks and place outbound calls presenting representative numbers.

Check queue announcements, schedules, voicemail and failover—not only a call to reception. Ask business testers at different sites to confirm behaviour. Log timestamps and call examples so suppliers can trace any fault quickly.

8. Monitor after migration

Watch registration, channel use, rejected calls, quality statistics and user reports during the first working days. Reconcile the final number list and confirm that no published number was missed.

Retire old services only after successful port confirmation and a billing review. Keep the migration record, test evidence and final configuration for support and future changes.

Common migration mistakes

Frequent problems include submitting an incomplete number range, changing firewall rules at the last moment, overlooking external forwarding and assuming that a PBX template guarantees full interoperability. Another common mistake is allowing commercial cancellation dates to drive the technical cutover before testing is complete.

Avoid making several unrelated changes together. Replacing connectivity, firewall, PBX and SIP provider in one unstructured event makes fault isolation much harder. Where the programme requires several changes, define testable stages and keep a record of the last known working state.

Prepare employees and customer-facing teams

Tell employees what will change, when it will happen and how to report a fault. Reception and customer-service teams should have an alternative contact route during the window. Provide short role-based guidance for transfers, queues, voicemail and any new applications.

After cutover, ask users for specific examples rather than general impressions. A timestamp, number dialled, direction and observed behaviour give technical teams useful evidence. Combine this feedback with provider logs before deciding that a problem is local, platform-related or network-related.

Migration checklist summary

• Inventory numbers, services and call routes.
• Confirm PBX, firewall, capacity and connectivity requirements.
• Build and test the new trunk before number porting.
• Validate losing-provider records and agree a controlled date.
• Test complete call journeys during cutover.
• Monitor, reconcile and close old services only when confirmed.

A well-managed migration separates preparation from the live number event and gives each party clear responsibility. Ask I.T Communications to review your SIP migration before committing to a cutover date.