Cisco Collaboration System Migration

Revised: January 15, 2015; OL-30952-03

This chapter provides recommendations for administrators to manage migrations of existing or previous Unified Communications solution versions (6.1.5, 7.1.5, 8. x, and 9. x) to the latest Cisco Collaboration System Release 10. x.

Note Cisco 7800 Series Media Convergence Servers (MCS) are no longer supported in Cisco Collaboration System Release 10.x.

For more information on minimum hardware and software requirements for Open Virtualization Archive (OVA) templates, VMware, ESXi Hypervisor, and Unified Communications applications, refer to the following documentation:

  • Unified Communications VMware Requirements

http://docwiki.cisco.com/wiki/Unified_Communications_VMware_Requirements

  • VMware Compatibility Guide

http://www.vmware.com/resources/compatibility

  • Hardware and Software Interoperability for UCSM Managed Servers

http://www.cisco.com/en/US/products/ps10477/prod_technical_reference_list.html

For Cisco Collaboration System Release 10 x, most Cisco Collaboration applications require virtualization deployments and may not be installed directly on a server without a hypervisor. VMware vSphere ESXi is currently the only supported hypervisor, and it is mandatory for all virtualized deployments of Cisco Collaboration Systems. Cisco Collaboration System Release 10.x does not support VMware vSphere ESX or any other VMware server virtualization products besides ESXi.

This chapter discusses the following types of migrations:

  • Cisco 7800 Series MCS servers to Cisco Unified Communications Manager (Unified CM) on Cisco Unified Computing System (UCS) servers
  • Cisco Video Communication Server (VCS) endpoint registration to Unified CM registration
  • H.323 gateways and trunks to SIP gateways and trunks
  • SCCP endpoints to SIP endpoints
  • Numeric dialing to URI dialing
  • Pre-9. x license migration, from device-based licenses to user-based licensing utilizing Cisco Prime License Manager

In order to ensure a successful migration, Cisco recommends using the following resources to validate that all requirements have been met prior to migration:

  • Cisco Unified Communications Compatibility Tool

http://tools.Cisco.com/ITDIT/vtgsca/jsp/index.jsp

  • Cisco Unified Communications Manager Software Compatibility Matrix

http://www.cisco.com/en/US/products/sw/voicesw/ps556/products_device_support_tables_list.html

The validation will ensure a successful migration using supported upgrade paths. For example, some early application software versions might require a multi-step upgrade in order to migrate successfully. Similarly, server hardware along with software compatibility might require a combination of multi-step hardware and software upgrades.

For details on Cisco Collaboration System products, refer to the documentation available at

http://www.cisco.com/en/US/products/sw/voicesw/ps556/prod_maintenance_guides_list.html

For a list of all supported system hardware, refer to the Unified Computing Products documentation available at

http://www.cisco.com/en/US/products/ps10265/products.html

What’s New in This Chapter

Table 28-1 lists the topics that are new in this chapter or that have changed significantly from previous releases of this document.

Table 28-1 New or Changed Information Since the Previous Release of This Document

New or Revised Topic
Described in:
Revision Date

Migration of IM and Presence Service

On-Premises Cisco IM and Presence Service Migration

January 15, 2015

Coexistence or Migration of Solutions

This is an important choice that must be made. Coexistence typically means two or more systems coexisting for an extended period of time (for example anything greater than six months.) Under this scenario feature transparency, whether for PBX, voicemail, or other features, becomes a more significant consideration. Investment and/or upgrades to existing systems might be necessary in order to deliver the level of feature transparency required. Migration typically occurs over a shorter period of time (for example, less than six months). Under this scenario users are more likely to tolerate a subset of existing features, knowing that the migration will be complete in a "short" time. Often existing system capabilities are sufficient for this short time, therefore migration is often less costly when compared to coexistence.

Migration Prerequisites

Before implementing any collaboration migration steps, all administrators should ensure their IP infrastructure is "collaboration ready," including redundancy, high availability, power consumption, Quality of Service (QoS), in-line power, ethernet ports, and so forth. For further details, refer to the chapter on Network Infrastructure.

If this is a first deployment of Cisco Unified Communications on Cisco Unified Computing System (UCS), follow the guidance provided in the Cisco UCS Site Preparation Guide, available at

http://www.cisco.com/en/US/docs/unified_computing/ucs/hw/site-prep-guide/ucs_site_prep.html

