Migrate CUCM 6.x to CUCM 9.x

[Cesar TM]

Hi,

I need migrate CUCM 6.x (8500 DLU - 1000 IP Telep.) to CUCM 9.x. Can i Directly migrate 6.x -> 9.x or need first migrate 6.x -> 8.x and then migrate to 9.x?

Need more additional licenses?

Name	Catalog Num	Description	Unit Price	Final Price	Qty
Voice and IP Communications
R-UCL-UCM-LIC-K9	R-UCL-UCM-LIC-K9	Top Level SKU For 9.x User License - Electronic Delivery	0,00	0,00	1
Software
CCX-90-CMBUNDLE-K9	CCX-90-CMBUNDLE-K9	CCX 9.0 Promo Bundle available only with NEW CUCM or BE6000	Included	Included	1
IME-PAK-K9	IME-PAK-K9	Auto-expanding PAK for IME 9.0	Included	Included	1
UCSS-UCM-PAK	UCSS-UCM-PAK	Include PAK Auto-expanding UCSS PAK for CUCM	Included	Included	1
CUCM-VERS-9.0	CUCM-VERS-9.0	CUCM  Software Version 9.0	0,00	0,00	1
IME-VERS-9.0-K9	IME-VERS-9.0-K9	IME  9.0 Server Software	0,00	0,00	1
MIG-CUCM-USR-B	MIG-CUCM-USR-B	Migration to UC Manager Enhanced - 1K - 10K Users	9,00	9,00	1.000
UCSS-UCM-ENH-B-3-1	UCSS-UCM-ENH-B-3-1	UC Manager Enh UCSS 1K to 10K users - 1 user - 3 years	29,00	29,00	1.000
Services
CON-ESW-MIGCUC03	CON-ESW-MIGCUC03	ESSENTIAL SW Migration to UC Manager Enhanced	6,00	6,00	1.000

[dakeller]

You are not completely off base, but when we talk about upgrading/migrating a cluster, you have to include all nodes in the process.  So in your step 2 above, you install & restore on a spare MCS appears to be just the publisher.   For a supported upgrade/migration, you will need to include all subs in the process. 

So here is a rough outline of the correct steps

1. Perform a DRS backup from my Production Env (all nodes)

2. Install Pub and subs & Restore on a spare MCS servers, exact build as my prod

3. Upgrade all nodes to 9.1 UC on the MCS

3.5 DRS Backup all nodes

4. Configure my new BE6k ESXI,

5. Run the OVA 9.1 and bootable ISO (on all nodes)

6. Preform a cluster wide DRS restore  in which the database will be tact with CTI route points, devices, users, gateways, etc. (on all nodes)

7. License (pub only)

8. Verify database replication and test.

The other choice you have is that instead of building the lab environment on MCS servers, you can use the Jump migration that will allow you to install UCM 7.1(3) on VMs, This will free you from having to find 3 physical servers for Step 2.  Check out Jump Upgrade Procedure for Cisco Unified Communications Manager Release 4.1(3)–7.1(5) to 9 | UC Migrations | Cisco Suppo… for details on the jump procedure.

Thanks,

Dan Keller

Technical Marketing Engineer

[jfloreszak12]

thanks for the last reply.

We have purchased the new attendant console standard licenses. I know that you have to download the client software on to a pc that meets the requirements, but how do you set up the call flows since the Pilot Points go away?

[Piotr Gorka]

Hi Daniel.

I need help with rehost license from CUCM MCS 8.6.2 to virtual appliance CUCM 8.6.2.

What I should do ?

[Hythim Ali El Hadad]

Send an email to licensing@cisco.com<mailto:licensing@cisco.com> with your requirements

Sent from my iPhone

[dakeller]

Poitr,

You will need to work with licensing.  hythamhadad's answer is correct.

Thanks,

Dan Keller

Technical Marketing Engineer

[Piotr Gorka]

Thanks Daniel for your help.

Can you tell me, is it possible migrate and upgrade  CUCM MCS 8.6.2 directly to CUCM 10.5 and after migrate license ?

[dakeller]

