Designing Number Porting Cutover Procedures with Zero-Downtime Migration Strategies

How-To-Articles
1

Designing Number Porting Cutover Procedures with Zero-Downtime Migration Strategies

What This Guide Covers

This guide details the architectural and operational procedures required to execute a Local Number Portability (LNP) cutover from a legacy PBX or SIP trunk provider to Genesys Cloud CX or NICE CXone without service interruption. You will learn how to configure dual-homing, implement DNS failover logic, and manage the critical “active-active” window where calls route through both providers simultaneously. The result is a deterministic cutover plan that eliminates the risk of dropped calls during the FCC-mandated porting window.

Prerequisites, Roles & Licensing

  • Licensing: Genesys Cloud CX (CX 2 or higher for advanced routing) or NICE CXone (Standard or higher). Voice Add-on licenses are required for all ported numbers.
  • Permissions:
    • Genesys: Telephony > Trunk > Edit, Telephony > Routing > Edit, Admin > Organization > Edit.
    • CXone: Telephony > Trunks > Manage, IVR Studio > Edit, Admin > Users > Manage Roles.
  • External Dependencies:
    • A secondary SIP Trunk provider (e.g., Bandwidth, Twilio, Telnyx) capable of supporting inbound and outbound traffic.
    • Access to the LoA (Letter of Authorization) and LoA-C forms for FCC-compliant porting.
    • Control over the domain DNS records (for SIP registration or HTTP-based routing if applicable).

The Implementation Deep-Dive

1. Establishing the Active-Active Dual-Homing Architecture

The fundamental error in most porting projects is treating the migration as a “switch” event. In reality, it is an overlap event. To achieve zero downtime, you must design a topology where the new cloud contact center (Genesys/CXone) and the legacy system are both active and receiving traffic simultaneously during the cutover window.

The Architectural Pattern:
You will configure the new platform as the primary destination for new DID numbers, while the legacy trunk remains active for existing numbers. However, for the numbers being ported, you must ensure that the new platform can accept traffic before the port completes. This requires provisioning the numbers on the new carrier before submitting the port request, or using a “port-out” strategy where the new provider acts as the destination carrier immediately upon approval.

Configuration Steps:

  1. Provision New Trunks:
    In Genesys Cloud, navigate to Admin > Telephony > Trunks. Create a new SIP trunk for the incoming carrier. Ensure the SIP Trunk profile allows inbound calls from the carrier’s IP ranges.

    {
  "name": "Primary_Carrier_Trunk",
  "description": "Inbound traffic from new LNP provider",
  "sip_profile_id": "sip-profile-inbound-id",
  "domains": ["example.com"],
  "call_leg_mode": "INBOUND",
  "codec_preferences": ["G722", "PCMU", "PCMA"]
}

    Note: In CXone, this occurs in Telephony > Trunks > Add Trunk. Ensure the Trunk Type is set to SIP and the Protocol matches the carrier requirements.

  2. Configure Inbound Routing Rules:
    You must create a routing rule that captures calls from the new carrier and directs them to the appropriate queue or IVR. Do not rely on default routing.

    • In Genesys, create an Inbound Routing Rule matching the From header or the Trunk ID.
    • Set the Destination to the primary IVR or Queue.
    • Critical: Enable Call Recording and Speech Analytics on this rule to monitor quality during the transition.

  3. The Trap: Codec Mismatch and NAT Traversal
    The most common failure point in dual-homing is not the routing logic, but the media path. If your legacy provider uses G.711u and your new provider defaults to G.722, and your firewall does not handle ALG (Application Layer Gateway) correctly, you will experience one-way audio or silent calls.

    • Solution: Force codec negotiation at the trunk level. In Genesys, edit the SIP Profile and explicitly order PCMU first if the legacy system is rigid. In CXone, use the Codec setting in the Trunk configuration to prioritize G711u.
    • NAT Trap: Ensure your carrier IP ranges are whitelisted in your firewall. If you are using a cloud provider like Genesys, you do not control the egress IP. You must whitelist the carrier’s IP ranges in your firewall if you have any on-premise components (like a legacy PBX) still in the path. If you are fully cloud-to-cloud, ensure the carrier supports Connection: close and proper Via header handling to prevent loopback issues.