Business needs of the users play an important role in identifying key system requirements to ensure that the features and functionality are reserved or translated during migration to provide equivalent behavior. A list of features and the versions of various devices and software helps in understanding what is supported. Typically some kind of survey of the site and users should be performed to ensure that all requirements (for example, fax/modems, environmental control systems, and so forth) are appropriately identified and accounted for.

Cisco Collaboration System Migration

There are two main methods for migrating to a virtualized Cisco Collaboration System: phased migration and parallel cutover. Cisco Prime Collaboration Deployment can be used to manage and simplify the migration process.

Phased Migration

This method typically starts with a small trial focused around Cisco Unified Communications Manager (Unified CM). Once the customer is familiar with Unified CM, the system administrator can initiate the steps to migrate and move groups of users at a time to the production system, with the new Unified CM release.

Parallel Cutover

This method begins similar to the phased approach; however, once the customer is satisfied with the progress of the trial, then a time and date are chosen for cutting-over all the users at once to the new Cisco Collaboration System.

A parallel cutover has the following advantages over a phased migration:

  • If something unexpected occurs, the parallel cutover provides a back-out plan that allows you to revert, with minimal effort, to the previous system, which is essentially still intact. For example, with phased migration from a PBX, service can be restored to the users simply by transferring the inbound PSTN trunks from the Cisco Collaboration System gateway(s) back to the PBX.
  • Parallel cutover allows for verification of the configuration of the collaboration services before the system carries live traffic. This scenario can be run for any length of time prior to the cutover of the collaboration services, thereby ensuring correct configuration of all user information such as phones, gateways, the dial plan, mailboxes, and so forth.
  • The parallel cutover allows for verification of the configuration of the Unified Communications service before the system carries live traffic. This scenario can be run for any length of time prior to the cutover of the Unified Communications service, thereby ensuring correct configuration of all user information such as phones, gateways, the dial plan, mailboxes, and so forth.
  • Training can be carried out at a more relaxed pace by allowing subscribers to explore and use the collaboration services at their own pace prior to the cutover.
  • The system administrator does not have to make special provisions for "communities of interest." With a phased approach, you have to consider maintaining the integrity of features such as call pickup groups, hunt groups, shared lines, and so forth. These associations can be easily accounted for when moving the complete service in a parallel cutover.

One disadvantage of the parallel cutover is that it requires the collaboration services, including the supporting infrastructure, to be fully funded from the beginning because the entire system must be deployed prior to bringing it into service. With a phased migration, on the other hand, you can purchase individual components of the system as and when they are needed, and this approach does not prevent you from starting with a small trial system prior to moving to full deployment. Neither method is right or wrong, and both depend upon individual customer circumstances and preferences to determine which option is most suitable.

Cisco Collaboration System Migration Examples

The following examples illustrate a phased migration and a parallel cutover from a PBX system to a Cisco Collaboration System.

Example 28-1 Phased Migration to Cisco Collaboration System

This approach typically entails a small Cisco Collaboration System trial that is connected to the main corporate PBX. The choice of which signaling protocol to use is determined by the required features and functionality as well as by the cost of implementation. Cisco Unified Communications Manager (Unified CM) can support either regular PSTN-type PRI or QSIG PRI as well as H.323 and SIP. Of these options, QSIG PRI typically provides the highest level of feature transparency between any two systems.

PSTN-type PRI provides for basic call connectivity as well as Automatic Number Identification (ANI). In some instances, the protocol also supports calling name information. This level of connectivity is available to all PBXs and therefore is considered to be the least costly option; that is, if the PBX can connect to the public network through PRI, then it can connect to Unified CM because Unified CM can be configured as the "network" side of the connection.

With either PSTN-type PRI or QSIG, the process for a phased migration is similar: move users from the PBX to Unified CM in groups, one group at a time, until the migration is complete.

The Cisco San Jose campus, consisting of some 23,000 users housed in approximately 60 buildings, was migrated to a Cisco Collaboration System in this manner and took just over one year from start to finish at the rate of one building per weekend. All users in the selected building were identified, and their extensions were deleted from the PBX on a Friday evening. At the same time, additions were made to the PBX routing tables so that anyone dialing those extension numbers would then be routed over the correct PRI trunk for delivery to Unified CM. During the weekend, new extensions were created in Unified CM for the users, and new IP phones were delivered to their appropriate office locations, ready for use by Monday morning. This process was repeated for each building until all users had been migrated.

Example 28-2 Parallel Cutover to Cisco Collaboration System

For this approach, all IP phones and gateways are fully configured and deployed so that users have two phones on their desk simultaneously, an IP phone as well as a PBX phone. This approach provides the opportunity not only to test the system but also to familiarize users with their new IP phones. Outbound-only trunks can also be connected to the Cisco Collaboration System, giving users the opportunity to use their new IP phones to place external as well as internal calls.

Once the Cisco Collaboration System is fully deployed, you can select a time and date for bringing the new system into full service by transferring the inbound PSTN trunks from the PBX to the Cisco Collaboration System gateways. You can also leave the PBX in place until such time as you are confident in the operation of the Cisco Collaboration System, at which point the PBX can then be decommissioned.

The Cisco San Jose campus voicemail service was originally provided by four Octel 350 systems serving some 23,000 users. Cisco Unity servers were installed and users' mailboxes were configured. Users had access to the their Cisco Unity mailbox by dialing the new access number, in order to allow them to record their name and greeting(s) as well as to familiarize themselves with the new Telephony User Interface (TUI). Approximately two weeks later, a Unified CM Bulk Administration Tool (BAT) update was carried out on a Friday evening to change the Call-Forward Busy and No-Answer (CFB/CFNA) numbers as well as the Messages button destination number for all users to the Unity system. Upon returning to work on Monday morning, users were serviced by Cisco Unity. The Octel 350 systems were left in place for one month to allow users to respond to any messages residing on those systems before they were decommissioned.

Summary of Cisco Collaboration System Migration

Although both methods of Cisco Collaboration System migration work well and neither method is right or wrong, the parallel cutover method usually works best in most cases. Cisco has a lab facility dedicated to testing interoperability between Unified CM and PBX systems, which might or might not include your current system architecture and applications. Cisco documents these test systems and their interoperability and end-user features, which should help greatly with the installation and migration process. The results of that testing are made available as application notes, which are posted at

http://www.cisco.com/go/interoperability

The notes are updated frequently, and new documents are continuously added to this website. Check the website often to obtain the latest information.

Cisco Prime Collaboration Deployment 10. x includes many enhancements over previous versions of Cisco Prime Collaboration, and it is the primary tool for migration to Cisco Collaboration System 10. x.

Centralized Deployment

In the case of an enterprise that has chosen a centralized deployment model for its Cisco Collaboration System, two options exist:

  • Start from the outside and work inward toward the central site (that is, smallest to largest).
  • Start from the central site and work outward toward the edges.

The majority of customers choose the first option because it has the following advantages:

  • It provides the opportunity to fully deploy all the Cisco Collaboration services and then conduct a small trial prior to rolling the services out to the remote locations.
  • The rollout of Cisco Collaboration services can be done one location at a time, and subsequent locations can be migrated whenever convenient.
  • This option is the lowest cost to implement once the core Cisco Collaboration services are deployed at the central site.
  • IT staff will gain valuable experience during migration of the smaller sites prior to migrating the central site.

The remote sites should be migrated by the parallel cutover approach, whereas the central site can be migrated using either the parallel or phased approach.

Which Cisco Collaboration Service to Migrate First

This choice depends mainly on the customer's particular business needs, and Cisco Collaboration solutions allows for most of the individual services to be deployed independently of the others. For example, IP telephony, voice messaging, contact center, and collaborative conferencing can all be deployed independently from each others.

This capability provides the customer with great flexibility. Consider a customer who is faced with a voicemail system that has since gone end-of-support and is suffering various issues leading to customer dissatisfaction. Cisco Unity Connection can often be deployed and integrated with the current PBX, thereby solving this issue. Once the new voicemail system is operating appropriately, then attention can turn to the next collaboration service, namely IP telephony.

Migrating Video Devices to Unified CM

Video endpoints controlled by Cisco Unified Communications Manager (Unified CM) 10. x might support only a subset of the features that are available with a video-centric Cisco Video Communications Server (VCS). However, migration to Cisco Unified CM can provide advantages such as a unified dial plan and consolidation of other features under a single call control agent. The following guidelines apply for migrating video endpoints to Unified CM:

  • Ensure that the technical functionality (for example, codecs or the ability to do content sharing) is fully supported so that the migration will not result in the loss of any features.