This is not only possible, but one of the migration paths that Cisco Supports through the Prime Collaboration Deployment (PCD) tool.  You will have two options for this upgrade/migration.  You will have slightly different processes depending on if you keep the same hostname/IP address or you upgrade/migrate to new hostnames/IP address, but PCD can handle both paths.  Once you complete the upgrade/migration, you can migrate your licenses to the 10.5 system.

Thanks,

Dan Keller

Technical Marketing Engineer

[wcalvache]

Hi Guys

I Have a queston. If I have CUCM 6.1.4 in MCS,  and I want VmWare 9.x in a different machine. Is a option install 6.1.4 in VmWare, install backup. and then upgrade to 9.x?

[stuart.pannell]

I have seen on other forums attempts to do this and the upgrade fails, Cisco so I am told will only support 8.0(2) and above on VMWare including any problems while trying to upgrade.

P.S still no license files yet :-(

[dakeller]

Stuart,

Thank you for your patience on this matter.  So there are 2 issues being discussed on this thread.  The first is migrating/upgrading to vitrual on 9.1 (or 9.0) from a pre 8.0 release with TAC support.  The other issue is how to get licensing to fulfill an upgrade if you use BAT instead of upgrades to get to 9.0.

A new document has been published to help with the migration from pre-9.x to 9.x.  The document details the paths and steps required to move from any version of CUCM 6.x/7.x/8.x on physical MCS servers to CUCM 9.x on virtual machines.  Although the official document is published on CCO, I have posted a copy of the document in Migration Corner for this community.  The document can be found at https://communities.cisco.com/docs/DOC-32342.  From a TAC perspective, using BAT to export and import is not a supported upgrade path.  There is too much difference between the data export and import requirements to support this migration method.   As such, a manual move of the data and subsequent issues with device associations or dial plan issues will need to be resolved by the installer. 

The other issue is license fulfillment.  I have dicussed this matter with one of the licensing managers and here are the steps required to fulfill licensing if the installer elects to install 9.x as a new install instead of upgrading. 

For a manual migration of their previous licenses into their 9.1 ELM (as in a fresh install):

1. Install any/all unused PAKs
2. Inventory existing licenses
   1. From CUCM System -> License Usage Report
   2. MAC address (License MAC for 8.X from sho status cli)
   3. Run License Count Utility (UCT) (version 2) on old system – must have all users/devices configured and all licenses installed (uploaded status)
3. Open a case with licensing.  Either send an email to licensing@cisco.com or www.cisco.com/tac/caseopen (subject licensing)
   1. Provide SO# of upgrade
   2. Provide license report from UCT showing required licenses and unused DLU allocated to new licenses
   3. Provide ELM license usage report from 9.1 fresh install system (if all users/devices have been fully configured on the fresh installed system)
   4. Provide the ELM Generate License Request (in .txt file as an attachment)

I hope this helps clarify the process for customers to get to CUCM 9.x.  Cisco is looking at other ways to simplfiy the upgrade/migration process for the 10.0 version of CUCM later this year, but for now, this is how you can accomplish what you want to do. 

Thanks,

Dan Keller

Technical Marketing Engineer

[stuart.pannell]

Dan,

That's a great bit of work you have done there and makes the process seem a little easier than what I am currently going through. I will give your process a go and see where we end up. A little dissapointed that BAT is not supported,  I presume that a fresh installation and manually adding the phones is a supported method? Can we not export from 6.1.4 using that BAT format and then import to 9.0 using the format for 9.0? Can't see that moving data from one spreadsheet to another is going to be too hard and using BAT to import phones is generally the method used on a fresh install anyway?

Anyway I will give your licensing method a go and worry about how the phone data gets populated another time :-)

[btmulgrew]

Thanks for this info Dan (and Stuart for highlighting this).

Dan, are you able to clarify on the implications of the statement:

"using BAT to export and import is not a supported upgrade path" please? 

i.e. TAC will not support issues experienced relating to the cutover / migration - but the end cluster will be a supported environment.

Thanks again

Brian

[dakeller]

To all,

