Upgrading from CUCM 7.1.2.31900-1 to 8.5.1.10000-26

I have been asked to put together a brief outline of tasks required to achieve an upgrade CUCM from 7.1.2.31900-1 to 8.5.1.10000-26. I have read pretty much everything that I can find from Cisco and have put together a brief list of tasks that will be required. I was hoping one of you genius's would cast a quick eye over my list and see if you can spot anything I may have missed please ?

Observations:

There does not appear to be a direct upgrade path for the call manager from version

7.1.2.31900-1 to either 8.5x or 8.6x.Would need to go to 7.1.(3b)SU2 first.

Prerequisites:

Ensure we have the relevant software feature License prior to upgrade to 8.5Ensure we have correct versions of ISO Files ready.

Thanks both of you for your time and comments. Very usefull. Do you think it would be advisable to do the upgrade to CUCCM 7.1.(3b)SU2 on a seperate occasion, again to lighten the load on the 8.5 upgrade evening / weekend ? We do have CUCCX 7.0(1)SR5_Build504, and I believe that this is compatible with CUCM 71.1(3b)SU2 anyway.

The only criticism I might have is the test periods you have in between the PUB and SUB switchovers. Since the Applications are running distinct versions at that point, you might find some inconsistencies and weird behaviour with your testing at that point, but it can depend on what you are actually thinking for your test best.

I would roll out a large set of test once both servers have been migrated to the new version, and then give myself a Window for roll back. I would not actively troubleshoot anything weird that might show up in 7.1.3 as we are just passing by it, without intention to stay.

Finally keep in mind your Jtapi Client!!, You might need to do a Resync in your UCCX if the Jtapi client happen to upgrade revision between your 7.1,2 and 7.1..3 CUCM.

The only criticism I might have is the test periods you have in between the PUB and SUB switchovers. Since the Applications are running distinct versions at that point, you might find some inconsistencies and weird behaviour with your testing at that point

BIt of an understatement ;-)

With the PUB & SUB on different versions of software, they ain't gonna be talking to each other. You want to minimise the time spent with the cluster in this state, so I wouldn't have much testing in there. The only "test" I'd have, is making sure the PUB comes up cleanly on the new version of software. As soon as it's up, get that SUB switching versions.

Also, that backup you've got scheduled between the PUB & SUB switches will only work for the PUB. I'd skip this entirely. At this stage, you shouldn't be making any DB changes to your system, so a backup is not needed.

If I'm reading your agena correctly, you're going to install the software on the SUB after you've switched versions on the PUB. I'd change this and do the SUB install as soon as the PUB install has finished. Then once both installs have finished, you can do the switch version on the PUB, followed by the SUB.

A small suggestion: After you've done the switch version on the PUB, use RTMT to monitor the PUB's CPU utilisation. Once the utilisation drops to normal, then switch version on the SUB.