We have a plan to migrate the exiting Call manager and unity cluster from a physical server to virtual servers. The current version 9.x.
We want to make sure to have a minimum downtime. The plan is to create the same version of the cucm & cuc servers on the VM with the different IP address.
Now I need to export and import the whole Cucm and unity configuration from production servers to new VM lab servers. I saw there is an option available in cucm import/export. Can I do import complete CUCM configuration in this way. Is there any direct export/import feature available for Cisco Unity connection.
Kindly help me with this
You need to perform DRS back up and restore to achieve your requirement.
Here is a good document to go with:
Thanks for your reply. The new CUCM server has the difference IP address, will DRS backup and restore work on this case?
Here is the prerequisite from the document that i shared:
Before you restore Cisco Unified Communications Manager, ensure that the hostname, IP address, DNS configuration, and deployment type of the restore matches the hostname, IP address, DNS configuration, and deployment type of the backup file that you want to restore. DRS does not restore across different hostnames, IP addresses, DNS configurations, and deployment types.
You can put new CUCM in isolated / different network, have DRS restored and then change IP address and host name as required.
Thanks for the details
Even if the call manager on a different/isolated network, the IP address cannot be the same, so how can I restore the DRS?
Is there any way I can import the complete configuration other than DRS?
There are ways to import / export various configuration, but you need to plan very well; personally I would not suggest that. The best way to have identical configuration is DRS restore.
Creating an isolated network is challenging, but not impossible. We had done this way to prepare our new environment. Or you need to have a downtime window to keep production servers shut, install new servers, restore DRS, change IP address and bring back up production servers. However, if you make any further changes on your existing cluster, those changes will not be replicated to your new cluster and you need to do them manually. So you need to do this activity as close to cut over window or keep track of all changes and have them done on new cluster manually.
There are many options, permutations to take care about, so carefully choose what best suits you.