Cisco has set the clock. UCCX 12.5 and 12.6 go end-of-sale December 31, 2025, with full support ending December 31, 2027. That's not a distant deadline — migrations at enterprise scale take 3–6 months, and the engineers who do this work are already booking out. The time to start your assessment is now.
UCPivot has executed UCCX-to-WxCC migrations hands-on. This guide covers what actually breaks, what takes longer than anyone quotes you, and how to cut over without a Sunday night incident.
Every UCCX-to-WxCC migration we've touched has taken longer than the customer expected. The EOL date is fixed. Your available runway is shrinking. Here's the official timeline:
| UCCX Version | End of Sale | Last Support Renewal | End of Support |
|---|---|---|---|
| 12.5 / 12.6 | Dec 31, 2025 | Dec 31, 2026 | Dec 31, 2027 |
| 12.0 | Apr 23, 2021 | Aug 31, 2023 | Aug 31, 2023 ✗ |
| 11.x | Apr 23, 2021 | Apr 30, 2026 | Apr 30, 2024 ✗ |
| 10.x and older | Already out of support ✗ | ||
If you're on 12.0 or older, support is already gone. You're running a contact center on unpatched software with unresolved CVEs — including two critical unauthenticated RCE vulnerabilities (CVE-2025-20354, CVSS 9.8 and CVE-2025-20358, CVSS 9.4) discovered in late 2025.
This is how we structure every UCCX-to-WxCC engagement. Each phase has a defined output. You don't move to the next phase until the current one is signed off. Skipping phases is how you get Sunday night incidents.
2–4 weeks
Complete inventory of your UCCX environment: scripts, triggers, CSQs, resource groups, skills, agent teams, Finesse desktop layouts, third-party integrations (CRM, WFM, recording), and CUIC reports. Network assessment for cloud voice quality (jitter, packet loss, MOS score). License audit — what you're paying for on-prem vs. what you'll pay for WxCC per-agent subscriptions.
Output: Migration complexity assessment + go/no-go report.
2–4 weeks
Target-state architecture for Webex Contact Center: entry points, flow logic, queue structure, skill profiles, agent desktop layouts, supervisor views. Every UCCX script gets analyzed — decomposed into its logical branches, documented, and mapped to WxCC Flow Designer equivalents. Integration design for CRM (Salesforce, ServiceNow, or custom), workforce management, and recording. PSTN routing strategy — whether you're using existing SIP trunks via CUBE hairpin or porting to Webex PSTN.
Output: Target state architecture doc + phased migration plan.
4–10 weeks
WxCC tenant provisioning in Control Hub. Flow Designer build-out for every call flow identified in Phase 1. Agent/supervisor user provisioning. CRM connector configuration and testing. Recording integration validation (Calabrio, Verint, or WxCC native). CUIC data archival via ODBC export to external SQL (db_cra database using uccxhruser credentials). Parallel environment running alongside UCCX — no production traffic yet.
Output: Fully configured WxCC tenant + UAT test plan.
1–2 weeks (UAT) + cutover window
User acceptance testing with your most complex call flows first. Agent training on Webex Desktop (browser-based, replacing Finesse). Supervisor training on Analyzer reports. Cutover execution: redirect primary DNs to WxCC entry points. Rollback plan is live — if a critical flow breaks, DNs point back to UCCX within minutes. Engineering coverage maintained for 24 hours post-cutover.
Output: Production WxCC handling live calls.
4–8 weeks post-cutover
Stabilization period. Monitor voice quality, RONA rates, IVR abandon rates, queue SLA performance against pre-migration baselines. Tune flow logic based on production behavior — lab behavior and production behavior diverge more than any engineer expects. Decommission UCCX after rollback window closes and metrics confirm stability.
Output: Decommissioned UCCX + optimized WxCC environment.
Every vendor will quote you the best case. Here's what we've seen end-to-end, including the time you lose to scope creep, unexpected integrations, and the three scripts that nobody documented.
| Deployment Size | Agents | Scripts | Realistic Timeline | Primary Risk Factors |
|---|---|---|---|---|
| Small | 1–25 | 1–5 | 6–10 weeks | Custom API integrations, recording vendor |
| Medium | 25–100 | 5–20 | 10–18 weeks | CUIC report parity, AD/SSO, CRM connector |
| Large | 100–300 | 20–50 | 18–28 weeks | Multi-site PSTN, WFM re-integration, custom desktops |
| Enterprise | 300+ | 50+ | 28–40+ weeks | Phased site cutovers, regulatory compliance, legacy Java steps |
These are elapsed calendar weeks from kickoff to UCCX decommission, not engineering hours. Add 20–30% buffer if your scripts contain Java steps, REST API calls with custom authentication, or integrations with on-premises databases.
These are the issues that add weeks to timelines and create post-cutover incidents. Not theoretical — each of these has burned a real deployment.
The UCCX historical reporting schema (db_cra) and the WxCC Analyzer are completely incompatible. There is no native migration path. Your CUIC dashboards — CSQ statistics, agent performance, abandon rates, SLA reports — have to be rebuilt from scratch in Analyzer. Worse: the moment you decommission UCCX, access to db_cra is gone unless you've pre-exported it. Run an ETL job via ODBC (uccxhruser credentials) before cutover and load the data into an external SQL database. Third-party tools like Expo XT can unify legacy UCCX data and live WxCC data in a single view during the transition period.
UCCX scripting is Java-based (CCX Script Editor, .aef files). WxCC uses a visual Flow Designer with HTTP Request nodes, condition branches, and menu steps. You cannot import a UCCX script. You analyze it, document every branch and integration point, and rebuild the logic in Flow Designer. For complex scripts with 15+ branches, REST API calls, and database lookups, this is the single longest task in the migration. Tools like Univonix CC Accelerator can auto-convert basic scripts to flow diagrams and provision them into WxCC — useful for straightforward IVR trees, but scripts with custom Java steps still require manual rebuild.
Whether you're running Calabrio, Verint, NICE, or WxCC's native recording, the integration architecture changes completely. UCCX recording typically used SIPREC or SPAN-based capture against on-premises infrastructure. WxCC recording operates at the cloud level — which is cleaner architecturally but requires fresh configuration, compliance validation, and testing of every recording scenario (transfer, conference, supervisor barge-in, silent monitoring). Don't assume your recording vendor supports WxCC — verify before you get to Phase 3.
WxCC uses Webex Control Hub for identity management, which integrates with Azure AD, Okta, and other IdPs via SAML 2.0. If your UCCX environment used local accounts or a different AD structure, user provisioning needs to be re-architected. Bulk import via Control Hub works well for straightforward AD migrations. Multi-domain AD environments and organizations with complex role hierarchies take longer than expected. Plan at least one dedicated sprint for IAM validation and SSO testing before UAT.
Agents move from Cisco Finesse (desktop app or browser, on-premises) to the Webex Contact Center Desktop (browser-based, cloud). The workflows are different enough that agents who've used Finesse for years will struggle with the new interface without training. Agents who were on Jabber softphones on UCCX can hit RONA issues on WxCC due to audio path latency differences — the Jabber-to-WebRTC transition creates call leg delays that can trigger RONA thresholds. Test your Jabber users specifically during UAT.
UCCX was perpetual licensing — you bought it once, paid for support annually, and owned the seats. WxCC is per-agent subscription (Standard or Premium tier). The math frequently surprises customers: what looks like a wash in Year 1 becomes significantly more expensive in Years 3–5 as agent count grows. Get a full TCO comparison from your Cisco partner before committing. If your agent count fluctuates seasonally, the WxCC subscription model can be an advantage — but only if you're actively managing seat counts.
UCCX voice was on your LAN. WxCC voice goes over the public internet (or Webex Edge Connect for dedicated connections). Your existing QoS policies don't protect cloud-destined voice traffic the same way they protected on-prem SIP. Run a network assessment (jitter <30ms, packet loss <1%, MOS >3.6) before you commit to a cutover date. Sites with poor uplinks or overloaded internet circuits will have quality degradation that post-cutover monitoring will catch too late. Sites with 200+ concurrent agents should consider Webex Edge Connect.
The default outcome if you don't plan for this: you cut over, decommission UCCX, and every historical report, every agent performance record, every abandon rate chart from the past 5 years is inaccessible. Compliance teams and ops managers will not accept this. Here's the playbook.
Connect to the UCCX db_cra database via ODBC using uccxhruser credentials. Export all historical tables: Contact Service Queue statistics, agent session data, IVR activity, abandon records. This is your archive — once UCCX is decommissioned, this data is gone. Set a hard requirement: no UCCX decommission until the export is validated.
Load exported data into an external SQL Server or PostgreSQL instance. This becomes your permanent compliance archive. Size accordingly — a large contact center with 3+ years of data can be several hundred GB when fully exported.
During the parallel-run window (both UCCX and WxCC active), you need visibility across both systems. Third-party tools like Expo XT from Metropolis Corp can query both your archived UCCX data and live WxCC Analyzer API simultaneously — giving ops managers a unified dashboard without switching between systems.
Identify your top 10 operational reports from CUIC. Map each field to its WxCC Analyzer equivalent (the schemas differ but the metrics exist — they're just named differently and calculated slightly differently in some cases). Build these reports before cutover and run them in parallel with CUIC during UAT to validate data consistency.
This is how you cut over without a Sunday night incident. The key principle: UCCX stays fully operational until WxCC is proven, and your fallback is a DNS/PSTN reroute — not a rebuild.
WxCC tenant is fully configured and tested. Zero production traffic is routed to it. UCCX handles 100% of calls. Agents are trained on the new desktop but haven't used it on live calls yet.
Route a single queue or a pilot group of agents (typically 10–15% of your total agent count, your most tech-savvy team) to WxCC. UCCX handles everything else. Monitor for 1–2 weeks. Fix anything that diverges from expected behavior.
Redirect primary DNs to WxCC entry points. Typically done during lowest-traffic hours (Sunday early morning). Engineering team on-call for 24 hours. Rollback = repoint DNs back to UCCX, which is still live and fully configured.
UCCX stays intact (but offline) for 30–60 days as a rollback option. Once metrics confirm WxCC is stable and matching or exceeding pre-migration baselines, UCCX is decommissioned. Not before.
Need an engineer to run your cutover? That's what fractional support is for.
Book a Migration EngineerThe migration ends when UCCX is decommissioned. Post-migration support is a different engagement — you're maintaining, optimizing, and extending a WxCC environment, not running a project.
3–9 months, depending on environment size and complexity. Small deployments (under 25 agents, 5 or fewer scripts) can complete in 6–10 weeks. Medium deployments (25–100 agents) typically take 10–18 weeks. Large deployments (100–300 agents) take 18–28 weeks. Enterprise environments with multiple sites, complex integrations, and regulatory requirements can exceed 40 weeks. The primary driver of timeline variance is script complexity — specifically, the number of custom API integrations and legacy Java steps that need to be rebuilt in WxCC Flow Designer.
Existing recordings don't migrate — they stay on your UCCX recording infrastructure until that system is decommissioned. Your obligation is to ensure recordings are archived per your retention policy before UCCX goes offline. New recordings after cutover are captured by WxCC's recording integration (native or third-party). The gap risk is a brief window during cutover where calls are in-flight across both systems — this is addressed by running both systems in parallel and not decommissioning UCCX recording until all in-flight calls complete.
Not directly — there is no import function. UCCX scripts (.aef files) are Java-based and cannot be consumed by WxCC's Flow Designer. The process is: analyze the existing script, document every branch and integration point, then rebuild the equivalent logic in Flow Designer using HTTP Request nodes, Condition nodes, Menu steps, and Queue Contact nodes. Tools like Univonix CC Accelerator can auto-generate flow diagrams from UCCX scripts and provision basic flows into WxCC with one click. Scripts with custom Java steps, complex variable manipulation, or legacy database lookups still require manual rebuild.
CUIC is an on-premises reporting system tied to UCCX. When you decommission UCCX, CUIC goes with it. WxCC uses the Analyzer for historical and real-time reporting — completely different schema, different data model, different interface. Before cutover, export your CUIC historical data via ODBC to an external SQL database. Rebuild your key operational reports in Analyzer before UAT and validate them in parallel with CUIC during the parallel-run period. This is the most common source of post-migration operational disruption — don't leave it until after cutover.
Several options: (1) Webex Calling PSTN — port your DIDs to Cisco's cloud PSTN, simplest architecture. (2) Existing SIP trunks via CUBE hairpin — your current SIP provider routes calls into your data center, your CUBE forwards them to WxCC entry points in the cloud. Adds a hairpin in the call path but lets you keep existing PSTN contracts. (3) Webex Edge Connect — dedicated connection to Webex for high-volume, latency-sensitive deployments. Most mid-market migrations use the CUBE hairpin option to avoid SIP trunk migration complexity.
WxCC manages users through Webex Control Hub, which syncs with Azure Active Directory, Okta, or other SAML 2.0 IdPs. Bulk user provisioning is available via Control Hub's CSV import. If you're running UCCX with local UCCX-native accounts (not synced to AD), you'll need to plan a full user re-provisioning. If your AD is already synced to Webex (many organizations using Webex Calling or Webex Meetings), user provisioning for WxCC is largely additive — you're assigning contact center licenses to existing Webex users.
UCCX 15 is Cisco's final on-premises UCCX release — it's a short-term bridge, not a long-term platform. Cisco's roadmap is unambiguously cloud-first: WxCC is where investment is going. UCCX 15 buys you more time on-premises but doesn't change the direction. WxCC is cloud-native (runs on AWS), subscription-based, and continuously updated. It supports digital channels (email, chat, SMS), AI-powered features (virtual agents, Webex AI Assistant), and a fundamentally different administration model via Control Hub. UCCX 15 supports voice-first, on-prem-style operations. Choose UCCX 15 only if you have a specific regulatory requirement that prevents cloud deployment.
It depends on how agents connect. If agents use WebRTC (browser-based softphone) for the agent audio leg, a standard WxCC agent license is sufficient — no separate Webex Calling license required. If you want agent-to-agent internal calling via the Webex app (Jabber replacement), Webex Calling licenses are required for that capability. This is a common confusion: WxCC handles inbound/outbound contact center calls on standard agent licenses; Webex Calling licenses are for internal enterprise telephony features. Clarify your agent use case before sizing the subscription.
We offer fractional UC engineering support — an experienced UCCX-to-WxCC engineer on your engagement, without the overhead of a full Cisco Professional Services contract. Engagements are weekly or monthly retainer. We cover assessment, flow rebuild, cutover planning, and post-migration support. Not a generalist consulting firm — we've executed these migrations and we work on the technical details directly. Start with a Flow Audit to understand your migration complexity before committing to a full engagement.
You don't need a full statement of work to get started. Start with a Flow Audit — we'll analyze your existing UCCX scripts, identify migration complexity, and give you a realistic timeline and effort estimate. No vendor pitch, no upsell. Just an engineer who's done this before telling you what you're actually dealing with.
Or explore our WxCC Admin Certification prep if you're building internal expertise.