2. Designing the DNS and SIP Failover Logic

For advanced zero-downtime strategies, especially when porting large blocks of numbers, you may leverage DNS-based failover or SIP registration persistence. This section assumes you are using a SIP trunking provider that supports dynamic DNS updates or that you are managing SIP registrations directly.

The Strategy:
Instead of waiting for the port to complete, you configure the new platform to “listen” for the numbers. When the port activates, the carrier updates the routing in the SS7 network to point to your new trunk. If the port fails or is delayed, calls continue to route to the legacy provider.

Implementation:

  1. Configure SIP Registration Persistence (If Applicable):
    If your carrier requires SIP registration (common in E.164 Short Number Routing or certain SIP trunking models), you must register the new trunk with the carrier before the port goes live.

    • In Genesys, go to Telephony > Trunks > [Your Trunk] > SIP Registration. Enter the credentials provided by the carrier.
    • Monitor the Status field. It must show Registered before the porting date.
    • The Trap: If the registration fails, the carrier will drop calls to the porting numbers immediately upon activation. Test the registration 48 hours in advance. If it fails, check for 403 Forbidden (auth error) or 408 Timeout (firewall/NAT issue).

  2. Implement DNS Failover (For HTTP/SIP over TLS):
    If your architecture uses a DNS-based load balancer (e.g., AWS Route 53, Azure Traffic Manager) to route SIP traffic to your cloud provider, you can configure a low-TTL DNS record.

    _sip._tcp.example.com. 300 IN SRV 10 60 5060 sip-new-provider.example.com.
_sip._tcp.example.com. 300 IN SRV 20 60 5060 sip-legacy-provider.example.com.
    • Set the TTL (Time To Live) to 300 seconds (5 minutes).
    • During the cutover, if the new provider fails to register, you can manually swap the priority in DNS to route all traffic back to the legacy provider.
    • The Trap: DNS propagation delays. Even with a low TTL, recursive resolvers may cache the record for longer. To mitigate this, use dig or nslookup to verify the DNS record resolves correctly from multiple global locations before the cutover window.

  3. Architectural Reasoning:
    Why use DNS failover? Because it provides a “break glass” mechanism. If the porting process encounters an FCC hold or a carrier dispute, you can instantly revert traffic to the legacy system without reconfiguring IVR flows. This is superior to relying solely on the carrier’s routing updates, which are often opaque and delayed.

3. Orchestrating the Porting Window and Cutover Execution

The cutover window is typically 24-48 hours, depending on the carrier and the number of digits. You must execute a precise sequence of actions to ensure no calls are dropped.

Phase 1: Pre-Porting Validation (T-48 Hours)

  1. Verify Number Availability: Use the carrier’s API to confirm the numbers are eligible for porting.
    GET https://api.carrier.com/v2/porting/eligibility?phone_numbers=+1234567890
    • If the API returns NOT_ELIGIBLE, investigate the account status with the losing carrier. Common issues include unpaid bills or pending disputes.
  2. Test Inbound Routing: Place test calls to the numbers while they are still on the legacy provider. This will not work for the porting numbers themselves, but you can test the trunk connectivity using a spare DID.
  3. Validate Outbound Routing: Ensure that outbound calls from the new platform are using the correct From header. If you port numbers, you must update the outbound trunk configuration to use the new carrier for those numbers.
    • In Genesys, create an Outbound Routing Rule matching the From number range.
    • Set the Trunk to the new carrier.
    • The Trap: If you do not update outbound routing, calls originating from the ported numbers will still route through the legacy trunk, causing billing discrepancies and potential CLID (Caller ID) spoofing alerts.

