Migration of UC Cluster with New IP Schema to New Data Center

[Mr.dchauhan1]

Hi Team,

We are Planning to Migrate one of our Customers CUCM Cluster,IM&Presence, CUC (Pub and SUB)  and UCCX( Pub and SUB) to New Data centre with New IP address and all UC application upgraded to 11.5 version.

CUCM Cluster 4 nodes(Version 9.1.2 )
CUC( Version 9.1.1)

UCCX( Version 9.0)

I am planning to use PCD to Migrate CUCM Cluster.

Before I go into Planning I have some queries.

1. What Could be the best approach for doing this entire Migration since I do not want to Impact the Production environment untill the New DC UC Infra is up, Tested and ready to ready to go live.

2. How I can plan for Migrating the UCCX and CUC to new DC with New IP bcz I think i can't use the PCD tool for migrating and upgrading UCCX and CUC.

3. While Migrating CUCM Cluster via PCD to New DC. Can we just let the IP phones and other endpoints to be active on the OLD cluster and run the new CUCM cluster in parllel and  once we are ready to switch to new Cluster(  other application (UCCX, CUC) are up and running we jst migrate the Phones.?

3. Any Risk and challenges if anyone can highlight..?

[Jonathan Unger]

The following breakdown is my opinion and without deep knowledge of your existing environment I have to make a lot of assumptions. Do not attempt a migration of this nature without careful planning and consideration:

1. CUCM/IM&P - PCD should work well for this, upgrade and migrate the hosts to the new version and new IP addressing.
   
   
2. Unity - Build the new cluster manually on the new version, then use COBRAS  to migrate the data (if you have not used COBRAS before, you will need to thoroughly read the documentation since it does not move ALL data, some components need to be rebuilt manually like the UCM integration, Class of Service, etc...).
   
   
3. UCCX - There are a couple ways to approach this one:
   1. "Copy method" - Shut down both UCCX VMs and copy the VM files from the datastore. Import the "copied" VMs into the ESXi inventory, ensure that you place them on an isolated network, otherwise when they are booted up you are going to have IP conflicts with your existing UCCX servers, and you will have a really bad day. After you have the nodes booted up in an isolated environment you can change the IP addressing and change the IP addresses UCCX points at for the CUCM integration.
   2. DRS restore method - Takes longer than the copy method since you need to manually rebuild the UCCX nodes and restore backups to them from the productions servers. However the advantage to this method is that you do not need to shut down the production UCCX servers. Again, make sure you do this in an ISOLATED network environment, or you will break your production systems.
   3. Please be aware that the CAD client can no longer be used on UCCX 11.X, you will need to migrate everything over to the Finesse client. UCCX 10.6(1) is the last version (I think) that supports CAD and Finesse at the same time.

When doing these types of parallel migrations you need to always be paranoid about affecting production systems. This means you need to be absolutely clear on the design and configuration of the existing UC environment. Really think hard about not only the core UC apps (CUCM, IM&P, CUC, UCCX), but also consider if there are 3rd party applications which integrate with the existing environment: call recording, CRM systems, call accounting/billing, attendant console, etc...

This will not be an easy migration, it requires a ton of careful planning and hours of reading documentation. If you need some further assurance for the upgrades/migrations you can open a TAC case on each product and they can help vet your migration plan. Alternatively you can engage a Cisco partner to assist as well.

In my opinion, parallel upgrades are much more work, however when planned properly they carry much less risk to the customer since the new environment can be fully tested in advance of the cut over.

To answer your questions about the cut over to the new version:

• Yes you can leave the phones on the old cluster until the cut over. Ideally during the cut over window you would just be moving over voice gateways and phones to the new cluster, then executing your final test plan.
• I would suggest doing a certificate exchange between the new cluster and the old cluster, this will prevent the phones from having ITL trust issues when moving back and forth between the old and the new clusters. Check out this article on bulk certificate management for more info
  https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/pcdadmin/10_5_1/CUCM_BK_U35347D2_00_pcd-administration-guide-1051/CUCM_BK_U35347D2_00_ucmap-administration-guide-1051_chapter_0110.html

Hope this helps!

- Jon

[Mr.dchauhan1]

Thanks Jon for the detail advise. but my query on the following points.

1. UCCX Migration

a) "Copy Method" is this a Long distance VMotion. or OVF? Copy the VM and moving it to new data centre there should not be a IP conflict because the existing UCCX Subnet does not exist in New DC so I can Boot-up and should be able to change the IP and hostname at VM level and then access the UCCX application remotely. But does this COPY and Move of UCCX will not cause any database issues(Has this option been tested) bcz the recommended is do by DRS Method.

While doing copy can we shutdown the one node and fallback all the agent and services on secondary   UCCX node and then bring the Primary node up and then start copying the second node.?

Any other Impact on the UCCX server while doing COPY..?

[Jonathan Unger]

I have used the copy method successfully in the past where we needed to move and change the IP address of a UCCX node in an HA environment. We did not have vCenter in that case so the files were copied manually via SCP to a new server.

In your situation it might be better to go with the "officially" supported DRS method. This would allow you to keep the existing production servers online the whole time.

Something to be careful of is to not let the DRS restored UCCX nodes onto the network where they could communicate with the old UCM servers until you have changed the UCCX server IP addresses and the UCM integration IPs on UCCX. If you fail to do this then the "new" UCCX servers will attempt to register via CTI with the old UCM cluster and you will have issues where callers can not reach your production queues.