Cisco Phone and Jabber Migration to Webex Calling

Direct answer: check every phone before choosing a cutover date

Many Cisco 7800 and 8800 Series phones can move from CUCM to Webex Calling, but model, hardware revision, firmware, licensing, and current configuration matter. Some phones need an Enterprise-to-Multiplatform firmware conversion. Cisco 9800 Series phones use PhoneOS and follow a different onboarding process.

Jabber needs a separate transition plan to the Webex App. The phone and client projects meet at the user: identity, number, calling features, voicemail, emergency location, headset, remote access, and call recording must all work after the move.

Test them together. A successful Webex App login does not prove that a user's shared line, desk phone, or [call-recording.com](/) recording path survived the cutover.

Build a phone inventory that includes model and hardware version

Export devices from CUCM and add physical checks where the database is incomplete. Capture:

• device name and owner;
• exact product model;
• hardware version or VID;
• current firmware and protocol;
• primary and shared lines;
• extension mobility use;
• sidecars, headsets, key expansion modules, and accessories;
• location, network, and emergency address; and
• whether the user also relies on Jabber.

“Cisco 8841” is not always enough. Conversion eligibility can depend on the hardware revision, and accessories that worked on CUCM may have different support in Webex Calling.

Check 7800 and 8800 MPP conversion eligibility

Cisco provides an Enterprise-to-Multiplatform firmware migration path for eligible 7800 and 8800 Series phones. Use Cisco's current eligibility and migration guidance rather than assuming every phone with the same front panel can convert.

The project may need the correct CUCM firmware, Control Hub device migration tasks, migration licensing, device access, and a factory reset or reboot sequence. A phone may download several firmware stages before it registers to Webex Calling.

Create three inventory outcomes: confirmed convertible, confirmed replacement, and needs physical validation. Do not let “probably MPP-capable” become the largest group one week before migration.

Treat 9800 Series PhoneOS as a different path

Cisco 9800 Series phones use PhoneOS, so they do not use the old Enterprise-to-MPP conversion process. Moving one from CUCM to Webex Calling still requires proper cloud onboarding and may require a factory reset so it can discover and accept its Webex configuration.

Check current Cisco onboarding instructions for the exact PhoneOS release and deployment method. Confirm Wi-Fi, certificate, proxy, LLDP, VLAN, and power behaviour at the real site. Zero-touch is excellent when all the things it assumes are actually true.

Check the phones that cannot migrate

Older models, unsupported hardware revisions, special wireless devices, conference phones, video endpoints, and third-party SIP devices need an explicit decision. Replace them, keep them temporarily on CUCM, or use a supported alternative.

Do not hide replacement costs inside a general contingency line. Count the devices, accessories, shipping, desk visits, disposal, spares, and user training. Also check whether the replacement changes the Cisco Built-In Bridge recording design.

Analogue and specialist devices belong in the separate Webex Calling ATA, paging, fax, and modem guide.

Choose a single-step or dual-step Jabber transition

Cisco describes two broad approaches. A single-step migration moves calling and messaging from Jabber to the Webex App together. A dual-step migration introduces the Webex App while calling remains on CUCM, then moves calling to Webex Calling later.

A single step can reduce the period of mixed-client confusion. A dual step can spread change and let users learn messaging and meetings before their calling platform moves. It also creates an interim state that needs support, policy, and testing.

Choose by user group. Contact-centre agents, assistants, shared-line users, remote workers, and ordinary single-line users may not need the same sequence.

Prepare identity before installing the Webex App

The Webex identity must match the person being migrated. Align email addresses, UPNs, directory records, Control Hub users, CUCM end users, and calling entitlements before client rollout.

If identity changes at the same moment as device and calling changes, troubleshooting becomes guesswork. Follow the directory synchronization and licence mapping guide first.

Test sign-in, single sign-on, multifactor authentication, password recovery, user status, number assignment, voicemail, and the ability to find colleagues. Include joiners, leavers, contractors, and users with more than one CUCM identity.

Decide what happens to contacts and settings

Cisco provides migration methods for Jabber contacts and some common settings. The available path depends on the existing Jabber deployment and whether Cloud-Connected UC is used.

Inventory local contacts, custom contacts, contact groups, calling preferences, voicemail settings, device selection, and user-specific configuration. Tell users clearly what moves and what must be recreated. Export or preserve anything business-critical before removing Jabber.

Do not claim that every preference follows the user. Test the exact Jabber version, migration method, and Webex App version in the pilot.

Rebuild remote-working assumptions

Jabber may use Mobile and Remote Access through Expressway. The Webex App may use cloud calling services directly. That changes sign-in, media routes, firewall dependencies, troubleshooting tools, and sometimes the recording path.

Test on the corporate network, home broadband, VPN where used, mobile hotspot, and any managed security service. Verify audio both ways, transfers, voicemail, emergency location, corporate directory, and headset controls.

For recording, make calls through each realistic network path and confirm they reach call-recording.com. The user being “off net” should not become a mysterious gap discovered during an investigation.

Test shared lines, queues, and user behaviour

Users experience features through phones and clients, not through a migration spreadsheet. Test line selection, incoming-call presentation, call waiting, hold and resume, transfer, conference, call pull, voicemail indicators, hunt-group sign-in, queue status, caller identification, and after-hours routing.

Webex Calling equivalents do not always look or behave exactly like CUCM. Use the feature parity, recording, queues, and shared-lines guide to migrate the complete user workflow.

Record calls from the primary line, shared lines, queue calls, transfers, conferences, and forwarded calls. Then use the call-recording.com unified dashboard to confirm migrated and non-migrated users have the expected playback, parties, direction, and timestamps.

Design the pilot around variation, not volunteers

A pilot made entirely of IT staff with new laptops and single lines proves very little. Include:

• a 7800 or 8800 phone being converted;
• a 9800 PhoneOS device if used;
• a replacement phone;
• a Jabber-only remote worker;
• a user with a desk phone and Webex App;
• shared-line, assistant, hunt, and queue users;
• different sites and PSTN models; and
• users whose calls must be recorded.

Keep the pilot long enough to cover real working patterns. Monday morning, after-hours routing, remote work, and a carrier fault are more educational than ten tidy calls in a lab.

Write the reset, rollback, and support runbooks

Document how to recover a phone stuck during conversion, factory-reset each supported model, restore network settings, obtain activation information, reassign a device, and return a user to the previous service if the cutover fails.

Give the support desk simple checks: registration, IP address, firmware, assigned user, calling licence, location, emergency address, service status, and known incident. Include screenshots only where they match the current interface.

For recorded users, the runbook should also say how to place a test call, find it in [call-recording.com](/), and escalate missing audio or metadata. “Ask compliance tomorrow” is not a cutover-night procedure.

Move in waves and measure each one

Group users by dependencies: shared lines, hunt groups, queues, assistants, sites, PSTN routes, and recording policies. Move the group together when splitting it would break the workflow.

For each wave, measure successful phone onboarding, Webex App sign-in, call completion, support cases, rollback count, emergency-calling validation, and recording completeness. Do not start the next wave merely because the calendar says Tuesday.

Keep CUCM and Webex recordings available through one [call-recording.com](/) organization during the transition. A unified call and message playback dashboard reduces the operational split while users and devices move at different speeds.

Continue the CUCM to Webex migration series

Return to the complete CUCM to Webex Calling migration guide, review Webex Calling PSTN choices, or start the feature parity and recording workstream.