Phase 2: The Porting Submission (T-24 Hours)

  1. Submit LoA/LoA-C: Use the carrier’s portal to submit the porting request. Ensure the Effective Date is set to a date that allows for a 24-hour buffer.
  2. Monitor Porting Status: Use the carrier’s API to poll the porting status.
    GET https://api.carrier.com/v2/porting/status?request_id=123456
    • Watch for status changes: PENDING, APPROVED, IN_PROGRESS, COMPLETED.
    • If the status is DENIED, you must resolve the dispute immediately. Common denials include mismatched account numbers or service addresses.

Phase 3: The Cutover Execution (T-0)

  1. Activate New Routing: At the moment the porting status changes to COMPLETED, the carrier will update the SS7 routing. Calls to the ported numbers will now arrive at your new trunk.
  2. Monitor Call Volume: Use Genesys Cloud Admin > Telephony > Call Volume or CXone Real-Time Dashboard to monitor inbound call volume.
    • If call volume drops to zero, check the trunk status.
    • If calls are being dropped, check the SIP logs for 488 Not Acceptable Here (codec mismatch) or 487 Request Terminated (timeout).
  3. The Trap: The “Zombie” Call Scenario
    During the porting window, some calls may be routed to the legacy provider while others are routed to the new provider. This is normal. However, if you have configured Call Forwarding or Voicemail on the legacy system, callers may hear a “Number Disconnected” tone if the legacy system does not recognize the number as active.
    • Solution: Ensure the legacy system is configured to accept calls for the porting numbers until the port is fully complete. If possible, disable call forwarding on the legacy system for these numbers to prevent routing loops.

Validation, Edge Cases & Troubleshooting

Edge Case 1: The “Split-Brain” Routing Conflict

The Failure Condition:
Calls to ported numbers are answered by the new IVR, but outbound calls from agents using those numbers are routed to the legacy trunk, causing Caller ID mismatch and regulatory violations (TCPA/STIR/SHAKEN).

The Root Cause:
The outbound routing rules were not updated to match the new trunk for the ported number ranges. The system defaults to the primary outbound trunk, which is the legacy provider.

The Solution:

  1. Create a specific Outbound Routing Rule in Genesys Cloud that matches the From number range of the ported numbers.
  2. Set the Trunk to the new carrier.
  3. In CXone, use the Routing > Outbound Routing menu to create a rule based on Dialed Number or From Number.
  4. Validate by placing a test call from an agent using a ported number and checking the From header in the SIP logs. It must match the ported number and route through the new trunk.

Edge Case 2: SS7 Routing Latency and Call Drops

The Failure Condition:
During the first 1-2 hours after the port completes, callers experience long ring times or immediate disconnects.

The Root Cause:
The SS7 network has not fully propagated the new routing information. Some switches are still routing calls to the legacy provider, which may reject them if the number is no longer active on that trunk.

The Solution:

  1. Implement a Retry logic in your IVR. If a call is disconnected within 2 seconds, retry the call once.
  2. Use Call Center Analytics to monitor Abandon Rate and Drop Rate during the cutover window.
  3. If drops persist, contact the carrier to force a routing refresh. Some carriers offer a “Push” feature to update the SS7 database immediately.
  4. The Trap: Do not rely solely on the carrier’s “Port Complete” notification. The SS7 propagation can take up to 24 hours. Monitor call quality metrics for the full 48 hours.

Edge Case 3: STIR/SHAKEN Attestation Failure

The Failure Condition:
Outbound calls from ported numbers are flagged as “Spam Likely” by carriers like AT&T or Verizon.

The Root Cause:
The new carrier has not been provisioned with the correct STIR/SHAKEN attestation level for the ported numbers. The losing carrier may have had A attestation, but the new carrier only has B or C until the port is fully verified.

The Solution:

  1. Verify with your new carrier that the ported numbers are enrolled in their STIR/SHAKEN program.
  2. If the carrier cannot provide A attestation immediately, consider using a B attestation with a clear disclaimer in your IVR.
  3. Monitor Call Blocking reports in Genesys Cloud Admin > Telephony > Call Blocking to identify which carriers are flagging your calls.
  4. The Trap: If you do not address STIR/SHAKEN, your deliverability will drop significantly, leading to customer complaints and potential regulatory fines.

Official References