1.4 Cisco Unified CM Cluster Upgrade Process
Key Takeaways
Unified CM supports Direct Standard Upgrades (application only, same OS) and Direct Refresh Upgrades (application plus OS), with fresh installs with data import or PCD migrations when no direct path exists.
New software installs into the inactive partition while the active release keeps running; switching versions reboots the node into the new release, and switching back is the rollback path.
The publisher is upgraded first; subscribers may start once the publisher has the inactive version, but the publisher must switch and reboot before any subscriber switches.
Subscribers switch in groups that keep each phone's backup subscriber up, with a wait for database replication after each group, and IM and Presence nodes switch only after the Unified CM nodes.
Before upgrading, run the upgrade readiness COP file, take a DRS backup, and confirm replication status 2; Cisco budgets 2 to 4 hours for the publisher install, plus an hour for a refresh upgrade.
1.4 Cisco Unified CM Cluster Upgrade Process
Blueprint objective 1.3 asks you to describe the cluster upgrade process for Communications Manager. A CUCM upgrade is not a single action: every node in the cluster must move to the new release in a fixed order, because the publisher owns the master database and every subscriber replicates from it. Questions usually test the upgrade types, the two-partition model, and the sequencing rules, so learn those three ideas first.
1. Upgrade Types
| Upgrade type | What changes | Example | Typical tools |
|---|---|---|---|
| Direct Standard Upgrade | The application only; the underlying operating system stays the same | 12.5 SU2 to 12.5 SU3 | Cisco Unified OS Administration, the CLI (utils system upgrade), or a Cisco Prime Collaboration Deployment (PCD) upgrade task |
| Direct Refresh Upgrade | Both the application and the underlying operating system | 11.5 to 14 | The same tools |
| Fresh install with data import | A new installation that imports data exported from the old cluster | Moving to a release with no supported direct path | The installer with an export from the old cluster |
| PCD migration (V2V) | PCD builds new virtual machines and migrates the cluster to them | Platform refresh with optional address changes | Cisco Prime Collaboration Deployment |
A standard upgrade is the simplest and least disruptive. A refresh upgrade takes longer: Cisco's upgrade guide adds about an hour to the publisher install time, the node's web interface is unavailable during the upgrade, and phones registered to a subscriber that is being refresh-upgraded go unregistered unless they have a backup subscriber. Direct and refresh upgrades from releases older than 12.5 to Release 15 are not supported, so such clusters first move to 12.5 or 14.
2. The Two-Partition Model
Every CUCM node has an active partition (the running release) and an inactive partition:
- An upgrade installs the new release into the inactive partition. With a standard upgrade, the old release keeps running and processing calls while the install happens, which is why administrators often install during the day and switch at night.
- Switching versions reboots the node into the partition that holds the new release; the previous release stays in the other partition.
- Rollback means switching back to the partition with the old release. It works only while the old release is still present, and the cluster must be switched back in the same publisher-first order.
Because the release in each partition is visible, a quick check before a maintenance window is to confirm that every node shows the target release as its inactive version.
3. Sequencing Rules
Cisco's Release 15 upgrade guide states the rules this way:
- Publisher first: The Unified CM publisher must be the first node upgraded. The new software is installed as an inactive version.
- Subscribers next, in parallel if you wish: Subscribers can begin their upgrade as soon as the publisher has the new inactive version installed.
- Switch the publisher first: The publisher must switch to the new version and reboot before any subscriber switches.
- Switch subscribers in groups and wait for replication: After each group of subscribers switches and reboots, wait for database replication to complete before moving on. Choose groups so that every phone's backup subscriber stays up while its primary reboots.
- IM and Presence after Unified CM: The IM and Presence database publisher can be upgraded to an inactive version once the Unified CM publisher has its inactive version (even in parallel with the Unified CM subscribers), but IM and Presence nodes switch versions only after the Unified CM nodes have switched, publisher first and then subscribers.
| Task (Cisco planning estimate) | Minimum time | Service impact |
|---|---|---|
| Upgrade the publisher to an inactive version | 2 to 4 hours (add 1 hour for a refresh upgrade) | Refresh upgrades: no access to the web interface |
| Upgrade each subscriber to an inactive version | 1 to 2 hours | Refresh upgrades: phones unavailable if they have no backup subscriber |
| Switch the publisher and reboot | 30 minutes | Administration unavailable during the reboot |
| Switch each subscriber and reboot | 30 minutes | Phones fail over to their backup subscriber |
| Database replication after switching | Varies with cluster size | Wait for status 2 before continuing |
4. Before and After the Upgrade
Before:
- Read the release notes and the compatibility matrix for phones, Unity Connection, Expressway, Emergency Responder, and third-party applications that use AXL, CTI, or SIP.
- Confirm the upgrade path, licensing readiness (Smart Licensing), and that the virtual machines meet the target release's OVA requirements.
- Run Cisco's pre-upgrade readiness COP file on the cluster and fix what it reports. Some older sources also need a signing-key COP file; for example, a Unified CM source older than 12.5.1.14900-63 must install
ciscocm.enable-sha512sum-2021-signing-key-v1.0.cop.sgnbefore upgrading to 15. - Take a Disaster Recovery System backup of the cluster (Section 1.3).
- Verify health:
utils dbreplication runtimestateshould show status 2 on every node, and NTP and DNS must be working.
After:
- Run the post-upgrade checks, confirm that services are running, and recheck replication.
- Compare the registered device counts in RTMT with the pre-upgrade numbers; phones may download new firmware loads after the switch, which briefly delays registration.
- Take a fresh DRS backup of the new release.
5. Cluster-Wide Options and Automation
Recent releases add cluster-level pages to Cisco Unified OS Administration on the publisher, Software Installation and Upgrade Cluster and Restart/Switch-Version Cluster, which install and switch every node while applying the sequencing rules for you. Cisco Prime Collaboration Deployment can schedule upgrade, switch-version, and restart tasks across several clusters, and Cloud-Connected UC (Section 10.1) can plan and run upgrades from Control Hub. Whatever the tool, the same publisher-first order applies.
6. Worked Scenario
A cluster has a publisher, four call-processing subscribers in two pairs (Sub1/Sub2 and Sub3/Sub4, each the backup of the other), and an IM and Presence publisher and subscriber. The upgrade is a standard upgrade:
- Day 1 (no outage): Install the new release as inactive on the publisher. When it finishes, install on all four subscribers in parallel, then on the IM and Presence publisher and subscriber.
- Maintenance window: Switch the publisher and wait for it to come up. Switch Sub2 and Sub4; their phones fail over to Sub1 and Sub3. Wait for replication to report status 2. Switch Sub1 and Sub3; phones move to Sub2 and Sub4. Wait for replication again.
- IM and Presence: Switch the IM and Presence publisher, then the subscriber.
- Verify: Check replication, registrations, and services, and take a DRS backup.
During a Cisco Unified CM upgrade, every node already has the new release installed in its inactive partition. In which order should the administrator switch versions?
Switch all subscribers first so that the publisher can copy their databases, then switch the publisher, then the IM and Presence nodes.
Switch and reboot the Unified CM publisher, then switch the subscribers in groups once replication is set up, and switch IM and Presence last.
Switch every node at the same moment so that the cluster never runs two releases at once and replication never has to resynchronize.
Switch the IM and Presence publisher first so that presence stays available, then the Unified CM publisher, then the Unified CM subscribers.
What is the key difference between a Direct Standard Upgrade and a Direct Refresh Upgrade of Cisco Unified CM?
A standard upgrade requires Cisco Prime Collaboration Deployment, while a refresh upgrade can be run only from the platform CLI of each node.
A refresh upgrade also replaces the underlying operating system and makes the node unavailable while it runs; a standard upgrade keeps the same OS.
A standard upgrade changes the operating system, while a refresh upgrade changes only the database schema and leaves the OS untouched.
A standard upgrade reinstalls the cluster from scratch and imports exported data, while a refresh upgrade only applies a COP file to the active partition.
An engineer is preparing for a Unified CM upgrade next week. Which preparation best protects the cluster if the upgrade fails?
Delete the inactive partition on every node to free disk space for the new release before the upgrade window starts.
Disable database replication on all subscribers so that a failed node cannot copy bad data to the others.
Switch every phone to SCCP so that it can register to either release while the cluster is partway through the upgrade and replication is down.
Run the upgrade readiness COP file, take a DRS backup, and confirm that utils dbreplication runtimestate shows status 2 on every node.
Sections you finish are checked off in the contents.