Cisco Collaboration System Migration

Revised: March 17, 2014; OL-29367-05

This chapter discusses how the individual Cisco Collaboration family of applications can be migrated either from earlier releases or from existing third-party deployments. This chapter also describes several methods for migrating from separate standalone communication components to an integrated Cisco Collaboration System. The topics discussed in this chapter are viewed from a customer or business viewpoint rather than a technical viewpoint that is based around which protocol to use or which features are required.

When considering any form of migration and/or upgrade, customers should first consult the following resources to ensure a successful outcome:

For example, some applications may start from such an early software release that a multi-step upgrade might be necessary. Similarly, server hardware along with software compatibility might require a combination of multi-step hardware and software upgrades.

Strong consideration should also be given to other Unified Communications applications because the system currently deployed might have multiple applications that have limited compatibility of interworking with each other.

For more information on Cisco Collaboration products, refer to the various guides available at

Coexistence or Migration?

This is an important question that needs to be answered.

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" period of time. Often existing system capabilities may be sufficient for this "short" period of time, therefore migration is often less costly when compared to coexistence.

Migration Prerequisites

Before implementing any Unified Communications service, customers should ensure that the underlying IP infrastructure is "UC ready," including redundancy, high availability, Quality of Service (QoS), in-line powered Ethernet ports, and so forth. For further details, refer to the chapter on Network Infrastructure.

Business needs of the users play an important role in identifying key system requirements (for example, phone hunt, Turret type phones, or manager/assistant needs) so that the features and functionality are preserved 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 site or user-survey should be performed to ensure that all requirements (for example, fax/modems, environmental control systems, and so forth) are appropriately identified and accounted for.

For an initial deployment of Cisco Unified Communications on Cisco Unified Computing System (UCS), follow the guidance in the
Cisco UCS Site Preparation Guide
, available at

Unified Communications Migration

There are two main methods for migrating to a Unified Communications system (or any individual Unified Communications service, for that matter):

Phased Migration

This method typically starts with a small trial focused around the Unified Communications service to be deployed. Once the customer is familiar with the Unified Communications service trial, then the migration starts by moving groups of users, one group at a time, to the production version of that Unified Communications service.

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 Unified Communications service.

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 Unified Communications gateway(s) back to the PBX.

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 Unified Communications service at their own leisure 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 pick-up groups, hunt groups, shared lines, and so forth. These associations can be easily accounted for when moving the complete Unified Communications service in a parallel cutover.

One disadvantage of the parallel cutover is that it requires the Unified Communications service, including the supporting infrastructure, to be fully funded from the beginning because the entire service 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.

Example 28-1 Phased Migration for Unified Communications

This approach typically entails a small Unified Communications 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 Unified Communications 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 for Unified Communications

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 Unified Communications system, giving users the opportunity to use their new IP phones to place external as well as internal calls.

Once the Unified Communications 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 Unified Communications gateways. You can also leave the PBX in place until such time as you are confident in the operation of the Unified Communications system, at which point the PBX can then be decommissioned.

The Cisco San Jose campus voicemail service was 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 Unity mailbox by dialing the new access number, in order to allow them to record their name and greeting(s) as well as to allow them 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 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.

The Need for QSIG in Multisite Enterprises

While some enterprises consist of only one location, others consist of many sites, some of which may potentially be spread over large distances. PBX networks for multisite enterprises are usually connected using T1 or E1 PRI trunks (depending on location) running a proprietary protocol such as Avaya DCS, Nortel MCDN, Siemens CorNet, NEC CCIS, Fujitsu FIPN, or Alcatel ABC, among others. These proprietary networking protocols enable the PBXs to deliver a high level of feature transparency between end users.

QSIG was developed to enable the interconnection of PBXs from different vendors, thereby allowing similar levels of feature transparency.

By supporting QSIG, Unified CM can be introduced into a large enterprise network while also maintaining feature transparency between users. PBX locations can then be converted to Unified Communications whenever convenient.

However, unless you already have QSIG enabled on your PBX or have a specific need for its additional features and functionality, the cost of upgrading the PBX might be hard to justify if it will be retired within a short period of time. For example, why spend $30,000 on enabling the PBX for QSIG if you plan to retire the PBX in two or three months?

Summary of Unified Communications Migration

Although both methods of Unified Communications migration work well and neither method is right or wrong, the parallel cutover method usually works best in most cases. In addition, large enterprises can improve upon either migration method by using QSIG to enable Unified CM to become part of the enterprise network.

Cisco has a lab facility dedicated to testing interoperability between Unified CM and PBX systems. The results of that testing are made available as application notes, which are posted at

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

Centralized Unified Communications Deployment

In the case of an enterprise that has chosen to deploy Unified Communications in a centralized manner, 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 gives them the opportunity to fully deploy all the Unified Communications services and then conduct a small trial prior to rolling Unified Communications out to the remote locations.

The rollout of Unified Communications can be done one location at a time, and subsequent locations can be migrated when convenient.

This option is the lowest cost to implement once the core Unified Communications 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 approach, whereas the central site can be migrated using either the parallel or phased approach.

Which Unified Communications Service First?

