Implementing Parallel Run Strategies for Simultaneous Legacy and Cloud Contact Center Operation

How-To-Articles
1

Implementing Parallel Run Strategies for Simultaneous Legacy and Cloud Contact Center Operation

What This Guide Covers

This guide details the architectural patterns and routing configurations required to operate a legacy PBX/ACD and a cloud contact center concurrently. You will configure SIP trunk interconnects, DNS-based traffic splitting, and API-driven session synchronization to maintain state parity during a phased migration. The end result is a resilient dual-platform environment where inbound traffic is distributed deterministically, agent states are correlated across systems, and compliance recording remains centralized without service interruption.

Prerequisites, Roles & Licensing

  • Licensing Tier: Genesys Cloud CX 3 or NICE CXone Unified (required for advanced routing, webhook streaming, and WFM API access)
  • Platform Permissions: Telephony > Trunk > Edit, Routing > Flow > Edit, Administration > API > Manage, Telephony > SBC > Configure
  • OAuth Scopes: telephony:trunk:read, routing:flow:write, integrations:webhook:manage, wfm:schedule:read
  • External Dependencies: Session Border Controller with NAT traversal and media transcoding capability, legacy ACD with SIP outbound/inbound support, DNS provider supporting weighted/SRV records, middleware server for state normalization (Node.js/Python recommended)

The Implementation Deep-Dive

1. SIP Trunk Interconnect & Media Path Architecture

The foundational layer of a parallel run is the SIP interconnect between the cloud platform and the legacy infrastructure. You must decide between direct media and transit media. For parallel operations, transit media is mandatory. Transit media forces all RTP streams through the cloud platform, which enables centralized recording, compliance archiving, and consistent codec handling regardless of which system originates or terminates the call.

Configure the cloud platform SIP trunk to point to the SBC. Set the trunk to Transit Media and disable Direct Media. On the SBC, create a dial plan that routes inbound INVITEs from the cloud platform to the legacy PBX SIP trunk group. Enforce G.711 (ALaw) as the sole codec on the interconnect. Legacy systems frequently negotiate G.729 or iLBC, which introduces compression artifacts and DTMF relay failures when bridged to cloud endpoints. Forcing G.711 eliminates transcoding latency and guarantees DTMF pass-through via RFC 2833.

The Trap: Allowing direct media across the interconnect during a parallel run. When the cloud platform tears down the SIP dialog, it assumes it owns the media path. If media is direct, the cloud platform sends a BYE while the legacy system continues streaming RTP. This causes orphaned media sessions, compliance recording gaps, and unpredictable one-way audio when agents transfer between platforms. Transit media eliminates this failure mode by making the cloud platform the authoritative media anchor.

Configure the trunk using the Genesys Cloud Telephony API. The payload below establishes a transit-media trunk with strict codec enforcement and DTMF handling.

POST https://api.mypurecloud.com/api/v2/telephony/providers/edges/trunks
Authorization: Bearer <ACCESS_TOKEN>
Content-Type: application/json

{
  "name": "Legacy-PBX-Interconnect",
  "type": "sbc",
  "sbcId": "sbc-uuid-from-environment",
  "configuration": {
    "sipUri": "sip:legacy-pbx.sbc.domain.com:5060",
    "transport": "TCP",
    "mediaMode": "TRANSIT",
    "dtmfHandling": "RFC2833",
    "codecs": [
      {
        "name": "PCMU",
        "enabled": true
      },
      {
        "name": "PCMA",
        "enabled": true
      }
    ],
    "authentication": {
      "type": "usernamePassword",
      "username": "cloud_trunk_auth",
      "password": "encrypted_credential_ref"
    }
  }
}

Validate the media path by placing a test call from a cloud softphone to a legacy extension. Inspect the SDP offer/answer exchange in the SBC packet capture. The a=sendrecv attribute must remain consistent, and the cloud platform must appear as the media endpoint in the c= and m= lines. If the SBC rewrites the connection address to the legacy PBX, direct media is active and the configuration requires correction.

2. DNS Traffic Splitting & Number Coexistence

