In my experience migrating contact centers off legacy on-prem CUCM infrastructure, the technical surprises don't come from the architecture — they come from the details. Dial plan translation is solvable. SIP trunk cutover is routine. What catches projects off guard are the edge features: things that CUCM has been doing quietly for years that nobody thought to document as requirements until Webex Calling can't do them.
The six features below are the most common ones I see surface late in a migration. None of them are showstoppers on their own — but all of them require an explicit decision before you can close out the design phase.
Forced Authorization Codes (FAC)
⚠ No direct equivalent in Webex CallingWhat it does in CUCM
Forced Authorization Codes (FAC) are CUCM's mechanism for restricting outbound call routing by requiring users to enter a numeric code before calls to certain route patterns are allowed. Typically used for long-distance, international, or premium-rate calls — the system validates the code, logs who made the call, and applies the associated calling privilege level. It's lightweight call accounting with an access-control layer baked in.
Why it doesn't translate
Webex Calling's calling permissions system is user-based and group-based, not code-based. You can restrict which call types a user or location can make — international, premium, operator-assisted — but there's no concept of a user "unlocking" a call by entering a code at dial time. The authorization happens at provisioning, not at the moment of the call.
What to do about it
For most customers, the FAC use case was really a soft control that nobody enforced strictly anyway. The first question to ask: does anyone actually audit these codes, and have any calls been blocked by them in the last 12 months? If the answer is no, you can replace FAC with proper user-level calling permissions in Webex and close the gap without drama.
For environments where FAC is genuinely load-bearing — typically regulated industries where call logging is a compliance requirement — you'll need a third-party call accounting solution that integrates with Webex Calling's CDR feed. Several exist. Budget the integration work separately from the migration itself.
How Migration Advisor handles it
UCPivot's Migration Advisor flags every route pattern with FAC assigned and generates a translation note identifying whether the restriction can be handled by Webex calling permissions or requires a supplemental call accounting integration.
MLPP (Multilevel Precedence and Preemption)
⚠ No equivalent — federal/government workloads onlyWhat it does in CUCM
Multilevel Precedence and Preemption is CUCM's implementation of a DoD-originated signaling standard that allows high-priority calls to preempt lower-priority ones on congested trunks. A call marked Flash Override can seize a circuit that a Routine call is using. The levels — Routine, Priority, Immediate, Flash, Flash Override — map directly to military communication precedence standards. MLPP is a contractual requirement for certain federal and defense installations.
Why it doesn't translate
Webex Calling has no MLPP support, full stop. This isn't an architectural gap that Cisco is likely to close in the near term — MLPP is a niche requirement that affects a small fraction of deployments, requires specialized trunk signaling, and Webex's cloud architecture doesn't map cleanly to preemption semantics. If your customer has MLPP in their CUCM configuration, you need to know whether it's there because they actually use it or because it was enabled during initial deployment and never touched since.
What to do about it
Check whether MLPP is actively configured and actually used. In many cases, MLPP was enabled as a "might need this" configuration item and the customer has never placed an MLPP-precedence call. If it's unused, document it as a known gap, get written customer sign-off that it won't be required in the Webex environment, and move on.
If MLPP is a genuine operational requirement — a DoD contractor, a military installation, a federal agency with a JITC-tested compliance mandate — Webex Calling is the wrong target platform. The honest conversation to have with that customer is whether Webex Calling is appropriate for this workload at all, or whether they need to retain a hybrid CUCM cluster for MLPP-dependent endpoints while migrating everything else.
How Migration Advisor handles it
Migration Advisor identifies MLPP domain and policy configuration in the exported BAT data and flags it as a high-confidence non-translatable item, with a recommendation for customer sign-off documentation.
SCCP Endpoints
⚠ Protocol not supported — physical device migration requiredWhat it does in CUCM
Skinny Client Control Protocol (SCCP) is Cisco's proprietary signaling protocol used by older Cisco IP phones and some analog telephone adapters. CUCM supports both SCCP and SIP device registration, but a significant portion of production CUCM environments still have SCCP devices on the network — particularly older 79xx-series phones, some 89xx models, and analog gateways using SCCP for FXS port signaling.
Why it doesn't translate
Webex Calling is SIP-only. SCCP devices cannot register to Webex Calling under any configuration. There is no SCCP gateway, no adapter, no workaround that allows a SCCP device to participate in a Webex Calling environment as a registered endpoint.
What to do about it
The migration path depends on what kind of SCCP device it is. For SCCP IP phones: if the device is a model that supports SIP firmware (many Cisco 79xx phones do), you can reflash it to SIP and register it to Webex Calling as a third-party SIP device. Check the firmware availability for the specific model — not all SCCP phones have SIP firmware available.
For phones without SIP firmware and for SCCP analog gateways: the options are hardware replacement (new Cisco MPP phones register natively to Webex Calling) or routing analog connections through a Webex-compatible SIP trunk via a local gateway. Either way, this is physical hardware work that needs to be scoped and budgeted separately. Don't let it show up as a surprise during cutover.
How Migration Advisor handles it
Migration Advisor identifies all SCCP device pool assignments in the exported configuration and surfaces the endpoint count and model mix. The assessment output includes a device-by-device translation status: SIP-flashable, hardware replacement required, or analog gateway path.
SRST (Survivable Remote Site Telephony)
⚠ Architectural gap — Webex Local Gateway is the closest analog, but it works differentlyWhat it does in CUCM
SRST allows a Cisco IOS router at a branch site to act as a fallback call manager if WAN connectivity to CUCM is lost. Phones at the site detect the loss of CUCM registration and automatically re-register to the SRST router, which provides basic dial tone, internal extension dialing, and PSTN access. The intent is that branch users can keep making calls even when the link to headquarters is down.
Why it doesn't translate
Webex Calling is cloud-dependent by design. There is no on-premise fallback registration target for Webex Calling devices the way SRST provides for CUCM. If the customer's internet connection at a branch site goes down, Webex Calling phones at that site go dark. The architecture assumes internet availability as a baseline.
Webex Local Gateway (the Cisco IOS-XE router that provides PSTN connectivity for Webex Calling) does not provide SRST-equivalent survivability for Webex-registered devices.
What to do about it
This is a conversation that needs to happen at the customer level before migration design, not during cutover. The right questions: How often does WAN connectivity actually fail at remote sites? What's the business impact of 30 minutes of phone outage at a branch? Is the current SRST actually tested, or has it been sitting configured but unvalidated for years?
For most commercial deployments, high-quality internet connectivity (with 4G/LTE backup circuits) is a more reliable answer than SRST — you're removing a dependency on WAN reliability and replacing it with internet redundancy. For sites where WAN survivability is a hard requirement, a hybrid architecture with retained CUCM at those sites (while migrating everything else to Webex) is the honest recommendation.
How Migration Advisor handles it
Migration Advisor identifies all SRST references in device pool and phone configurations, counts the affected sites and endpoint population, and includes a survivability gap notice in the generated runbook's Executive Summary section.
Cisco Emergency Responder (CER)
⚠ Admin model is completely different — requires re-implementationWhat it does in CUCM
Cisco Emergency Responder integrates with CUCM to provide Enhanced 911 (E911) services — specifically, the ability to route 911 calls based on the physical location of the calling device and to notify on-site security personnel when a 911 call is placed. CER tracks endpoint location by switch port or IP subnet, maintains Emergency Response Locations (ERLs), and routes emergency calls to the appropriate Public Safety Answering Point (PSAP) for that location.
Why it doesn't translate
Webex Calling does not use CER. The cloud platform has its own E911 mechanism — integration with third-party E911 providers, most commonly RedSky (now part of Bandwidth) or Nomadic E911. These services provide similar functional capabilities (location-based routing, security desk notification) but are administered entirely differently. You're not migrating CER configuration — you're replacing CER with a new system and rebuilding the location database.
What to do about it
Treat E911 compliance as its own work stream in the migration project, not a checkbox in the Webex Calling configuration. Webex Calling's native E911 support (Redsky/Nomadic integration) requires:
First, an audit of all physical locations and their ERLs — this data exists in CER but needs to be reformatted for the new provider. Second, decisions about which Webex Calling locations map to which PSAPs. Third, network location discovery configuration (Webex Calling supports Wi-Fi BSSID, network switch/port, and IP subnet for location detection). Fourth, testing — E911 is not something you want to discover is broken during an actual emergency.
Budget this as a separate sub-project with its own timeline and testing phase. E911 compliance is a legal requirement in most jurisdictions. It's not optional to defer.
How Migration Advisor handles it
Migration Advisor extracts all ERL data and emergency routing configurations from the BAT export and generates a structured ERL inventory as part of the runbook — giving you a starting point for the new E911 provider configuration rather than starting from scratch.
Cisco Unified Presence (CUP / IM&P)
⚠ Presence federation and IM history don't migrate cleanlyWhat it does in CUCM
Cisco Unified Presence (CUP), later rebranded as IM and Presence Service (IM&P), is the on-premise presence and instant messaging platform that integrates with CUCM. It provides phone state presence (on a call, idle, DND), IM capabilities, and — critically for many enterprise deployments — presence federation with external XMPP domains and Microsoft environments via the Cisco Presence Federation gateway.
Why it doesn't translate
Webex Messaging is the cloud messaging and presence replacement, and it works well for most use cases. The problem is on the edges: IM history does not migrate — there's no tool to lift chat logs from IM&P and import them into Webex. Presence federation with on-premise systems is handled differently, and if a customer has active XMPP federation with external organizations (common in healthcare, government contracting, and multi-org enterprise environments), that federation relationship needs to be rebuilt or replaced.
The Jabber-to-Webex App transition also often surfaces unexpected user behavior dependencies — contacts lists, custom status strings, persistent chat rooms — that were never formally documented as requirements because everyone just assumed they'd move.
What to do about it
IM history loss is usually the thorniest issue. For most customers, the practical answer is a cutover date with a clear communication that chat history prior to migration date is archived (retain the IM&P data for 90 days post-cutover for access if needed) but not carried forward. Users adjust faster than you expect.
For presence federation: audit active federation agreements before the migration. If a customer federates presence with external healthcare organizations via XMPP, that's a significant dependency that needs a migration plan before you can turn off IM&P. Webex supports federation via Webex Calling and through certain partner integrations — but the configuration process is nothing like the CUP federation setup.
How Migration Advisor handles it
Migration Advisor identifies IM&P user assignments and presence subscription data in the exported configuration and flags active federation configurations as high-priority items requiring pre-migration resolution.
The Common Thread
What these six features share: they're all things that CUCM has been doing in the background for years without anyone thinking of them as "features." They were just how the phone system worked. The reason migrations get surprised by them is that requirements-gathering sessions focus on what users do, not on what the infrastructure has been silently handling.
The right time to surface these gaps is during pre-sales discovery, not during cutover planning. A clean migration design has explicit decisions documented for each of these items — whether that's "we're replacing this with X," "the customer has signed off that they don't need this," or "we're keeping hybrid for this workload." Ambiguity on any of them is technical debt that will surface at the worst possible moment.
The Migration Advisor tool automates the discovery phase — it reads your BAT export and produces a structured assessment of which of these gaps exist in your specific environment, with confidence levels and a proposed translation approach for each one. It doesn't replace engineering judgment, but it does replace the hours of manual config review that usually happen before engineering judgment can even be applied.
Automate the discovery phase
Planning a CUCM-to-Webex migration? UCPivot's Migration Advisor reads your BAT export and produces a structured translation assessment — identifying gaps like the ones above, with confidence scores and proposed configurations. Upload a BAT export and get results in minutes.
Try Migration Advisor →