How to Migrate from UCCX to Webex Contact Center

UCCX reaches end of life on December 31, 2028. That gives most organizations enough runway to migrate properly — but "properly" means starting now, not in 2027. A medium-complexity UCCX environment (25–75 agents, 5–15 queues, moderate IVR complexity) typically takes 4–7 months from discovery through production cutover. Larger environments with heavy IVR customization, multiple PSTN circuits, or complex CRM integrations can take 9–12 months.

This guide walks through each phase in order. Phase dependencies matter: don't start Phase 3 without Phase 2 design decisions locked, and don't start Phase 5 without Phase 3 IVR builds validated.

Phase 1 — Discovery & Assessment

Discovery is where most migration projects go wrong. Teams scope based on what they think is in the environment, not what's actually there. The only way to scope a UCCX migration accurately is to export and document everything — scripts, queues, agents, integrations, and PSTN configuration — before any design work starts.

The CUCM BAT export gives you the call control layer: directory numbers, device pools, route patterns, hunt groups, shared lines. The UCCX configuration lives separately — scripts in the UCCX Repository, queue definitions in UCCX Admin, skills and teams in the supervisor interface. Both need a complete export.

Pay particular attention to IVR scripts that use custom Java steps, external database queries, or CTI integrations. These are the items that will consume the most time in Phase 3. Finding them in discovery means you can budget for them. Finding them two weeks before cutover means you're either delaying or cutting scope.

Phase 2 — Design & Pilot Environment

Phase 2 translates the Phase 1 inventory into a Webex CC architecture. The three design decisions that have the most downstream impact are: PSTN path, IdP/AD sync approach, and agent license type.

PSTN path is the decision most teams leave too late. If you're migrating to Webex CC cloud-native, your numbers need to port to Webex Calling — a process that takes 2–6 weeks and requires carrier coordination. If you can't break existing circuit contracts during the migration window, the Local Gateway path lets existing PRI/T1/SIP circuits continue operating through a Cisco IOS-XE gateway that hairpins to Webex CC. The third option is Cloud Connected PSTN via a Cisco-certified carrier — useful if you want cloud PSTN without full Webex Calling adoption. For a deeper comparison of platform differences, see our UCCX vs Webex Contact Center overview.

Set up a pilot environment in Webex CC with at least one test queue before Phase 3 starts. Engineers building flows in a production-only tenant make mistakes that wouldn't happen with a safe test environment. The pilot queue also serves as the first UAT target in Phase 5.

Phase 3 — IVR & Flow Conversion

IVR conversion is the longest phase of any UCCX migration. UCCX Editor scripts (.aef files) do not import to Webex CC Flow Designer — they must be rebuilt. This is not a technical limitation that will be resolved in a future release; the platforms use fundamentally different architectures. Plan to rebuild every call flow from scratch.

The rebuild complexity depends heavily on what the existing scripts do. A simple IVR — main menu, 4–6 options, direct queue routing, after-hours handling — can be rebuilt in Flow Designer in 1–2 weeks by an engineer familiar with the platform. A complex IVR with custom Java steps that query an external database, generate a screen pop via CTI, and route based on caller history can take 4–8 weeks, particularly if the database connector needs to be redesigned for Webex CC's HTTP connector model.

Start with the simple flows. Building fluency on low-risk flows before tackling complex ones reduces errors and accelerates the team's velocity. Once you've rebuilt 3–4 simple flows, revisit the complexity estimates for the harder scripts — you'll have much better data.

Prompt and greeting migration is a hidden time sink. Export all .wav files from the UCCX Repository before the rebuild starts. Webex CC accepts .wav but has specific encoding requirements — many files need to be re-encoded. Build this into the IVR rebuild timeline, not as a separate post-conversion task.

Phase 4 — Agent & Supervisor Onboarding

Provisioning agents in Webex CC is different from adding users in UCCX Admin. Users must exist in Webex Control Hub and be synchronized from your IdP before they can be assigned to queues. If IdP sync was configured in Phase 2, this should be straightforward — but any agents not in the IdP (service accounts, test users) need to be created manually.

The Webex CC Agent desktop is browser-based — no thick client or VPN required for remote agents. This is a significant operational improvement over CAD and most Finesse deployments, but it does require agent retraining. Screen pop configurations, wrap-up codes, and after-call work timers all have Webex CC equivalents that work differently than UCCX. Document the workflow differences and train agents before parallel run starts.

Supervisor reporting in Webex CC uses Analyzer, not CUIC. The data model is different — queue metrics, agent state reporting, and historical reports all need to be recreated. Use the Phase 2 reporting baseline to confirm that Webex CC Analyzer produces equivalent outputs for every supervisor-critical report before cutover.

Phase 5 — Parallel Run & UAT

The parallel run validates that Webex CC handles production traffic correctly before you commit to cutover. The mechanics: configure a shadow queue in Webex CC that mirrors one of your production UCCX queues, route a subset of test calls to it, and validate behavior against expected outcomes. This isn't the same as load testing — it's behavioral validation under real conditions.

The rollback plan must be documented and tested before the parallel run starts, not after. Define the conditions under which you would revert production routing to UCCX, assign an owner to that decision, and confirm the revert can be executed within your RTO. If the rollback plan takes 4 hours to execute and your RTO is 30 minutes, you don't have a rollback plan — you have a migration that had better work.

UAT call scripts should cover every IVR path for every queue, including error paths and timeouts. Agents and supervisors who will work on the new platform should run the UAT, not just engineers. They will find usability issues that technical testing misses.

Phase 6 — Cutover & Decommission

Cutover is a planned event with a documented runbook, not an improvised migration. The runbook should specify: who is on the bridge, what the go/no-go criteria are, what step-by-step actions are taken to reroute production DIDs to Webex CC, how active calls are handled during the transition, and what the rollback trigger is if something goes wrong.

DID porting timing is the most common source of cutover delay. If you're porting numbers to Webex Calling, the port completes at a carrier-scheduled time that you don't control precisely. If you're using Local Gateway, you control the cutover by changing the routing on the IOS-XE gateway. Plan your cutover window around the PSTN path you selected in Phase 2.

After cutover, run a hypercare period of at least 2–4 weeks before decommissioning UCCX. Keep UCCX running and reachable during this period — it's your fallback if a production issue surfaces after cutover. Before shutting UCCX down permanently: export and archive all CUIC historical data, archive all UCCX call recordings per your retention policy, and confirm that every supervisor-critical report is running correctly in Webex CC Analyzer.

Frequently Asked Questions