Implementing Phased Migration Strategies from Avaya Aura to Genesys Cloud
What This Guide Covers
You are designing a phased, zero-disruption migration strategy to move your contact center from an Avaya Aura platform (Communication Manager, AES, CMS) to Genesys Cloud. When complete, your migration plan will allow individual agent groups, queues, and skill sets to be migrated independently over a 6-12 month timeline, with both Avaya and Genesys running in parallel during the transition-preserving SLA continuity, enabling rollback at any phase boundary, and ensuring no agent experiences a “big bang” cutover that disrupts their workflow.
Prerequisites, Roles & Licensing
- Genesys Cloud: Any CX tier (typically CX 3 for full WFO capability parity with Avaya CMS/WFM).
- Existing Infrastructure:
- Avaya Communication Manager (ACM) with ACD routing.
- Avaya CMS for historical reporting.
- Possibly Avaya Experience Portal (IVR), Avaya WFO/NICE WFM.
- Infrastructure:
- BYOC Cloud or Genesys BYOC Premise for SIP trunking from the same carrier during transition.
- A network that can route SIP calls to either platform based on DID.
The Implementation Deep-Dive
1. Why Phased Migration is Non-Negotiable
“Big bang” cutovers from Avaya to Genesys are the leading cause of migration project failures:
- Agents trained on Genesys Communicate but still handling calls for queues that haven’t been migrated yet.
- Supervisors running Avaya CMS dashboards for half the team and Genesys Cloud reporting for the other half.
- IVR prompts directing customers to queues that don’t exist yet on Genesys.
- A single issue on cutover night that requires an emergency rollback of 800 agents.
A phased approach limits the blast radius of any issue to the current phase’s scope.
2. The Five Migration Phases
Phase 1 (Weeks 1-4): Infrastructure & Pilot Group
├── Provision Genesys Cloud org (queues, skills, users)
├── Configure BYOC Cloud trunks from same carrier as Avaya
├── Migrate Pilot Group (10-20 agents, 1-2 non-critical queues)
└── Validate: Call routing, recording, reporting, WFM
Phase 2 (Weeks 5-8): Digital Channels
├── Migrate web chat, email channels to Genesys
├── Keep voice on Avaya for all non-pilot queues
└── Validate: Omnichannel routing, CRM screen pops
Phase 3 (Weeks 9-16): Queue-by-Queue Voice Migration
├── Migrate one queue per week, in order of risk:
│ Week 9: General Inquiry (lowest risk)
│ Week 11: Technical Support
│ Week 13: Billing
│ Week 15: VIP/Retention (highest risk - migrate last)
└── Keep Avaya active for unmigrated queues throughout
Phase 4 (Weeks 17-20): IVR & Advanced Routing
├── Move IVR/IEP from Avaya Experience Portal to Genesys Architect
├── Implement skill-based routing parity
└── Validate: All call paths, edge cases, overflow routing
Phase 5 (Weeks 21-24): Decommission & Cleanup
├── Validate 30 days of stable operation
├── Decommission Avaya CMS reporting
├── Migrate historical reporting data to Genesys Analytics
└── Decommission ACM, AES, WFM legacy instances
3. The SIP Trunk Coexistence Architecture
During phases 1-4, both Avaya and Genesys receive live traffic simultaneously. Route DIDs using your SIP carrier’s SIP redirect rules:
[SIP Carrier]
|
|-- DID: +1-800-GENERAL --> [Avaya CM] (not yet migrated)
|-- DID: +1-800-TECH --> [Avaya CM] (not yet migrated)
|-- DID: +1-800-BILLING --> [Genesys Cloud BYOC] (migrated in Phase 3, Week 11)
|-- DID: +1-800-VIP --> [Avaya CM] (migrated in Phase 3, Week 15)
At each phase, you update the SIP routing rule for the target DID to point to Genesys Cloud - no changes to the customer-facing phone numbers.
Avaya trunk configuration: Ensure AES (Application Enablement Services) connectivity to Genesys is maintained for any in-flight agent-to-agent transfers during the transition period. An Avaya agent on a non-migrated queue may need to transfer to a Genesys agent on a migrated queue.
4. Agent Identity and Single Sign-On
Configure Genesys Cloud to use the same LDAP/Active Directory as Avaya OAUTH for agent SSO. Agents who are in both systems during the migration transition should use the same credentials. This prevents password fatigue and enables you to provision Genesys accounts in bulk from SCIM/AD sync before migration, so accounts are ready the moment an agent’s queue is migrated.
# Bulk provisioning script: sync Avaya CMS agent list to Genesys Cloud
import requests
import csv
def provision_agents_from_avaya_export(csv_path: str, access_token: str):
"""
Reads an Avaya CMS agent export and pre-provisions Genesys Cloud accounts.
Agents are created as 'inactive' until their queue is migrated.
"""
headers = {"Authorization": f"Bearer {access_token}", "Content-Type": "application/json"}
with open(csv_path) as f:
for row in csv.DictReader(f):
# Check if user already exists
email = row['email'].lower()
search = requests.get(
f"https://api.mypurecloud.com/api/v2/users?email={email}",
headers=headers
).json()
if search.get('total', 0) > 0:
print(f"User {email} already exists - skipping.")
continue
# Create Genesys user (pre-staged, not yet active)
requests.post(
"https://api.mypurecloud.com/api/v2/users",
headers=headers,
json={
"name": row['full_name'],
"email": email,
"department": row['department'],
"title": row['title'],
"state": "inactive" # Will be activated at phase cutover
}
)
print(f"Pre-provisioned: {email}")
5. Phase Rollback Criteria
Each phase should have clearly defined rollback triggers. If any of these occur within 48 hours of a phase cutover, revert the SIP DID routing back to Avaya:
- SLA falls more than 10 percentage points below baseline for 2+ consecutive hours.
- Agent satisfaction score (from pulse survey) drops below 3/5.
- Call quality complaints exceed 5% of interactions (transcription review).
- Any P1 incident (complete call routing failure) with > 15 minutes to resolution.
Document the rollback procedure and test it in the staging environment before each phase.
Validation, Edge Cases & Troubleshooting
Edge Case 1: Historical Reporting Gap
After migrating a queue to Genesys, historical queue data from before the migration exists only in Avaya CMS. Genesys Cloud Analytics starts accumulating data from day 1 of migration. Supervisors lose continuity.
Solution: Before decommissioning Avaya CMS, export all historical data to the shared data warehouse. Build dbt models (see companion guide) that merge pre-migration Avaya data with post-migration Genesys data into unified reporting tables.
Edge Case 2: Transfer Failures During Dual-Stack Operation
During phases 1-4, an agent on Genesys (migrated queue) may try to transfer a customer to a queue that is still on Avaya. Without explicit SIP trunk routing between the two platforms, the transfer fails.
Solution: Configure a BYOC integration that routes cross-platform transfers via SIP re-INVITE through the shared carrier. Map Avaya DN/skill codes to Genesys queue phone numbers in a translation table. Agents use a custom transfer panel that looks up the correct destination regardless of platform.
Edge Case 3: WFM Forecast Incompatibility
Your existing Avaya CMS WFM team uses historical interval data from CMS to generate forecasts. During the transition, the partially-migrated queues have split historical data between CMS and Genesys.
Solution: Maintain both WFM systems in parallel during the transition, with queues forecasted by whichever platform currently hosts them. After full migration, run a 90-day stabilization period in Genesys WFM using its historical data before decommissioning the Avaya WFM.