Full number porting is rarely feasible during a parallel run. You must split inbound traffic at the DNS or carrier STP level. DNS-based splitting using weighted A records or SRV records provides granular control without carrier dependency. Configure your DNS provider to return multiple target IPs with explicit weight values. Set the TTL to 300 seconds. A lower TTL increases resolver query volume, which degrades carrier DNS performance. A higher TTL delays traffic redistribution during failover or capacity adjustments.

Route traffic through separate SBC clusters. The primary SBC cluster terminates cloud-bound traffic. The secondary SBC cluster terminates legacy-bound traffic. Both clusters share the same public DNS namespace but resolve to different load balancer VIPs. Configure the cloud platform routing flow to inspect the P-Asserted-Identity or From header to identify legacy-originated calls. Apply distinct routing logic based on the source.

The Trap: Using round-robin DNS without TTL management or health checks. Round-robin distribution ignores server capacity and geographic latency. When a DNS resolver caches the record, it continues sending traffic to a saturated or offline SBC until the TTL expires. This creates call abandonment spikes and violates SLA thresholds. Weighted DNS with proactive health monitoring prevents uneven distribution and ensures traffic shifts deterministically.

Implement weighted DNS records through your provider API. The example below demonstrates a 70/30 split between cloud and legacy ingress points.

PUT https://api.dnsprovider.com/v2/domains/example.com/records
Authorization: Bearer <DNS_API_KEY>
Content-Type: application/json

{
  "name": "sip.example.com",
  "type": "A",
  "ttl": 300,
  "records": [
    {
      "data": "203.0.113.10",
      "weight": 70
    },
    {
      "data": "203.0.113.20",
      "weight": 30
    }
  ]
}

In the cloud platform routing flow, add a Set Variable block that evaluates the SIP URI pattern. Use the expression getFlowData("TrunkId") to identify the interconnect trunk. Route legacy-originated calls to a dedicated queue that applies legacy-specific wrap-up time and compliance rules. This prevents cross-platform metric contamination.

3. Session State Synchronization via REST APIs

Agents will operate in one platform or the other during a parallel run, but supervisors, WFM systems, and CRM platforms require a unified view of call state. You must synchronize session data without introducing polling overhead or duplicate records. Webhook streaming is the only viable approach for real-time parity.

Register a webhook endpoint in the cloud platform for call:state:change events. Configure the middleware endpoint to accept POST requests with HMAC signature validation. The middleware normalizes the webhook payload, maps cloud agent IDs to legacy extension numbers, and pushes the state to the legacy supervisor console or unified dashboard. Implement exponential backoff retry logic for failed deliveries. Set the maximum retry count to 5 with a base delay of 2 seconds.

The Trap: Polling the cloud API every 2 seconds for call state. This approach triggers rate limiting, consumes excessive API quota, and creates inconsistent UI updates when network latency causes race conditions. Polling also fails to capture transient states like ringing or queued, which degrade supervisor visibility. Webhook streaming delivers state changes exactly once, preserves event ordering, and eliminates polling overhead.

Register the webhook using the Integrations API. The payload below configures the endpoint with HMAC validation and retry policies.

POST https://api.mypurecloud.com/api/v2/integrations/webhooks
Authorization: Bearer <ACCESS_TOKEN>
Content-Type: application/json

{
  "name": "Legacy-State-Sync-Webhook",
  "endpointUrl": "https://middleware.internal/api/v1/call-state",
  "events": [
    "call:state:change"
  ],
  "security": {
    "type": "hmac",
    "hmacKey": "generated_symmetric_key_32bytes"
  },
  "deliverySettings": {
    "retryPolicy": "exponentialBackoff",
    "maxRetries": 5,
    "baseDelayMs": 2000
  }
}

The middleware must implement idempotency. Extract the callId and timestamp from the webhook payload. Store the latest state in a key-value store with a 24-hour TTL. When the legacy supervisor console requests state updates, the middleware queries the store and returns a deduplicated payload. This prevents duplicate case creation in CRM systems and ensures accurate queue occupancy metrics.