– Phased migration is the most commonly used method for this purpose because it enables users to become familiar with the new devices while still having their existing phones as backup for some time.

– Provide adequate network capacity to ensure a good experience for users. As the video resolution increases, higher bandwidth is needed when compared with audio-only calls.

– Migrate the dial plan and associated gateways (for example, ISDN H.320 gateways) and application servers (for example, conferencing servers and bridges).

  • For endpoints, consider any additional licenses needed if endpoint versions will be upgraded or if some devices need different licenses.

– System management tools can be a big help when there is a large number of endpoints or if the endpoints need more back-end administration and support.

Organizations can then assess the types of devices, the feasibility, and the scope of the tasks needed so that the migration of video devices to Unified CM is as efficient and effective as possible.

Migrating Licenses to Cisco Collaboration System Release 10.x

Cisco Collaboration System Release 10. x provides centralized license management whereby license usage moves away from the Device License Unit (DLU) concept and implements user-based licensing, thereby matching what a customer actually purchases. This new licensing model for 10. x releases is under the management of the Cisco Prime License Manager (Prime LM), previously named Enterprise License Manager (ELM), with added new features.

Note If your existing Enterprise License Manager (ELM) resides on a physical server, then in order to upgrade to 10.x you must move to a virtual environment, and in doing so your existing licenses must be rehosted to the new virtual machine and reinstalled. In a virtual environment, just as with ELM, the new Prime License Manager also requires a static MAC address to function properly.

Customers who have already deployed Cisco Unified Communications can use the Cisco Global Licensing Operations (GLO) process to migrate existing licenses to Cisco Prime License Manager.

License Migration with Cisco Global Licensing Operations (GLO)

A new self-serve option is now available for those experienced with the Cisco software licensing process and functions. This self-serve option is available through the Product License Registration tool at

https://tools.cisco.com/SWIFT/LicensingUI/migrateDisplayProducts

Note You must have a valid Cisco.com login ID and password in order to access the Product License Registration tool at the above link.

You may also get assistance from the Cisco Global Licensing Operations (GLO) team by either opening a case using the Support Case Manager https://tools.cisco.com/ServiceRequestTool/scm/mgmt/case or submitting the form at https://survey.opinionlab.com/survey/s?s=10422.

For all license migrations, follow the guidelines presented in this section.

The license migration process has been simplified to make the migration to Prime License Manager much easier. Customers wanting to upgrade to Cisco Collaboration System Release 10. x may contact the Cisco Global Licensing Operations (GLO) team directly for all migration needs. GLO processes the request and sends the license file, a statement describing any user quantity changes, and the migration policy to the requester's email address. Cisco adjusts the current software service contract product records to reflect the number of Release 10. x users that have been licensed. The requester also receives an email about any contract record updates to the user quantities. If it is a license entitlement inquiry, then GLO sends the current entitlement information directly to the requester.

Make sure you register any unused Product Activation Keys (PAKs) for the system being migrated. If the customer had planned for growth in the previous license model, take that into consideration for the current migration. As an example, if there is a need to have some clusters on a pre-10. x release while upgrading the rest to 10. x, then the license migration request to the GLO team must clearly state exactly how many DLUs need to be migrated and how many will still be utilized in the old format when the request is made.

Ensure that you have analyzed all licensing needs in detail, and clearly state the needs in the request. If migration is from a pre-9. x release with DLUs, once those DLUs are migrated there is no way to revert back to the old schema because all migrated DLUs will be in the "revoked" state.

Note The licensing process is subject to change with each new release. Always confirm the process with Cisco GLO before submitting your license request to license@cisco.com.

You can contact GLO for license migration during the following stages:

  • Before the upgrade process to obtain the current license entitlement.
  • After the upgrade process to obtain Cisco Unified Communications Manager Release 10. x migration licenses.

Before the Upgrade

You will need to provide GLO with the following information:

  • If you are upgrading from a pre-9. x system, then use License Count Utility (LCU) output that was run on the Cisco Unified Communications Manager publisher node.
  • MAC address of the Cisco Unified Communications Manager publisher node. If available, include all previous publisher or license MAC addresses.

After the Upgrade

