The first step in transitioning to is to ensure reliable and secure Internet connectivity between the on-premises network and the cloud.

Since most organizations connect to the internet through one or more firewalls or security devices, it is essential to validate that the required traffic flows are supported.

Network and security administrators must understand these flows in terms of:

• Direction (inbound vs outbound)

• Protocols (Example - SIP TLS, SRTP, HTTPS)

• IP address ranges used by services

• Port numbers that must be opened or allowed.

This ensures that corporate firewalls, NAT devices, and other network infrastructure are properly configured to accommodate traffic while maintaining enterprise security policies.

For information on the required flows including IP address, ports, and protocols, see Port reference information for Webex Calling. Use this information to configure the firewall, proxies, and other network infrastructure in the existing deployment to enable network flows.

Decentralized internet breakout from each branch or site is the recommended approach for cloud collaboration services such as . By allowing traffic to exit locally, this model:

• Reduces round-trip delay and jitter, improving overall call quality

• Scales efficiently as more users and sites transition to

• Works seamlessly with SD-WAN, which can dynamically route sessions to the nearest cloud entry point for optimal performance

• Allows to track user location based on their public IP address which helps with media path analysis and troubleshooting.

In addition, organizations must ensure adequate internet bandwidth at each site. Bandwidth should be sized based on the expected number of concurrent calls, the selected codec (e.g., Opus or G.711), plus overhead for signaling, retransmissions, and growth. This aligns with the Prepare phase of the PPDIO lifecycle and establishes a solid foundation for migration.

The initial setup subsection within the implement phase of deploying is foundational to establishing a well-structured and manageable cloud calling environment. This stage encompasses critical tasks such as setting up the organization, procuring and assigning licenses, and verifying and claiming your company's domains to ensure proper user management and security. Additionally, it includes provisioning license templates to automate user license assignments, configuring Single Sign-On (SSO) to streamline user authentication and enhance security, and adjusting service and client settings to align with organizational policies and user needs. Completing these initial setup activities ensures that the environment is properly configured for scalability, security, and seamless user experience, setting the stage for subsequent deployment and operational phases.

During the implement phase, executing a pilot migration represents a critical milestone in validating the transition from to . This pilot involves provisioning a representative subset of users across one or more locations onto the platform, ensuring that the selected population reflects diverse use cases and organizational roles. In parallel with user migration, essential collaboration services including voicemail, auto attendants, call queues, and hunt groups must be transitioned to their equivalents to maintain business continuity and service functionality.

The pilot migration should leverage the same combination of Cisco-provided tools and third-party migration utilities that are planned for the broader organizational deployment, ensuring that the processes, automation workflows, and integration points are thoroughly validated under representative conditions.

The primary objectives of this pilot deployment are two fold: first, to validate and refine the end-to-end transition processes including user provisioning workflows, data migration procedures, and endpoint configurations; and second, to comprehensively verify the functionality of migrated services under real-world operational conditions.

This phased approach allows the project team to identify and remediate any technical or procedural issues in a controlled environment, gather user feedback on the new platform experience, assess the effectiveness of selected migration tools, and establish confidence in the migration methodology before proceeding with broader organizational deployment.

The insights gained during this pilot phase are instrumental in optimizing subsequent migration waves and ensuring a smooth, risk-mitigated transition for the entire enterprise.

To procure PSTN services for , first select a PSTN connectivity option in the .

If an organization plans to maintain hybrid dual call control ( phase 1 in figure Phased Calling Transition: Hybrid and Cloud) either temporarily or indefinitely, they will need to deploy one or more Local Gateways for on-premises PSTN to allow calling between and endpoints.

If a full transition ( phase 2) to the cloud is the end goal including PSTN, then either a Cisco Calling Plan or a Cloud Connect for option will be required for PSTN.

Work with your chosen provider to order and port phone numbers before configuring them in . Ordering phone numbers or initiating port orders is only required/possible for on-premises PSTN and Cloud Connect for . For Cisco Calling Plans, ordering and porting is initiated from within Control Hub as soon as the location is created, and in countries where Cisco Calling Plan is available. For more information on Cisco Calling plans, see Getting started with the Cisco plans.

As part of the PSTN implementation, ensure that your provider has enabled both inbound and outbound PSTN services for your location. Additionally, perform test calls to verify that calls are being routed correctly through your chosen PSTN connection.

Before adding users and devices to , you must provision calling locations. For each location, a valid street address must be entered. In the US and Canada, this address is validated and used by the platform to send PIDF-LO location information for emergency calls.

