Showing results for 
Search instead for 
Did you mean: 

migrate UC apps to new hardware

I have several UCS C220 M3S servers running various Cisco Unified Communications Applications such as Call Manager and Unity Connections. Since the C220 M3S is nearing EOS, we are thinking of migrating to Business Edition 7000M servers. I like to keep all IP addresses the same.  How do we actually migrate the UC apps, all running 11.x on the C220 currently, to the new BE 7000?

VIP Collaborator

DRS Backup and restore during the same maintenance window would be my preferred option. Some might suggest a complete outage, but you should be able to have only a small outage by restoring one at a time.

So the process would be like this:
Setup BE7k, VMWare, etc.
Install fresh CUCM, CUC 11.x (same version, and ES)
- If you dont have the exact build, TAC can provide you with a new copy.
DRS Backup of CUCM, CUC
Power down current CUCM, CUC - Pub Only
DRS Restore onto BE7k CUCM, CUM - Pub
Validate DB replication and service status on cluster
Power down current CUCM, CUC - Sub Only
DRS Restore onto BE7k CUCM, CUM - Sub

Doing it like this takes alot longer than all at once, but I believe it is far safer and less downtime for the user base. If something were to go catastrophic during one step, you lose only a single Pub / Sub - and that can be rectified quickly.

That makes sense Mike.  A few questions -


I plan to have 1 maintenance window per app.  For example, first weekend, down all CUCM nodes on the old hosts and migrate them to the new hosts.  Let CUCM run on the new hosts while the CUC, CER, PLM etc. continue to run on the old hosts for a week.  Second weekend, migrate the CUC.  Third weekend, migrate CER.  Do you see any issues with this approach?


What is the reason for doing DRS backup and restore?  What if I power down all CUCM nodes on the old hosts, copy the OVA and disk image files to the new hosts and start the VMs?


If you plan to move the VMs over I would recommend you to move one at a time. That way you should not get much disturbance to the service.

Moving one service at a time sounds like a good and prudent approach.

Please rate all useful posts

@tachyon05 wrote:

What if I power down all CUCM nodes on the old hosts, copy the OVA and disk image files to the new hosts and start the VMs?

We've done that a few times without issue.  Copy the whole contents of each virtual machine folder.  Or use Vcenter to move the virtual machine.   In one case we had to manually edit the CPU reservation for Unity Connection, there's a Cisco note covering that requirement and giving directions.


Tony makes a great point - if you happen to have the VM's in a Vcenter and potentially a fabric switch - you can Vmotion the machines over in a matter of minutes. I have done this successfully before, but on third party SAN attached hosts. I have never tried on UCS / BE6k / BE7k.

We have done this on UCS SAN attached hosts. Works without issues. VMware should likely behave the same for this independent of the hardware.

Please rate all useful posts


Most of the UC applications support VMware vMotion and Copy VM features. 

Please remember, the following applies to any use of vMotion with UC apps:

  • Prior to ESXi 5.1, VM must be installed on shared storage (SAN) and source and destination physical servers must be connected to same SAN. In ESXi 5.1+ vMotion allows "DAS to DAS", i.e. VM can be installed on DAS and source/destination physical servers can have different DAS yet still vMotion the VM.
  • Destination physical server must not end up with over-subscribed hardware after the migration. Supported capacity and co-residency rules for UC must be followed before and after the migration.
  • VMware "Long Distance vMotion" (site to site) is not supported.
  • The only supported scenario is a manual move to a different server, e.g. for planned maintenance on the server or VMware software, or during troubleshooting to move software off of a physical server having issues.
  • For real-time load-balancing of live UC VMs (e.g. via Distributed Resource Scheduler [DRS]), a few applications have caveated support ; otherwise it is not supported.
  • Moving a shut down VM during a maintenance window, i.e. a "cold migration" or "host to host migration", is not vMotion and is supported.

You can go though below URL to know more about these two features before using it: 



Please rate helpful posts and if applicable mark "Accept as a Solution".
Thanks, Vaijanath S.

Thanks everyone for all the input. We don't have SAN or vCenter, so it looks like Tony's method would be the easiest where I copy all files from the VM's folder from the old to the new server.  I will give this a try after we get the new hardware.


You can setup 60-day trial vCenter server for the migration (vMotion) purpose and delete it later once the activity is completed. But make sure you have the correct EXSi licenses on your existing and new UCS server that supports vMotion feature. 

Check the License Comparison table in below URL: 



Please rate helpful posts and if applicable mark "Accept as a Solution".
Thanks, Vaijanath S.

Vcenter needs an eligible VMware edition on the host that you want to manage.  On a new host you can temporarily enable all features, on a trial basis, by removing the licence key.  However I'm pretty sure the trial period is 60 days from initial install of the host, so if I'm right this couldn't be done on one that's been in service for a while.

It works perfectly well copying the VM folder.  We've even done it by copying to a USB drive and shipping that to site.