You will need to provide GLO with the following information:

  • If you are upgrading from a pre-9. x system, then use License Count Utility (LCU) output that was run on the Cisco Unified Communications Manager publisher node.
  • MAC address of the Cisco Unified Communications Manager publisher node. If available, include all previous publisher or license MAC addresses.
  • Prime LM generated license request in a.txt file as an attachment.
  • Site information for the contract update (for example: name-all name permutations, city, state, country)
  • (Optional) Email addresses to send license and software support contract updates.
  • (Optional) If a User Connect License (UCL) customer, how the customer wants to allocate unused DLUs.

Note For all pre-9.x systems moving to Collaboration System Release 10.x, customers must decide if they want to use their unused DLUs or drop them at the time of migration. There are no refunds for dropped DLUs; however, customers will save on future service charges. Note the differences between current Cisco Unified Communications Software Subscription (UCSS) users on contract and estimate the change, if any, in their UCSS and Essential Operate Services (ESW) costs at renewal.

At the time of migration, customers may choose how to use their existing licenses. The options are:

  • Keep the same quantity and type of licenses.
  • Decrease license quantity and change type (no refund).
  • Increase license quantity by converting DLUs.
  • Upgrade license types using the Drive-to-9 promotion.

After the upgrade process is complete, the information is locked in and becomes the customer entitlement record moving forward. There are no further modifications to the license migration information.

For more information, refer to the following sources:

  • Cisco Prime License Manager User Guide, Release 10.0(1)

http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/plm/10_0_1/CPLM_BK_U7066CD8_00_user-guide-rel-10-0-1.html

  • Release Notes for Cisco Prime License Manager Release 10.0(1)

http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/plm/CUCM_BK_P73D8919_00_plm_rn_1001.html

  • Enterprise License Manager User Guide, available at

http://www.cisco.com/c/en/us/support/unified-communications/unified-communications-manager-callmanager/products-maintenance-guides-list.html

Cisco Prime License Manager

Cisco Prime License Manager (Prime LM, formerly Cisco Enterprise License Manager) aligns with the Cisco Prime management suite of products. Cisco Prime LM offers new features and capabilities and adds support for Cisco Emergency Responder. Cisco Prime LM also supports multiple clusters and multiple versions of products, such as Cisco Unified CM versions 9. x and 10. x.

If you choose to remain on Cisco Enterprise License Manager (ELM) 9. x and have 10. x clusters, ELM can support both Unified CM version 9. x and 10. x with an update from a Cisco Option Package (COP) file; however, Cisco highly recommends upgrading to Cisco Prime LM to leverage new features and functions.

Cisco Prime LM currently supports the following Cisco Collaboration applications:

  • Cisco Unified CM
  • Cisco Unified CM Session Management Edition (SME)
  • Cisco IM and Presence Service
  • Cisco Unity Connection
  • Cisco Business Edition 6000
  • Cisco Emergency Responder
  • Cisco WebEx Meetings Server

For migration of other applications not supported by Cisco Prime Collaboration Deployment, follow the specific product migration guidelines provided in the documentation available at

http://www.cisco.com/en/US/products/sw/voicesw/ps556/prod_maintenance_guides_list.html

Types of License Migrations

Manual migration:

  • Used by Cisco Unified CM and Unity Connection; Cisco Unified Workspace License (CUWL) only

Migration with manual fulfillment:

  • Migration without required Cisco Support; fulfillment through Customer Portal
  • Used by version 9. x of Cisco Unified CM and Unity Connection
  • Used by Cisco Unity Connection 9. x (non-CUWL)
  • Used by version 10. x of Cisco Unity Connection (non-CUWL) and Emergency Responder

Migration with electronic fulfillment:

  • Migration without required Cisco Support; electronic fulfillment through Cisco Prime LM

Migration with Cisco Global Licensing Operations (GLO)

  • Migration via email request to the Cisco GLO Team for migration assistance
  • Migration via the self-serve option for users experienced in the licensing process and functions

Considerations for Migrating Pre-9.x Licenses to Unified CM 10.x

  • Register and install all Product Activation Keys (PAKs).
  • Inventory all purchased and installed licenses.
  • Use the License Count Utility and submit to licensing@cisco.com.
  • Purchase upgrades per quantity and type required.
  • Purchase new users for augmented quantities, if planning for growth.
  • Install and configure Cisco Prime License Manager (Prime LM), and add product inventory.
  • Run the Prime LM Migration Utility.
  • Submit Migration Utility output to licensing@cisco.com.
  • Cisco Global Licensing Operations will issue the 10. x licenses.

