A PRI to SIP migration is often sold as a simple carrier upgrade: replace an old circuit, keep the numbers, and reduce the bill. The carrier handoff may be simple. The surrounding system is not. Number ownership, call capacity, emergency locations, faxing, analog alarms, firewall behavior, and PBX licensing can each stop the cutover.
Build the plan around call flows and rollback, not the carrier's requested disconnect date. A PRI sunset notice creates urgency, but it does not make an untested port order safe.
What a PRI is and why carriers are sunsetting it
A Primary Rate Interface is a digital, circuit-switched trunk between a carrier and a customer's phone system. In a common North American deployment it rides on a T-carrier facility, provides a fixed bundle of bearer channels for calls, and uses a separate channel for signaling. The PBX sees predictable call paths and a physical carrier handoff.
PRI belongs to the legacy time-division multiplexed network. Carriers are moving voice onto packet infrastructure and retiring the switches, transport, interface cards, spares, and operational skills that keep TDM services running. As demand declines, the cost and difficulty of maintaining parallel voice networks rise. Customers then see stop-sell policies, rate changes, mandatory migrations, or retirement notices.
“PRI sunset” is not one nationwide event. The relevant trigger is the written notice for your circuit, central office, and carrier. Confirm the last order date, service-change restrictions, retirement date, and what happens if porting is still pending.
The two destinations: SIP trunking or full cloud UCaaS
SIP trunking and unified communications as a service solve different scopes of problem.
| Decision area | SIP trunk to existing PBX | Full UCaaS migration |
|---|---|---|
| Call control | Remains on your PBX | Moves to the provider's cloud platform |
| User devices | Often retained if the PBX remains supported | May require supported phones, apps, or replacements |
| Local integrations | Usually preserved, subject to PBX and gateway behavior | Must be rebuilt or replaced against the UCaaS platform |
| Operational ownership | Your team maintains PBX, licenses, and often the SBC | Provider operates call control; your team manages policy and users |
| Project scope | Trunk, routing, security, porting, and compatibility | Users, endpoints, features, integrations, porting, training, and sites |
| Best reason to choose it | The PBX is valuable and supportable | Retiring the PBX is an actual business objective |
Choose SIP when the PBX has useful life, required integrations, current support, and a proven interoperability path. Confirm whether it speaks SIP natively or needs a session border controller, gateway, or license.
Choose UCaaS when keeping the PBX would preserve a support problem, or when the company needs common administration and calling across offices. Do not choose it solely because a carrier is retiring PRI. UCaaS changes endpoints, user experience, emergency calling, contact-center behavior, and administrative control; budget and test those changes explicitly.
Size concurrent calls, not DIDs
A DID is a telephone number that routes to a user, queue, auto attendant, fax, or application. It does not reserve a call path. A business can own many DIDs while using relatively few simultaneous calls, or have few published numbers feeding a busy contact center.
SIP trunks are commonly sized and controlled by concurrent sessions or call paths. To find your requirement:
- Export call-detail records from both the PBX and carrier for representative normal and peak periods.
- Measure simultaneous inbound and outbound calls rather than total calls per day.
- Separate contact-center traffic, conferences, fax sessions, recording forks, and any application that consumes extra sessions.
- Model a site or trunk failure. Rerouted traffic from another office may create a peak the surviving trunk never sees in normal operation.
- Add growth and event headroom based on the company's plan, then document the assumption.
- Ask how the provider handles a limit: block, queue, burst, reroute, or bill differently.
Repeat the analysis by location and by shared trunk group. Pooling can improve utilization across sites, but it also increases the impact of a carrier, SBC, or WAN failure.
Number porting mechanics and sequence
Porting is an identity-matching and routing process. The new provider submits the customer name, service address, account information, billing telephone number, numbers to port, and authorization to the losing carrier. A mismatch can reject the request even when the business clearly owns the numbers.
The losing carrier controls the practical timeline because it holds the active routing until the port and must validate the order against its customer record before releasing the numbers. The gaining provider can submit, correct, and escalate the request, but it cannot unilaterally approve that release. Treat a requested date as a preference until the gaining provider confirms that the losing carrier has accepted the order and committed to the cutover.
Build a number inventory from carrier records and PBX configuration. Include main numbers, DIDs, fax, toll-free service, conference bridges, hunt groups, remote call forwarding, and numbers that receive only occasional calls. Mark ranges and identify numbers that must stay together. Ask the losing carrier for a current customer service record where available, and make the letter of authorization match it exactly.
The safer sequence is:
- Configure the new SIP trunk or UCaaS tenant without changing public numbers.
- Test outbound calls and inbound calls on temporary numbers, including caller ID, transfers, queues, voicemail, recording, and after-hours routing.
- Validate the firewall, SBC, codec, DTMF, fraud controls, and carrier failover.
- Port a low-risk subset if both carriers support a partial-port design that will not break a number range.
- Schedule the main port only after the pilot passes and the gaining provider reports the losing carrier's firm order commitment.
- Test every critical number from outside networks during cutover and keep an incident bridge open.
- Disconnect the old PRI only after stabilization, reconciliation, and written business acceptance.
Porting works on carrier processing and validation time, not solely on your desired project date. A rejection restarts part of that exchange, so resolve record mismatches before tying the port to a larger office or system change. Toll-free numbers may use a separate control and porting process; identify their responsible organization and status independently.
What commonly breaks during migration
Fax and analog devices
Fax tones are sensitive to packet loss, timing, codec conversion, and gateway behavior. Test the real machine to its real destinations using the provider's supported fax method. For alarms, elevator phones, modems, and gate systems, do not assume the PBX analog port makes SIP acceptable. Follow a separate POTS line replacement and compliance review.
E911 and dispatchable location records
Register and validate the E911 dispatchable address required for each calling location. Pay attention to shared trunks, remote users, softphones, and devices that can move between offices. Confirm how the provider handles location updates, call-back numbers, on-site notifications, and loss of internet access. Place test calls only through the approved nonemergency procedure supplied by the provider or local public-safety organization.
PBX licenses and hardware
An older PBX may require SIP trunk licenses, new software, an SBC, certificates, or a gateway to translate from SIP to its existing interface. Check feature entitlements, vendor support, capacity, encryption, codec support, DTMF handling, caller-ID format, and high availability before signing the carrier order. “SIP compatible” is not an interoperability test.
Routing and security
SIP helpers and casual port forwarding often cause one-way audio or unstable registration. Use the provider's reference architecture, define trusted signaling sources, restrict management access, set fraud thresholds and alerts, and verify NAT behavior. If the trunk rides the public internet, document what happens during circuit failure and whether calls can reroute before they reach your PBX.
Use a phased cutover with a real fallback
Run the new and old trunks in parallel if the PBX supports it. Before porting, route selected outbound call types over SIP while the PRI remains the default fallback. Bring temporary inbound numbers through SIP and exercise every application path.
During a partial port, keep explicit routing tables for numbers on each carrier. Before the main port, prebuild carrier-side forwarding or alternate routing that can send calls to a tested destination if your SIP edge fails. After a number has ported, “fail back to PRI” is not automatic because the losing carrier no longer controls that number. Your fallback must be a route the new carrier can activate, not a hope that the old switch will take the call.
Keep the PRI until the acceptance period ends, but confirm how long the carrier will allow it to remain and what it costs. Then issue a written disconnect, remove obsolete routes and firewall rules, and audit later bills.
Questions to ask before signing
- Is the exact PBX version and SBC or gateway supported, and who owns interoperability remediation?
- How are concurrent calls measured, limited, burst, rerouted, and reported?
- What internet or private-access paths are supported, and what survives each failure scenario?
- Who owns the numbers, port records, toll-free control, and rejected-order escalation?
- How are emergency addresses, remote users, notifications, and location changes administered?
- Which fax method, codecs, DTMF modes, encryption options, and caller-ID formats are supported?
- What fraud controls, spend limits, authentication, logs, and incident contacts are included?
- What are the service term, renewal, notice window, port-out terms, and termination charges?
Check access options at every site
SIP and UCaaS are only as usable as their access and failover design. Check which carriers report service at each business address before tying the voice migration to one network path. Checking several addresses at once takes no longer than checking one, while engineering and cutover still remain site-specific.
InventiveHQ sources quotes through carrier channel agreements; the chosen carrier delivers and bills, and the buyer pays nothing for sourcing because carriers fund the channel from the same budget as direct sales. Sign only after the porting, capacity, emergency-calling, and fallback responsibilities are written down.