cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
4083
Views
41
Helpful
40
Replies

CUCM migration from 11.0 to 14

jaheshkhan
Level 4
Level 4

What is the best way to migrate from 11.0 to 14.

 

Since there was no existing contract we can only build new cluster and migrate the data from cucm 11 cluster to new cucm 14 cluster..

 

what all things to consider in this case?

do we need to use new IP for new cucm 14 cluster?

in this case can we backup data from CUCM 11 and restore to NEW CUCM 14 cluster? Doing so we will get all our phones another configuration data to new cluster.

is this possible?

 

for the phones to get register to new cluster what we need to do? I think we will face certificate issue ? we have 600 phones .. how we can overcome this issue as well?

 

 

40 Replies 40

PCD comes along with the BE, you just need to configure the IP. 

 

The best part is you can schedule the migrations. 



Response Signature


Install PCD on your new server, discover the old cluster.  schedule the migrate task. Migrate CUCM and IM from your OLD m3  to the new M5 server. 

 

Make sure you need  read all  Guides  JAVA mentioned. 

 

Phones will register with the new call manger. I Never faced any issues with PCD migrations. 

 

 



Response Signature


ra 011
Level 1
Level 1

I'd like to add to the above that Fresh install with data import also will takecare of certificates , CTL , ITL also and will be moved to the new CUCM 14v Cluster without any issue in registration with Mixed mode or ITL secure by default

If you are chaining the IP address, you must exchange the certificates. If not the phones will fail to register with the new CUCM.

You can remove the ITL certificates by "Prepare Cluster for Rollback to Pre-8.0" or manually removing it by some third party tools.

 

I would suggest to use PCD and it avoid the manual process of data export. And PCD can migrate to same IP or different IP.

If you are using different IP, PCD will force Pause to complete the certificate exchange.

 

In data export option you are not making a backup. Backup restore is a different process. Even you export data you must exchange the certificates for the phones to trust new cluster.



Response Signature


Faisal Saoud
Level 1
Level 1

@Nithin Eluvathingal  I have a project migration from 11.5 to 14, but I have 4 BE7K which is two UCS in the same location and the other two in different locations connected through WAN. In addition has multiple CUCM nodes around these servers.

I read in your comments that you support the PCD option but I have some concerns:

- Do I have to install PCD on the server that has CUCM publisher or do I have to install the PCD on every hardware?

- If I have to install one PCD, will the iso file be transferred to the remote subscribers when upgrade them, that means it will take much time for this transfer.

- If you have an implementation plan for this way, I appreciate to share it with me.

PCD is a standalone application. You can install it on any ESXi host that has access to your network so it can reach the UC systems you have. You only need one PCD if it has access to all of your CVOS systems.



Response Signature


Thanks, @Roger Kallberg, but If I upload the upgrade media to one PCD, it will take time when I go through upgrading the remote subscribers over WAN, I am asking if I can install PCD on each site and upgrade each site by the local PCD.

I see, that was not really apparent in your other post. You don’t need to have the update media on PCD, you can put it onto a SFTP server locally to the server node being updated and then configure in PCD what each cluster node should get their upgrade media from.



Response Signature


@Roger Kallberg  Do you mean I can connect to the PCD with multiple SFTP servers at each location and enable each location to get the ISO file locally? or doing it site by site, running SFTP at the main site, and starting migrating the nodes, when it comes to the first remote site, I run SFTP there at the remote site to migrate their nodes.

your advice @Nithin Eluvathingal 

Another alternative would be to perform a fresh installation with data export. In this scenario, you could set up an SFTP locally at each site and use it to store the exported data.



Response Signature


Thank you @Nithin Eluvathingal, for your support, but in this way, Can I change the IPs at the new cluster, and will the phones register directly without any physical intervention?

With this option, you can modify the IP. Once the new servers are operational, you’ll need to manage the certificates in bulk to ensure a smooth transition of the phone from the old to the new servers.

Even if you choose the PCD option with a new IP, the PCD process will pause at the final step, allowing us to perform the Bulk Certificate Management.

https://www.cisco.com/c/en/us/support/docs/unified-communications/unified-communications-manager-callmanager/215539-procedure-for-bulk-certificate-managemen.html

 



Response Signature


I mean the first of what you wrote. However I have no idea on how, or even if, this operates for migrations in PCD as I’ve never done that type of task in PCD myself. It does work for upgrades, we do this for our SME that has one cluster node in each of our 3 DCs. Each SME node gets the upgrade image from a locally located SFTP server.



Response Signature


 

In my opinion, the optimal solution for this situation would be a fresh installation with data export data export.Install the provided COP on all nodes, export the data, and store it on an SFTP. For the nodes at the headquarters, keep the files on an SFTP located at the HQ. For the nodes at the branch, store the exported data on a local SFTP at the site. Utilize this data during the installation of the nodes.

NithinEluvathingal_0-1716729075951.png

 



Response Signature


PCD can absolutely use other SFTP servers. We use one PCD located at one of our 3 DCs that uses locally sourced SFTP data storage.

image.pngimage.pngimage.pngWith this we can then use one centralised PCD to upgrade any of our systems in each DC without pushing data across the WAN.



Response Signature