PAKs are required for all migration license requests submitted to the Cisco Global Licensing Operations (GLO) team by email to licensing@cisco.com. When it fulfills a request, GLO provides the license file(s) to the requester via email, and the migration can proceed. Existing customers using Cisco Unified Communications 9. x release with Cisco Enterprise License Manager may upgrade directly to release 10. x to get all the benefits of Cisco Prime LM. To fulfill any new licenses, please proceed to the Cisco Product License Registration portal at

http://www.cisco.com/go/license

Using Cisco Prime Collaboration Deployment for Migration from Physical Servers to Virtual Machines

Cisco Prime Collaboration Deployment is a management application that enables administrators to perform migration from legacy Cisco Unified CM and Cisco IM and Presence services to a virtualized environment in Cisco Collaboration System Release 10. x. Cisco Prime Collaboration Deployment can migrate the cluster(s), handle data migration, and install the 10. x release on all the new VMware ESXi hosts with very little impact to the production (source) cluster. Cisco Prime Collaboration Deployment does a direct migration, whereas previous migration methods involved more steps with a "server recovery" Disaster Recovery System relying on an initial upgrade followed by a restore from backup.

Cisco Prime Collaboration Deployment can also be used to:

  • Upgrade Unified Communications software (8.6.1 and later releases)
  • Install Cisco Option Package (COP) files (locales or device packs) on a cluster (8.6.1 and later releases)
  • Switch versions
  • Reboot
  • Change IP addresses or hostnames on existing 10. x clusters
  • Install a new Unified CM or IM and Presence cluster

Cisco Prime Collaboration Deployment Migration Types

Cisco Prime Collaboration Deployment supports two types of migrations:

In a simple migration, each node in the cluster keeps its original hostname and IP address as well as all other network configurations.

In a network migration, one or more nodes in the cluster have a change in hostname, IP address, and/or any other network configuration needed for Collaboration Applications.

Cisco Prime Collaboration Deployment Migration Prerequisites

  • Install the VMware ESXi Hypervisor.
  • Deploy the Cisco Prime Collaboration Deployment virtual machine (delivered as a virtual appliance).
  • Download and install Cisco Prime Deployment and associated Open Virtualization Archive (OVA) templates, and create target virtual machines using the templates.
  • Download Cisco ISO images for the target release and upload them to Cisco Prime Collaboration Deployment.
  • Export data from the old nodes to a Secure File Transfer Protocol (SFTP) server in preparation for importing and installing on the new virtual machines.
  • Install Cisco Collaboration System Release 10. x nodes on the virtual machines.

Simple Migration

A migration without any network changes (such as hostname, IP address, or DNS changes) can use the phased migration approach. In a simple migration, Cisco Prime Collaboration Deployment first installs the COP file on each node in the cluster. It then exports the data of the publisher node first. Cisco Prime Collaboration Deployment will power down the existing publisher and then install and import the publisher’s data into the new virtual machine. After publisher migration is done, Cisco Prime Collaboration Deployment begins exporting data, powering off existing servers, and installing the backup call processing nodes of the cluster. Once those backup nodes are up, Cisco Prime Collaboration Deployment exports the data from the primary call processing nodes. After Cisco Prime Collaboration Deployment powers off the primary call processing nodes, phones will register to the backup call processing nodes. Cisco Prime Collaboration Deployment then starts installing and importing the new primary call processing nodes.

Note Cisco Prime Collaboration Deployment can perform a migration from various releases, but the destination release for migration to virtual machines must be Cisco Collaboration System Release 10.x.

Network Migration

For a migration with network changes, Cisco Prime Collaboration Deployment can be utilized for the parallel cutover approach. In a network migration, all nodes perform the data export at the same time, then Cisco Prime Collaboration Deployment installs the publisher node. After that, all the nodes can be installed at the same time. After the new cluster nodes are installed, the phones can be reset to add new TFTP servers. Once the phones have switched over to the new nodes, the old cluster nodes can be powered off to complete the cutover to the new system.

Migrating Video Endpoints from Cisco VCS to Unified CM

Video endpoints migrated from the Cisco TelePresence Video Communication Server (VCS) to Cisco Unified CM 10. x might support only a subset of the features that were available in the video-centric VCS environment. However, migration to Cisco Unified CM can provide advantages such as a unified dial plan and consolidation of other features under a single call control agent. Migration of video endpoints to Cisco Unified CM supports both SIP and SCCP endpoints, but Cisco recommends that all customers move to SIP endpoints. Although SCCP is supported, SIP has grown in popularity among both Unified Communications vendors and customers, and SIP features and functionality have grown, making SIP the new standard and recommended choice for Unified Communications.