4. WFM & Analytics Parity Configuration

Workforce management and analytics systems require consistent shrinkage factors, wrap-up time definitions, and availability states across both platforms. During a parallel run, agents are scheduled in the legacy WFM system or the cloud WEM module. You must export and normalize scheduling data to maintain accurate service level calculations.

Configure the cloud WFM API to export schedule data daily. Map cloud availability codes to legacy status codes. Apply a unified shrinkage factor that accounts for platform-specific wrap-up time handling. The cloud platform calculates wrap-up time from agent disconnect to available state. Legacy systems often calculate wrap-up from call completion to next ready state. Normalize these definitions by adding a fixed offset to legacy wrap-up durations before merging datasets.

The Trap: Merging utilization data without normalizing wrap-up time and shrinkage definitions. This corrupts SLA reporting, inflates occupancy metrics, and triggers false staffing alerts. When legacy and cloud data use different time boundaries, the unified report shows agents as simultaneously available and in wrap-up. Normalization eliminates this discrepancy and ensures accurate capacity planning.

Use the WFM API to export schedule data and apply normalization rules in the middleware. The example below retrieves schedule data for a specific date range.

GET https://api.mypurecloud.com/api/v2/wfm/schedules/groups/{groupId}/entries?dateRange=2024-01-01,2024-01-31
Authorization: Bearer <ACCESS_TOKEN>
Content-Type: application/json

Process the response in the middleware. Group entries by agentId and date. Calculate total scheduled minutes. Apply the shrinkage factor using the formula: Effective Minutes = Scheduled Minutes * (1 - Shrinkage Factor). Export the normalized dataset to the unified reporting layer. Reference the WFM Data Normalization for Hybrid Environments guide for advanced shrinkage modeling and absence handling.

Validation, Edge Cases & Troubleshooting

Edge Case 1: SIP 408 Request Timeout During DNS Failover

  • The failure condition: Inbound calls drop with a 408 Request Timeout when DNS TTL expires and the resolver switches to the legacy SBC IP.
  • The root cause: SIP INVITE retransmission timers (T1, T2, T4) expire before the DNS resolver completes the new lookup and the SBC establishes the TCP connection. The cloud platform abandons the transaction.
  • The solution: Configure the SBC to handle SIP retransmissions aggressively. Set the INVITE retransmission timer to 500ms and the maximum retransmissions to 10. Implement DNS health checks with proactive TTL reduction to 60 seconds during scheduled cutover windows. Monitor SIP transaction logs for 408 responses and adjust resolver cache policies accordingly.

Edge Case 2: Codec Mismatch Causing One-Way Audio on Legacy-to-Cloud Transfers

  • The failure condition: An agent on the legacy PBX transfers a call to a cloud queue. The caller hears silence while the agent audio passes.
  • The root cause: The legacy system negotiates G.729. The cloud trunk expects Opus. The SBC attempts real-time transcoding but experiences CPU saturation due to concurrent transfers. The RTP stream drops on the return path.
  • The solution: Enforce G.711/ALaw on the interconnect trunk. Disable Opus and G.729 on the legacy bridge. Add SBC CPU monitoring with an alert threshold at 70 percent utilization. Configure the SBC to fallback to G.711 when transcoding CPU exceeds the threshold. Validate the codec negotiation sequence using Wireshark and confirm the a=rtpmap line matches on both sides.

Edge Case 3: Duplicate CRM Updates from Dual Webhooks

  • The failure condition: The same call triggers case updates in both the legacy CRM and the cloud CRM. Duplicate records appear, and workflow automation executes twice.
  • The root cause: The middleware lacks idempotency keys and call correlation logic. Webhook retries deliver duplicate payloads, and the CRM integration does not check for existing records before insertion.
  • The solution: Implement a deterministic call correlation key using ANI + timestamp + sequence. Use database upsert logic with ON CONFLICT DO NOTHING or equivalent. Configure the webhook retry policy to drop duplicates after the first successful delivery. Add a deduplication window of 30 seconds in the middleware to handle out-of-order event delivery.

Official References