Implementing Gradual Agent Migration with Split-Queue Routing during Platform Transitions

How-To-Articles
1

Implementing Gradual Agent Migration with Split-Queue Routing during Platform Transitions

What This Guide Covers

You are in the middle of a migration from a legacy PBX to Genesys Cloud. You have a single high-volume queue (e.g., “Customer Service”) that currently has 100 agents on the legacy platform. You want to migrate 10 agents to Genesys Cloud today, 20 next week, and so on, without splitting the customer’s call into two different entry numbers. This guide implements a Split-Queue Routing strategy using Overflow Logic and Skill-Based Weighting to ensure that agents on both platforms receive work in the correct proportion while maintaining a unified queue experience for the customer.

Prerequisites, Roles & Licensing

  • Genesys Cloud: CX 1, 2, or 3.
  • Legacy Platform: Ability to accept SIP transfers or SIP Redirects.
  • SIP Interconnect: Established BYOC trunk between platforms.
  • Permissions: Routing > Queue > Edit.

The Implementation Deep-Dive

1. The “Dual-Homing” Logic

The goal is to have Genesys Cloud act as the primary traffic controller. Every call arrives at Genesys Cloud first.

Routing Logic:

  1. Call enters Genesys Cloud Queue (“Customer_Service_Migrated”).
  2. Router checks for an available agent on Genesys Cloud.
  3. If an agent is available, the call is delivered immediately.
  4. If NO agent is available, the call is Overflowed to the legacy platform.

2. Configuring the Overflow (Split)

In the Genesys Cloud Queue settings, configure the In-Queue Flow.

[In-Queue Flow: Customer_Service]
    |
    v
[Decision: Is there a Genesys agent available?]
    |
    |-- YES --> [Continue Waiting in Genesys Queue]
    |
    |-- NO  --> [Transfer to External Number: +15551000]
                (Legacy PBX Hunt Group)

3. Implementing Weight-Based Pacing

To prevent Genesys agents from being “swamped” (because they take the call before the legacy overflow), use Skill-Based Routing to throttle the volume.

  • Phase 1 (10% Migrated): Assign the “CS_Migrated” skill only to those 10 agents. Use an Architect flow to route only 10% of calls to the Genesys Queue and 90% directly to the Legacy SIP Trunk.

Architect Logic (Randomized Split):

[Update Variable: Flow.RandomValue = Random(1, 100)]
    |
    v
[Decision: Flow.RandomValue <= 10]
    |
    |-- YES --> [Transfer to Genesys ACD Queue]
    |
    |-- NO  --> [Transfer to Legacy SIP Trunk]

4. Preserving Queue Position (Advanced)

If a call is “Overflowed” to the legacy platform after waiting 60 seconds on Genesys, the customer effectively loses their place in line.

  • Solution: Implement Virtual Hold (Callback). Instead of transferring the live call to legacy, offer a callback. The callback can be placed in either the Genesys or Legacy queue based on current staffing levels, ensuring the customer doesn’t “start over.”

5. Managing Outbound Visibility

Migrated agents must be able to see the status of the legacy queue to avoid “over-calling” the dialer.

  • Pattern: Use a Reporting Dashboard (e.g., BrightMetrics or custom API dashboard) that aggregates “Agents On Call” from both the Mitel/Avaya SQL DB and the Genesys Cloud Analytics API.

Validation, Edge Cases & Troubleshooting

Edge Case 1: Call Loopback

A call is transferred to the legacy platform, but no agent is available there either. The legacy system “redirects” it back to Genesys.
Solution: Implement Loop Detection. Attach a Participant Data attribute Transfer_Count = 1. If a call arrives with Transfer_Count >= 1, force it to stay on the current platform (queue it) rather than transferring it again.

Edge Case 2: Inbound Caller ID Loss

When Genesys overflows to legacy, the legacy agent sees the Genesys SBC’s IP as the caller, not the customer.
Solution: Ensure the SIP Trunk is configured for P-Asserted-Identity (PAI) passthrough. This allows the legacy PBX to see the original PSTN ANI.

Edge Case 3: Transfer “Flash” (Double Charging)

Every call that enters Genesys and then overflows to legacy consumes two SIP trunk paths (one in, one out).
Solution: Use SIP Refer (if supported by the carrier and both platforms). This “hands off” the call entirely to the legacy platform, freeing up the Genesys trunk path and reducing PSTN costs.

Official References