Consider the following recommendations when migrating video endpoints to Unified CM as SIP endpoints:

  • Ensure that the technical functionality (for example, codecs or the ability to do content sharing) is fully supported so that the migration will not result in the loss of any features.
  • Provide adequate network capacity to ensure a good experience for users. As the video resolution increases, higher bandwidth is needed when compared with audio-only calls.
  • Migrate the dial plan and associated gateways or trunks (for example, ISDN H.320 gateways) and application servers (for example, conferencing servers and bridges).
  • For endpoints, consider any additional licenses needed if endpoint versions will be upgraded or if some devices need different licenses.
  • System management tools can be a big help when there is a large number of endpoints or if the endpoints need more back-end administration and support.
  • Customers should assess the types of devices, the feasibility, and the scope of the tasks needed so that the migration of video devices to Unified CM is as efficient and effective as possible.

Migrating from H.323 to SIP

H.323 was designed with a good understanding of the requirements for multimedia communications over IP networks, including audio, video, and data conferencing. It defines an entire unified system for performing these functions. Although SIP adoption is on the rise, H.323 is still the most widely deployed protocol for videoconferencing endpoints due to its longevity in the field. Organizations have spent a lot of effort and money deploying H.323, so they understand how it fits into their environment.

SIP is easier to implement and has begun to gain popularity in the video marketplace. As organizations struggle with the idea of changing signaling protocols, the industry has continued to evolve, and SIP has become popular for its ease of use and ability to integrate with other vendors’ products. Cisco Collaboration Systems support both H.323 and SIP, but Cisco strongly recommends utilizing SIP because it provides a set of services similar to H.323 with far less complexity, rich extensibility, and better scalability.

Migrating Trunks from H.323 to SIP

Cisco Unified CM supports both SIP and H.323 intercluster trunks, and in many cases the decision to use SIP or H.323 is driven by the unique feature(s) offered by each of the protocols. A number of factors can dictate the choice customers make, such as experience, ease of interoperability, features, and functionality with various other products. While Cisco Collaboration Systems support both H.323 and SIP trunks, Cisco recommends using SIP trunks for all deployments because SIP trunks provide ease of interoperability as well as additional features and functionality not available with H.323 trunks.

For detailed information on H.323 and SIP trunk capabilities and operation, see the chapter on Cisco Unified CM Trunks.

Migrating Gateways from H.323 to SIP

Cisco Unified Communications Manager (Unified CM) supports both SIP and H.323 protocols for gateways. Cisco gateways provide a number of methods for connecting Cisco Collaboration Systems to the Public Switched Telephone Network (PSTN), a legacy PBX, or third-party external deployment solution. Cisco provides both voice and video gateways, from entry-level to high-end, that fully support both protocols, but Cisco highly recommends SIP as the choice for all call signaling because it interoperates better with the entire portfolio of Cisco Collaboration voice and video products.

For detailed information on H.323 and SIP gateway capabilities and operation, see the chapter on Gateways.

Migrating Endpoints from SCCP to SIP

Given Cisco's general recommendation for Session Initiation Protocol (SIP) standard signaling, administrators should consider migrating their existing SCCP IP endpoints to SIP IP endpoints to provide feature parity and standards compliance. If existing SCCP IP phone models support SIP loads, administrators can use the Cisco Unified CM Bulk Administration Tool (BAT) to perform this migration.

Unified CM BAT is the recommended tool to migrate SCCP phones to SIP phones. SIP is a universal protocol standard in the industry. Within Unified CM BAT, there is an option for SCCP-to-SIP phone migration workflow (Bulk Administration > Phones > Migrate Phones > SCCP to SIP), which generates a report of existing SCCP phones. After selecting the SCCP phones to be migrated, the job to migrate these devices to SIP can be run immediately or scheduled for later. During the SCCP-to-SIP migration, only SIP specific default values in the phone report get migrated; other values in the template are not migrated. Migrating a phone from SCCP to SIP does not require a manual reset because the migration itself handles the reset of the phones.

For more information and detailed migration steps, refer to the latest version of the Cisco Unified Communications Manager Bulk Administration Guide, available at

http://www.Cisco.com/en/US/products/sw/voicesw/ps556/prod_maintenance_guides_list.html

