SIP Trunk Number Porting: Controlling the Cutover Window

SIP Trunk Number Porting: Controlling the Cutover Window

Ask an operations team when they will move their trunks to a new carrier and you will usually get two answers: the date the carrier promised, and the date the project plan says is safe. Those two dates are often weeks apart, and the gap between them is where inbound calls get lost. Porting a number block looks like a paperwork exercise from the outside, but in practice it is a coordinated cutover involving an ordering carrier, a losing carrier, a losing carrier's downstream network owners, a voice firewall strategy, and at least one business day where inbound reachability is uncertain. The purpose of this article is to treat porting as a change window with a defined start, a defined abort point, and a defined verification step, rather than as a task someone marks complete when the paperwork is filed.

Why Porting Projects Slip

Most delay comes from information that only one party holds. The order form is complete, but the authorized customer identifier on the losing carrier account does not match the name on the new account, and the request bounces back. Or the number block is portable in principle but sits behind a reseller relationship that has to authorise the release separately. Or a fax-on-demand or alarm circuit is still attached to the number and holds it. Or the port completes, the new carrier accepts the calls, and the inbound route in the business's own firewall or DNS-based routing layer was never updated, so calls still arrive at the old destination and are simply lost. Planning means finding these dependencies before the cutover date, not during it.

The Pre-Port Dependency Check

Before committing to a date, confirm that every number in the block is actually portable and actually free of attachments. This sounds obvious, but attachments are the single most common cause of a rejected port request. Numbers may carry fax service, a paging tie-in, an emergency address record, a direct inward dial entry in the old system, or a legacy alarm circuit that nobody remembers installing.

• List every number in the block and confirm each one is portable under the losing carrier's current terms
• Identify fax, paging, alarm, and elevator or door-entry tie-ins attached to any number in the block
• Verify that the authorised contact and customer identifier on the losing account match the new order form exactly
• Confirm whether any reseller or downstream carrier relationship requires a separate release authorisation
• Check for numbers that are listed as ported or pending elsewhere, which will cause an automatic rejection
• Confirm the new carrier has completed a test fit and has the address, contact, and routing information on file
• Establish a single named owner on both sides with authority to approve the cutover or abort it

Sequencing the Cutover

Order matters more than most teams expect. The safest sequence keeps one working path until the next one is proven, and never removes a working path before a replacement is verified. The typical sequence below keeps inbound calls answering at every step, which means a failure at any point is a delay rather than an outage.

One caution about the observation period. It must be long enough to cover the traffic that matters, not just the first hour. Emergency and inbound sales traffic tends to follow a diurnal pattern, so an observation window that closes at midday on a Tuesday has not tested much. Overnight and next-morning verification is where late routing failures usually surface.

The Abort Point

Every port project needs a written decision point at which the team stops and reverts. The abort point is defined in advance, in writing, with a specific clock time. Ambiguity here is dangerous: when inbound calls fail at 09:40 and the team has not agreed who decides, nobody decides, and calls keep failing while people argue about it. Define the abort threshold as something observable and unambiguous, for example a stated number of consecutive failed inbound test calls within a stated time window, or a stated number of reported missed calls from the business.

Rollback after a port completes is not always a simple action. In many cases the numbers have already left the losing carrier and cannot be moved back on demand, so rollback in the strict sense may not be available. The realistic rollback is to re-point routing at the old destination if a working path still exists, or to fail over to a temporary number range with divert announcements. That constraint is exactly why the old trunk should stay alive through the observation period rather than being cancelled on the port date.

Verifying a Completed Port

Verification should be scripted and repeatable so that any team member can run it. Test from an external network rather than from the office, because a call placed internally can succeed through a local path while external inbound is broken. Place test calls from at least two unrelated networks, and check inbound, outbound, and the behaviour of a transferred call, since transfers often expose routing differences that simple tests miss.

Recording the results of each check in the change record closes the loop. A port that is marked complete without a saved verification record will eventually be questioned by whoever inherits the system, and they will have no way to know which checks were actually run.

Common Failure Patterns

• The port completes correctly while the business firewall or inbound routing layer still points at the old destination
• Test calls are placed from inside the network and succeed through a path that external callers cannot use
• Emergency call routing context is not re-established on the new trunk and is discovered by a user, not by a test
• Fax or alarm services attached to the number are discovered only after the number has left the old carrier
• The old trunk is cancelled on the port date, removing the only practical rollback path
• The observation window is measured in hours rather than in a full traffic cycle
• No named decision owner exists, so a failing cutover stalls until external escalation becomes unavoidable

Redstone Approach

Redstone supports number porting and trunk transition projects as part of broader voice platform work. Our teams can review current trunk arrangements, help map dial plan and routing dependencies, coordinate cutover sequencing with your chosen carriers, script and run the verification checks, and stay available through the observation window. We work with the Redstone REX IP-PBX and RGW gateway lines to plan a transition that keeps inbound calling reachable, and we document the procedure so your team can repeat it for future moves. Specific configuration details depend on your existing platform and carrier terms, so we scope those in writing before any work begins.