Migrate 10.5 to 12.x expected downtime (BE6K)

[Marcel Tempelman]

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.

[piyush aghera]

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.

[piyush aghera]

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

[Vaijanath Sonvane]

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.

1. It will try to migrate CUCM Publisher database from old server to new server. The phones that are registered to old CUCM Publisher will register to CUCM Subscriber. During this time old CUCM subscriber is up and running and all the phones registered to subscriber will work fine.
2. Once PCD successfully completes CUCM Publisher migration, it will shut down old CUCM Publisher.
3. PCD then proceed with CUCM Subscriber migration. The phones that are registered to old CUCM Subscriber will register to new CUCM Publisher and all the phones registered to it will work fine.
4. Once PCD successfully completes CUCM Subscriber migration, it will shut down old CUCM Subscriber.
5. Your new CUCM cluster is back to normal operation.

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

[john.f.spencer]

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? 

[Jaime Valencia]

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.

[mikeleebrla]

---

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.

[john.f.spencer]

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. 

[Marcel Tempelman]

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.