This choice is very much dependent on the customer's individual business needs, and the Cisco Unified Communications solution allows for most of its individual services to be deployed independently of the others; for example, IP telephony, voice messaging, contact center, and collaboration 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 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 Unified Communications service, namely IP telephony.

Migrating from Physical Servers to Virtual Machines

This type of migration refers to migrating from a system with Cisco Unified Communications Manager (Unified CM) deployed on a physical cluster of Cisco Media Convergence Servers (MCS) to a system with Unified CM deployed on Cisco Unified Computing System (UCS) virtual machines. The simplest way to perform this type of migration is through the disaster recovery service (DRS) method.

The DRS backup-and-restore server replacement method is carried out by performing a backup operation on each physical server in the Unified CM cluster and then restoring the backup to the corresponding virtual machine. This is a serial process, and depending upon the number of servers involved and the available outage windows, it may take some time to complete. This approach is preferred over simply doing a re-import of the database through the Cisco Unified CM Bulk Administration Tool (BAT) and has the advantage that it fully captures the state of the cluster (for example, custom music-on-hold files, non-default TFTP firmware files, states of various Unified CM services, and so forth) at the time the backup is taken.

There are currently well defined processes for moving existing MCS severs to virtual machines, described as server replacement and IP readdressing. For details, refer to the latest version of
Replacing a Single Server or Cluster for Cisco Unified Communications Manager
, available at

Cisco IM and Presence Migration

Migration from earlier releases of Cisco Unified Presence to Cisco IM and Presence is supported with a multi-step upgrade migration process.

Direct upgrades from Cisco Unified Presence Release 6.0(
x
) to Release 9.
x
are not supported. You must first upgrade to at least Release 8.0(1) of Cisco Unified Presence, then move to Release 9.
x
of Cisco IM and Presence, which provides the ability to deploy Unified CM with voice, video, IM, and presence.

For Cisco Unified Communications System 9.0 and later releases, Cisco Unified CM and the Cisco IM and Presence Service are required to run the same version at all times. You must upgrade Unified CM before you can upgrade IM and Presence to the matching version.

The Cisco IM and Presence Service (9.0 and later releases) supports backward compatibility, thereby providing customers who have multiple Cisco Unified Presence systems with the opportunity to upgrade those systems over a period of time. (See Figure 28-1.)

Figure 28-1 Large Enterprise Migration with Backward Compatibility

Migrating Video Devices to Unified CM

Video endpoints controlled by Cisco Unified Communications Manager (Unified CM) 9.
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.

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 efficient and effective as possible.

Migrating Licenses to the Cisco Enterprise License Manager (ELM)

Cisco Unified Communications System 9.
x
moves away from the Device License Unit (DLU) concept and implement user-based licensing, thereby matching what a customer actually purchases. This new licensing model is also under the management of the Cisco Enterprise License Manager (ELM). For more details on ELM, see the section on Enterprise License Manager.

For those products that support ELM, customers can continue to fulfill their licenses from the Cisco Product License Registration portal at http://www.cisco.com/go/license
, and can now import them into the ELM instead of the individual product instances. Customers who have already deployed Cisco Unified Communications can use the Cisco Global Licensing Operations (GLO) process, described in the next section, to migrate existing licenses to Cisco Enterprise 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

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

The license migration process has been simplified to make the migration to Enterprise License Manager much easier. Customers wanting to upgrade to Cisco Collaboration Systems Release 9.
x
may contact Cisco's 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 9.
x
users that have been licensed. The requester also receives an email about any contract record updates to the Release 9.
x
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-9.
x
release while wanting to upgrade the rest to 9.
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. Once the 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:

(Optional) If a User Connect License (UCL) customer, how the customer wants to allocate unused DLUs.

Note 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.

Licenses to upgrade to Cisco Unified Communications Manager Release 9.
x
from any intermediate releases should be migrated or re-hosted to the new release. These intermediate releases might need a server node, software feature, and device licenses for the server upgrade to be possible. License migration or re-hosting should also be done when migrating from physical MAC address-based licenses for MCS servers to MAC address-based licenses for virtualized UCS servers.

Customers with Cisco Unified Communications Software Subscription (UCSS) are assured the same licensing capability and capacity at no cost as they migrate to Cisco Unified Communications Manager Release 9.
x
.

Customers will be granted new 9.
x
licenses for the users and devices that they currently have configured on their systems. In addition, Cisco Unified Communications Manager (User Connect License) customers have the ability to apply their unused DLUs to new 9.
x
licenses at the time of migration. The use of features such as extension mobility will be issued at no cost for the migration.

Software services at next renewal:

At the time of the next UCSS/ESW contract renewal after migrating to 9.
x
, the UCSS/ESW contract terms and price are based on the user count and license type that was issued during license migration, plus any additional users that were purchased after migration. When a customer has multiple UCSS/ESW contracts, the license is attached to the first contract.

Migration to Cisco Unified Workshop Licenses (CUWL):

Customers migrating to new Cisco Unified Workshop Licenses that have not been previously purchased must purchase the migration to CUWL, including the associated UCSS and ESW.

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.