SIP URI Dialing and Directory Numbers

SIP uniform resource identifiers (URIs) are an addressing schema for directing calls to users. A URI is essentially an alias for a user's assigned directory number. A SIP URI resembles an email address and is written in the following format:

sip: x @ y : Port

where x =username and y =host (domain or IP)

For example:

username@cisco.com or users-directorynumber@cisco.com

URIs are alphanumeric strings consisting of a user name and a host address separated by the @ symbol. Cisco Unified CM supports the following formats for directory URIs:

  • User @ domain (for example, joe@cisco.com)
  • Users-directorynumber @ domain (for example, 9728135555@cisco.com)

If the SIP request carries a user=phone tag, the SIP URI is interpreted as a numeric SIP URI and Unified CM assumes that the user portion of the SIP URI is a directory number. If no user=phone is present, the decision is based on the dial string interpretation setting in the calling device's (endpoint or trunk) SIP profile. This setting either defines a set of characters that Unified CM will accept as part of numeric SIP URIs (0-9, *, #, +, and optionally A-D) or it enforces the interpretation as a directory URI.

In releases prior to Cisco Unified CM 9.0, all SIP URIs are always treated as numeric SIP URIs.

Note If you do not specify a port, the default SIP port (5060) is assumed. If you have changed the default SIP port to something else, then you must specify it in the SIP URI.

The following URI and directory number (DN) considerations apply to Unified CM and supported endpoints:

  • DNs are the primary identity of the endpoint device.
  • URIs are assigned to DNs, and each DN can support up to 5 URIs.
  • Devices always register with their DNs.
  • URIs can be dialed from Cisco Unified IP Phone 9900 Series, Cisco Unified IP Phone 8961, Cisco Jabber for Windows 9.6, Cisco Desktop Collaboration Experience DX650, and third-party endpoints.
  • The primary URI can be synchronized directly from LDAP in Unified CM.

For more information, see the section on Implementing Endpoint SIP URIs.

USB Support with Virtualized Unified CM

Music on hold (MoH) from an audio source file (using unicast or multicast) is supported; however, fixed or live audio source connections to Unified CM are not supported with Unified CM 10. x due to lack of USB audio support with virtualized servers. The following guidelines apply to live audio source MoH with virtualized Unified CM server nodes:

  • Live or fixed audio source feeds from a USB audio device are not supported on Unified CM 10. x.
  • Instead, a Cisco IOS router may be used to deliver multicast MoH feeds from fixed or live audio sources. This requires configuration of multicast MoH on the Cisco IOS router using Survivable Remote Site Telephony (SRST) or Enhanced SRST.
  • Multicast must be enabled on the network to enable the Cisco IOS router to stream audio to endpoints and gateways.

While the Cisco UCS B-Series Blade Servers and C-Series Rack-Mount Servers do support a local keyboard, video, and mouse (KVM) cable connection that provides a serial port, a Video Graphics Array (VGA) monitor port, and two Universal Serial Bus (USB) ports, the Unified CM VMware virtual application has no access to these USB and serial ports. Therefore, Unified CM no longer supports the Cisco Messaging Interface (CMI) service for Simplified Message Desk Interface (SMDI) integrations, fixed MoH audio source integration for live MoH audio feeds using the audio cards, or flash drives to these servers.

On-Premises Cisco IM and Presence Service Migration

Cisco IM and Presence Service 10. x supports only virtualized server instances. Earlier versions of Cisco IM and Presence must migrate from Cisco MCS physical server hardware to Cisco Unified Computing System (UCS) virtualized hardware in order to deploy IM and Presence Service 10. x.

Migration from earlier releases of Cisco Unified Presence to Cisco IM and Presence Service is supported in the following cases (see Figure 28-1):

  • Direct migration from Cisco Unified Communications Manager (Unified CM) 7. x or 8. x to Cisco Unified Communications 9. x IM and Presence — provides the ability to deploy Unified CM with voice, video, IM, and presence.
  • Direct migration from Unified CM 7. x or 8. x and Cisco Unified Presence 8. x to Cisco Unified Communications 9. x IM and Presence — provides the ability to deploy Unified CM with voice, video, IM, and presence.

Earlier versions of Unified CM and Cisco Unified Presence require a multi-step upgrade migration.

Figure 28-1 Large Enterprise Migration with Backward Compatibility