08-28-2019 01:25 AM
Hello all,
On of our customers has a BE6K based on an older C220. They ordered a new C220 and they want to migrate/upgrade to 12.x. This job can be done with PCD and if I look at the Cisco Live presentation slides the current cluster will be down while PCD migrates the old version to the new hardware and software (for the same amount of time it takes aprox. to install a full cucm). Is this correct ?
The customer has a pretty simple setup (1 cucm pub + sub, 1 IMP pub) and we have to option to upgrade during off-hours.
Or is it better to deploy 10.5 on the new hardware and do a straight upgrade to 12.x and then switchover to the versions running on the new hardware to minimize downtime ?
with kind regards,
Marcel Tempelman.
08-29-2019 12:43 AM
Recently we migrated CUCM 10.5 to 11.5 using PCD (1pub + 2sub) which took about 2 hours. It may vary based on configuration and devices on the cluster.
08-29-2019 12:48 AM - edited 08-29-2019 12:50 AM
Bonus information :-)
If you decide to perform migration using PCD and then if the DRF backups fail, you may be hitting below defect, though CUCM 12.x is listed under fixed versions:
https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvf63806/?reffering_site=dumpcr
08-29-2019 05:49 AM
Hi,
When you perform migration using PCD, the existing CUCM cluster will not go down at once. Your phones will work even if PCD performs the migration. PCD performs the migration tasks one at a time.
Please refer to below videos for more details.
https://www.youtube.com/watch?time_continue=393&v=nMrS0hMES7A
https://www.youtube.com/watch?v=Kd7dvvP103E
01-31-2021 06:19 PM
Is the UFF copied after each server is migrated and the source shutdown? Or is the database/UFF copied at the end of the migration? I seem to remember a comment somewhere saying that once the last source server is down, all phones are down until the final server is completed and the UFF is copied to the new cluster? Effectively, causing a total outage while this process completes?
08-29-2019 07:03 AM
That will depend on what you're doing, if you're using the NAT option and migrating to an isolated network, there is no need for the source servers to be shutdown.
If you're keeping the same network info, and placing the new servers in the same network, then the source servers need to be shutdown to avoid network issues.
Yes, the time it will take is a bit more of a usual install as it also needs to transfer the data, how long it takes depends on HW and amount of data to transfer.
If you don't want the source servers to be shutdown, then you can just DRS into an isolated network and then perform the upgrade there.
08-29-2019 01:07 PM
If you don't want the source servers to be shutdown, then you can just DRS into an isolated network and then perform the upgrade there.
This is the method I always use whenever I'm concerned about down time. Using this method, if you run into any issues during the upgrade you can take care of them in an isolated environment rather than on the customer's production environment (much less stressful of course). To make it go even faster, I always upgrade the phones' firmware in the production environment ahead of time as well to match that of the upgraded CUCM. Using this method, the cutover simply consists of disabling the NICs on the "old" servers, and putting the "new" servers into to production VLAN. Cutover time is less than 2 minutes usually.
01-31-2021 06:09 PM - edited 01-31-2021 06:11 PM
But if what Vaijanath has stated above is true, then technically, there is no downtime if phones re-register back to their primary sub/pub (now running the new version), as the migration continues thru the cluster,correct? Should the migration fail, simply turning off the failed migration cluster and starting the old one would be the "DRS" method in this sort of migration?
Note: this assumes the latest phone firmware is installed so phones do not have to rollback.
08-29-2019 01:44 PM
Thank you all for the great replies. I get a feeling what to expect. Most migrations I did up till now where 'start over' migrations (starting all over with a new configuration). I guess I will use the DRS option because that does not touch the production directly but I will have to discuss this with the customer.
With kind regards,
Marcel Tempelman.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide