Migrating from PRI to SIP without a bad week

Replacing ISDN with SIP is a well-trodden migration, and the parts that go wrong are rarely the parts people prepare for. The SIP trunk usually registers on the first attempt. Number porting, emergency calling and the order of the cutover are what turn a routine change into a bad week.

Start with an inventory of what the PRI actually carries

Before anything else, find out what is genuinely on those circuits. In most organizations there is more than the phone system:

• Every DDI range, including ranges nobody uses but which appear on printed material.
• Fax lines — accounts, legal, and sometimes one in a warehouse nobody has mentioned since 2014.
• Lift emergency lines, alarm diallers and building management dial-outs. These are frequently on the same delivery and frequently forgotten.
• Analogue extensions behind gateways.
• Anything doing outbound-only calling, such as an automated notification system.

The fax and alarm lines are the ones that cause incidents, because they fail silently: nobody notices a fax line is dead until a supplier says they have been sending invoices for three weeks.

Porting sets the timeline, not you

Number porting runs on the losing carrier’s clock and on the accuracy of your paperwork. Two things reduce the risk:

• Match the details exactly to the losing carrier’s records — legal entity name, installation address, account number, as they have it, not as it is correct today. A rejected port typically costs a week and the reason is almost always a mismatch of this kind.
• Port in stages. A pilot range first, main ranges next, everything else last. Porting a thousand numbers on one date concentrates every possible failure into one morning.

Keep the PRI running in parallel through the porting window. Paying for both for a month is trivially cheaper than a failed cutover.

Emergency calling needs an explicit decision

On a PRI, the location of a call is implied by the circuit. On SIP it is not — a trunk can be presented from anywhere, and a call to emergency services must reach the right control room with the right address.

Decide before cutover:

• What address is registered against each trunk and each number range.
• How a call from a remote or home worker is handled, since their physical location is not where the trunk is.
• Whether emergency calls can complete when the trunk is full, or when the internet link is down.

Then test it, by arrangement, rather than assuming. This is the single item on the list where an untested assumption has consequences beyond inconvenience.

Survivability changes shape

A PRI kept working when the internet did not. SIP does not, so the failure mode moves from “rare” to “whenever the circuit does”. Decide what happens when the link drops: a second circuit on a different path, a mobile failover, or provider-side diversion of the main numbers to a mobile group. Any of the three is fine; none of them is the default.

A sequence that works

1. Inventory everything on the PRI, walking the building for the lines that are not in any document.
2. Order the SIP trunk and get it registered and tested alongside the live PRI.
3. Route outbound over SIP first, inbound still arriving on the PRI. Outbound is reversible in seconds.
4. Test call quality under real load for a week, with codec and QoS settings finalized.
5. Port a small pilot range and watch it for a week.
6. Port the main ranges in stages, keeping the PRI live.
7. Move the analogue oddments — fax, lifts, alarms — deliberately, testing each.
8. Cease the PRI only after a full month with nothing on it.

Routing outbound first is the step most often skipped and the one that finds most problems while they are still cheap to fix.

What to watch after cutover

Jitter, packet loss and one-way delay for the first month, plus the codec actually negotiated per trunk. Most post-migration quality complaints trace to a network path or a codec mismatch rather than to the trunk, and having the measurements already running turns a vague complaint into a specific one.

AcmaPBX runs alongside existing TDM gateways during exactly this kind of phased cutover, which is what makes the outbound-first step practical. If you are planning a migration, the inventory stage is worth a second pair of eyes.