CUCM Upgrade Strategy or Approaches...

[nelson.chu]

Hi,

I am looking for an upgrade strategy or ideas (ccm 4.2 to cucm 7.1).  There are (2) clusters with 15K phones per cluster. These phones are spread out over 200 sites, some large (>2000 phones) and some small (<20 phones). So far, we have discussed about two approaches: phased migration or flash cut.  We are leaning towards a phased migration, but will require building seperate CUCM cluster and Unity.  Does anyone have any ideas for minimizing downtime, risks, and hardware???

Thanks,

Nelson

[testeven · Accepted solution]

Hi Nelson,

When upgrading a CUCM server from a Windows based to a Linux based
version it's better if you have new hardware and build parallel servers.
This will give you a minimal impact, besides, probably the servers you
currently have are not supported in later CUCM versions or are quite old.

First of all, you need to check the correct upgrade path and if the servers
you have are supported on the new CUCM version.

You can check this on the documents below:

*** Cisco Unified Communications Manager Software Compatibility Matrix ***

http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/compat/ccmcompmatr.html

*** Supported Cisco Unified Communications Manager Releases by Server ***

http://www.cisco.com/en/US/prod/collateral/voicesw/ps6790/ps5748/ps378/prod_brochure0900aecd8062a4f9.html

For a minimal upgrade downtime, you can take a BARS backup from the 4.X version and install it on a
new server so you can recreate the production system. Then run the DMA process (multiple times if
necessary to get a clean output) and install 7.1.X (or later) on this server.

Afterwards you need to run extensive tests in the lab to verify all features and functionality work
as desired. You can also test customized applications along with all the Cisco applications that
would touch this cluster. Once everything looks good, you can take the new 7.1 server and place it in
the data centers, connect it to the network with the switch port shut down.

The night of the cutover just disable the switch ports for the production 4.X server, enable the switch ports

for the 7.1 server, reboot the cluster and start your test plan.

Then validate replication, enabled NTP, and DNS if used and that's it! This process is usually used for big

clusters with a large number of users.

Sometimes having the luxury of building out and testing in the Lab outweighs the cost of the new servers.

And with this, you will also have an instant roll back option if you run into any issue and you reduce business impact.

Usually when talking about large clusters, engineers spend months aggressively testing 7.1 in a Lab as well

as a small user acceptance cluster. This testing helps ensure the migration is successful.

HTH!

Regards,

Teresa.

[nelson.chu]

Hi Teresa,

This helps a lot!

Thanks,

Nelson

[Chris Lee · Accepted solution]

Another thing to be aware of...

I'd recommend confirming the firmware of all your IP Phones is compatible with the UCM version you are upgrading to prior to upgrading. That way, after upgrading, you won't have IP phones sitting out there "unregistered" and you're wondering what happened to them after the upgrade.

Good luck.

[nelson.chu]

Chris,

We plan to upgrade the firmware on the phones before cutting them over to CUCM 7.1. From the Cisco documentation, the firmware should be backward compatible to CCM 4.2.

Thanks,

Nelson