When configuring locations that use on-premises PSTN, you need to set up the local gateways accordingly. In , a trunk and a route group must be created for each local gateway, and the route group is then assigned as the PSTN choice for the location. Cisco strongly recommends always selecting a route group as the PSTN choice, as this approach allows you to easily add additional trunks in the future, supporting both scalability and redundancy. Cisco also recommends enabling dual-identity and P-Charge-Info support on every PSTN trunk, since this simplifies the identification of the billable party for outgoing direct or diverted calls. If your PSTN provider uses a different header for billing, you can copy the information from the P-Charge-Info header on the local gateway to the required billing header.

For locations that use Cloud Connect for or the Cisco Calling Plan as their PSTN option, simply select the respective PSTN choice for the location during setup. If the location uses either Cloud Connect for or on-premises PSTN, you will need to add the phone numbers that were ordered in the previous step. Numbers can be added as inactive if you do not want them included in call routing right away; you can activate these numbers later when they are assigned to users or features.

It is important to always set the main number for each location. The main number can be assigned to either a user or a feature, such as an auto-attendant. To enable voicemail at the location, make sure to set the voicemail pilot number, also known as the voice portal number.

Additional settings for calling locations include configuring emergency calling details such as the emergency callback number, notification options, and enhanced emergency calling features. You should also review and adjust recording settings, language preferences, and device configurations as required for each location. If your organization uses abbreviated inter-site on-net dialing with enterprise significant numbers, remember to configure a unique site code for the location in the internal dialing settings. Finally, if external dialing requires an outbound dial digit, be sure to set this in the external dialing settings. When an outbound dial digit is configured, Cisco recommends enabling outbound dial digit enforcement to ensure consistency.

To integrate with on-premises call control, it is necessary to configure trunks, route groups, enterprise dial plans, and both location and global settings. Begin by setting up the trunks and local gateways intended for interconnection with the on-premises call control system; this step is only required if dedicated trunks are necessary. If existing trunks and route groups are sufficient for your deployment, they can be reused for the on-premises interconnect without additional configuration.

Once the trunks and route groups are established, proceed to create the enterprise dial plans and assign the appropriate route group as the destination for each dial plan. When integration involves multiple on-premises call control systems connected through different trunks, multiple dial plans will be required. It is important to ensure that these dial plans contain only the patterns necessary for routing calls to on-premises destinations.

If your deployment requires support for unknown extension routing, this feature should be enabled at the location level. Additionally, when unknown extension routing is activated, you must specify the maximum unknown extension length within the Call Routing between and premises section of the calling services settings in . This ensures seamless call routing and proper handling of extension-based dialing scenarios in your integrated environment.

When you migrate users from to you may not be able to move all users at the same time. This can be due to multiple reasons, including but not limited to the number of sites or users, how long it takes to transition a site and/or group of users at one time, limited IT or site resource to support the change window, duration of change window, complexity of change, etc.

When you migrate users in phases it is critical to identify which users need to migrate together in the same batch. The primary goal is to migrate users together who have dependencies with each other for their calling services and features. You want to ensure all their calling features (Example - Call Queues) are fully functional on as they were before the transition on .

Even if you implement calling interworking between and with Local Gateways, you cannot split shared services or features across this connection. Therefore, you need to identify the dependencies between users by looking at features like:

• Monitoring other users using BLFs

• In the same hunt pilot, call queue, etc

• Shared lines

• Using call pick-up

• Using the same call-park numbers

• Intercom

• Executive/Admin.

An example would be a user who is part of a Hunt Group that is being transitioned to . This user will transition to with the Hunt Group and with all other members of the Hunt Group. Therefore, post-transition the Hunt Group and its members can successfully answer calls on the new platform.

This becomes more challenging when users are connected to different groups of users for different calling services and features. This will require transitioning more than one group of users and one calling service to at the same time.

Use the output from the Migration Insights tool or third party tool that you used in the prepare phase to determine which users and features should be grouped together. This output should have been used to develop your migration plan and will give you insights into how you will group users and features that need to transition together.

The key steps when transitioning a batch of users are:

• Identifying users to migrate together

• Verify all users are in

• Verify all TNs for the users exist in

• Verify correct phone number format in directory

• Make sure that licensing and settings template for the user groups are set up correctly

• Verifying or configuring all calling services and features for the group of users (before or during the transition as appropriate)

• In the corporate directory add users to group of calling enabled users

• Leverage Tools - user and feature migration tools and/or third party tools

• Disable/Delete user/device directory number and calling features/services on after the transition.

After migration a group of users, test a subset of the users to validate all their calling features and services are working correctly. If calling features such as Call Queue, Hunt Groups, etc. are transitioned with the group of users, then test these calling services for proper functionality.

In , a workspace refers to a shared location (like a conference room, huddle space, or hot desk) that can be assigned devices, extensions, and users. Unlike traditional Unifed CM phones, workspaces are:

• Location-centric: tied to physical spaces.

• Device-flexible: can have one or more devices (Desk Phones, Boards, etc.).

Once workspaces have been identified as part of the transition to , they can be added in under Devices. Each workspace needs a device assignment, and if they are already in Unified CM, they need to be reset or re-provisioned for . features such as voicemail, call forwarding, and call pickup can be enabled or disabled, and policies can be applied for video calls, call park, and mobility as required. Test each workspace by making internal and external calls, testing video, conferencing, and mobility features. Lastly, let users know of any applicable processes for workspace devices and bookings.

For more information on workspaces in , see Workspaces.

Phones that are currently registered to will need to be migrated to as part of the cloud transition. To make the migration as simple as possible with minimal chance for failure, Cisco recommends migrating physical sites or departments at the same time. However, you may be required to migrate users in batches due to feature dependencies. See the section Migrate users in batches for more details.

Any supported phones that you need to transition from will need to be configured on as a user or workspace and the physical phone will need to be reconfigured to register with . In addition, the 7800 and 8800 series phones need their firmware upgraded from Enterprise firmware to Multiplatform Phone (MPP) firmware. This process includes loading transitional firmware before loading the MPP firmware required for registration. It also requires the appropriate migration license. Cisco has improved this process over the past few years to make it easier for you to upgrade your Enterprise firmware phones to MPP firmware. For more information on the steps to complete the firmware upgrade, see Convert Cisco 7800 and 8800 series IP phones between Enterprise and MPP Firmware.

In addition to the steps outlined in this article, has a built-in tool, Migrate your phone to Webex Calling, that you can use to help migrate your 7800 and 8800 phones from Enterprise to MPP firmware. This tool also allows you to add the phones to and assign them to the appropriate users or workspaces. For more information on tool usage, see Migrate your phone.

For any 9800 series phones registered with the above firmware migration requirement does not apply. These phones run PhoneOS, which is supported by both and . To transition these phones to you will need to add them to Webex Calling, assign them to a user or workspace and then factory reset the phones. PhoneOS boot sequence for registration figure below shows the PhoneOS boot sequence and how the phone will register to once it has been added to , even if the phone is still provisioned on and/or DHCP Options (Example - 150) are in use.

supports factory resetting PhoneOS devices to allow for Zero-Touch onboarding to . admins can remotely factory reset the 9800 and 8875 phones through the CUCM Administration pages, which eliminates the need for physical access to the phones to onboard the phones to . This feature is supported with the Device Packs from September 9, 2025:

• CUCM v15 - Unified Communications Manager Version 15

• CUCM v14 - Unified Communications Manager Version 14.

For more information on registration process for the 9800 series, see Registration process.

In addition to the Cisco IP phones, provisioning of other devices such as analog telephone adapters (ATAs), wireless (Wifi, DECT) phones, video devices, voice gateways, and 3^rd party devices and phones may be required. Many of these devices do not have a firmware upgrade path like the IP phones to transition them from enterprise firmware to cloud firmware. Therefore, you will provision each of these devices in Control Hub. Some of these cannot be transitioned to and the equivalent model will need to replace it (e.g. ATA 191/192) and others will require manual reconfiguration and/or software changes.

• Voice gateways - To migrate your local gateway, see Migrate local gateway.

  For more information to configure your voice gateway VG400, VG410, or VG420 in Control Hub, see Local gateway

• Analog telephone adapter (ATA) - To get started with your Cisco ATA 191 and 192, see Cisco ATA.

• Wifi wireless phone - To integrate wireless phone 840 and 860, see Integrate Webex wireless phone.

• DECT wireless phones - To get started with your new Cisco IP DECT 6800 series, see Cisco IP DECT.

  To build and manage digital DECT network in Control Hub, see Manage DECT network

  For more information on Cisco IP DECT 6800, see Deployment guide

• 3^rd party devices and phones - Work with 3^rd party vendors on device/phone requirements and the process to migrate or replace them to support .

Any calling features that are required in need to be provisioned before or during the transition. As discussed during the Migrate users in batches section, the calling features need to be configured and transitioned when the users who are using them are transitioned.

For details on how to configure each of the features, see the corresponding configuration help articles.

• Auto attendants - To manage auto attendants, see Auto attendants

• Call park - To manage call park, see Call park

• Call pickup - To configure call pickup group, see Call pickup

• Call queues - To configure Call Queue, see Call queue

• Hunt groups - To Manage hunt groups, see Manage hunt group

• Operating modes - To call routing based on operating modes, see Call routing based on operational modes

• Paging groups - To configure a paging group, see Configure a paging group

• Recordings - To manage call recording for , see Manage recordings

• Single number reach - To configure single number reach (office anywhere), see Configure single number

• Voicemail group - To manage a shared voicemail and inbound fax box for , see Manage voicemail.

Acceptance testing ensures that the migrated environment meets the functional requirements, operates as expected, and delivers a seamless user experience across all communication workflows. This validation process is multifaceted, covering everything from user provisioning and number assignments to the operational performance of advanced calling features.

This section provides examples and highlights key aspects to consider during acceptance testing; however, it is not intended to serve as an exhaustive or comprehensive checklist.

User provisioning and number assignment

A foundational aspect of acceptance testing involves verifying that all users are provisioned accurately and completely within . This requires a thorough comparison between the source () directory and the newly established user base to ensure that every user account, along with associated attributes such as extension numbers, and direct inward dial (DID) assignments has been correctly migrated. Completeness of provisioning is critical not only for day-one operability but also for ongoing administration and support.

Number assignment validation includes confirming that each user is assigned the correct extension and external number, and that these numbers route correctly in both internal (on-net) and external (PSTN) call flows. It is essential to check for any overlaps, missing assignments, or misconfigurations that could lead to call routing errors or service interruptions.

PSTN Call flows and caller ID presentation

A robust acceptance testing procedure must encompass end-to-end validation of PSTN call flows. This includes both inbound and outbound call scenarios. For incoming PSTN calls, the testing team should confirm that calls are delivered to the intended endpoints, whether these are individual users, call queues, hunt groups, or auto attendants. Outgoing PSTN calls must be placed successfully, with particular attention given to the correct delivery and presentation of caller ID information. This involves ensuring that the correct caller name and number are displayed to external recipients, in accordance with organizational policies and regulatory requirements.

Testing should also address failover scenarios, such as the handling of unreachable endpoints or network disruptions. This helps to confirm that fallback mechanisms and alternate routing are functioning properly, maintaining service continuity and reliability.

On-net call flows

Internal, or on-net, call flows form the backbone of enterprise communication. Acceptance testing in this area verifies that calls between users within the organization are routed correctly, with features such as call transfer, hold, forwarding, and conferencing operating as intended. The integrity of dial plans, extension-to-extension connectivity, and the support for organizational call policies must all be confirmed.

User Call handling and feature validation

An important aspect of acceptance testing involves validating how users handle calls using the and supported desk phones. This process focuses on confirming that day-to-day calling workflows are intuitive and reliable, and that users have seamless access to the core features necessary for their roles. Testing should assess the ease with which users can place and receive calls, manage hold and resume functions, and perform both blind and consultative transfers. It is also essential to verify that call forwarding, conferencing, and other advanced capabilities, such as parking and retrieving calls or activating do not disturb, are readily available and operate smoothly.

The experience should be evaluated for clarity and responsiveness, considering how users interact with call history, voicemail, and integrated directories. Additional attention should be paid to the ability to move active calls between devices and to use in-call controls effectively within the application or on physical phones. The ultimate goal is to ensure that the end-user experience is consistent, efficient, and fully supports the organization's communication needs following the migration.

Call Queues: Agent and supervisor experience

Call queues are frequently used for handling high-volume inbound call scenarios. Acceptance testing here focuses on several dimensions. First, it should be verified that calls are distributed to agents according to the configured queue logic, such as round robin, longest idle, or simultaneous ring. The presentation of queued calls on agent desktops must be examined for clarity and ease of use, ensuring agents can efficiently accept, hold, and transfer calls.

For supervisors, the desktop experience should be evaluated for features such as real-time monitoring, call barging, and analytics or insights into queue performance. This includes but is not limited to validating dashboards and reporting tools that provide actionable data on call distribution, agent activity, and queue metrics.

Hunt Groups: Call distribution

Hunt groups are a key mechanism for distributing calls to predefined sets of users. Acceptance testing needs to confirm that calls are routed to group members based on the configured hunting algorithm, and that overflow, forwarding, and no-answer scenarios are handled according to design. Ensuring that group membership and call routing behaviors match those previously established in is essential for operational consistency and user satisfaction.

Auto Attendants: Announcements and menu operations

Auto attendants represent the front line of automated call handling. Testing must cover the playback of announcements, the accuracy of recorded greetings, and the correct operation of menu trees. Menu selections should reliably route callers to the appropriate departments, individuals, or external numbers. Testing should also include invalid or timeout scenarios to confirm that callers receive clear guidance or are redirected as intended.

Voicemail operation

Finally, voicemail functionality is critical to the user experience. Acceptance tests should verify that voicemail boxes are correctly assigned and accessible, both from within the organization and remotely. The ability to record, retrieve, and manage messages must be confirmed, along with notification delivery.