Although BAT can export most data from a system, the BAT process does not export all the information from all the records  with all the associations to allow importing into another system.  For this reason, BAT is not a supported upgrade path.

So as an example, if you have exported all the possible data via BAT from a 6.x CUCM version, massaged it into the 9.x format for import, imported as much of the data as you can, but found that the user and phone association was lost, TAC will not support this as an upgrade failure. 

BAT is meant to simplify the importing of data, but not the migration of data.  Often times, BAT required templates to be created prior to importing data.  So phone template or user templates need to be created that may conflict with the exported information from a previous version that will result in a loss of data during the import.  If you are interested in importing phones or users or route patterns, there are other things that must be present for this to work (like CSS's or MRGL or VM Profiles or phone button templates, etc).  Because Cisco has not detailed many of these relationships for BAT, the use of BAT for moving between versions should only be used if there is not other path available or the path to get from the installed version to the target version required more than 3 hops with multiple HW changes.  In the case of a multi-hop install, the amount of upgrade time may be greater than the amount of time to BAT the information over and correct any config that was not correctly associated during the BAT process. 

Bottom line is that the supported upgrade process takes into account all data migration and associations while BAT allows export and import of data that may lose those record associations in the process. 

I will only recommend BAT to a customer as a migration process if there is no other way to migrate.

Thanks,

Dan Keller

Technical Marketing Engineer

[Brian Houston]

Dan

The new document is very useful but I wonder if it could be expaned to include the type of scenario I have at the moment:

Upgrading from UCM 5.1(3) on MCS to UCM 9.1(1) on UCS  - note that Cisco BE6000 has been purchased for the new UCS deployment.

My plan is to use the "Virtualise at Release 8.0 upgrade path" as per your document; I'll have to upgrade from 5.1(3) to 6.1(5) then to 8.0(3) on the MCS before getting to the virtualised stage.

I just wonder if there are any issues given that BE6000 has been purchased for the UCS deployment - or is BE6000 just a bundle of UC applications, including UCM,  that can be upgraded as per the usual rules.

Regards

Brian Houston

[dakeller]

Brian,

There were at least 5 other scenario's we considered for inclusion, but we wanted to make sure the procedures we documented would address most of the upgrade paths.  Since 85% of our customers are on 6.0 and later, we felt the upgrade paths covered would meet that criteria.  Additionally, the method by which we laid out the upgrade path, it is very easy to modify the process to customer specific starting and ending version. 

Looking at your specific starting point, you are in that ~ 3% of our user base that is on 5.x.  We did not include that version in the upgrade path because 1) it's a very small % of the install base and 2) there is no easy path to get to 9.0. 

With that said, here is the challenge a 5.x upgrade will face.  First off, there is no direct path from 5.x to 8.x.  You must upgrade to a 6.x or 7.x to get to 8.x.  So at minimum, you are looking at a 4 step upgrade process to get to 9.0.  Secondly, to minimize the HW impact of the upgrade, you will need to make sure the 6.x or 7.x intermediate version also supports your hardware.  If you have old hardware, you may have to replace hardware before upgrading (add another upgrade step to the process). 

I always hate to be the bearer of bad news, but this is a good example why a customer should keep their installation close to the current release.   Cisco end of saled 5.1 in 2009 and the last day of support for 5.1 was February of 2012.  Just upgrading to 6.x would have greatly simplified the upgrade.  But at this point in time, the upgrade path from 5.x to 9.1 will include the other upgrades that have been deferred over the years. 

Since all the 6.x and 7.x versions of CUCM have been EOS's, you are going to find a hard time to find an upgrade to those versions (aside from the HW support concern).  My recommendation is that if you can find a 6.x or 7.x upgrade and your HW supports that version, at least upgrade to that version, then you can follow the upgrade procedure that we have outlined in the migration document.

In regards to your second question about the BE6K, the answer is yes.  The BE6K is the same installer as the CUCM, but based on the OVA for the VM will install the CUCM as a BE6K install that caps the number of users and devices specific to the BE6K.  But a BE6K is just a number of UC applications that Cisco has validated to run in harmony in the virtual environment.

Thanks,

Dan Keller

Technical Marketing Engineer