cisco onprem uc · published

Unified CM backup and upgrade

Verified 2026-09-24 · 60 sources · tier 2

Also known as Clusterwide Upgrade, DRS backup, Disaster Recovery System, direct refresh upgrade, direct standard upgrade, pre-upgrade-check COP file, switch version.

Cisco Unified Communications Manager (Unified CM) upgrades and backups rely on structured pre-upgrade validation, the Disaster Recovery System (DRS), and version-switching mechanisms 352059. Destination versions such as Release 15 dictate specific upgrade types, hypervisor requirements, and operational sequencing across cluster nodes 316023.

Upgrade Types and Paths

A direct standard upgrade upgrades the application software but not the underlying operating system 56. In contrast, a direct refresh upgrade upgrades both the application software and the underlying operating system 38. For Unified CM and IM and Presence Service Release 15 and later, there are no supported Direct Refresh Upgrade paths 31.

A direct standard upgrade to Release 15 is supported from Unified CM Release 12.5 and from Release 14 and its SUs 9. However, an upgrade from Release 14SU4 to a destination version lower than Release 15SU2 is not supported 1. For legacy systems running Unified CM 7.0(1) and older, migration to Release 15 is not supported, and Cisco recommends rebuilding on the latest release from scratch 27.

Every supported path to Release 15 that uses the Prime Collaboration Deployment (PCD) Upgrade Task or PCD Migration Task must use PCD Release 15 33.

Pre-Upgrade Requirements

Upgrading requires at least 25G of free space on the common partition 5. In addition, the partition must have no expired certificates, including trust certificates 30.

Every supported upgrade path to Release 15 in the compatibility matrix requires running the pre-upgrade-check COP file first 35. After this COP file is installed, its report can be viewed from the CLI using file view install PreUpgradeReport.txt 36. Cisco also strongly recommends running the upgrade readiness COP file prior to upgrading to reduce the chance of upgrade failure 37.

Additional administrative preparation includes:

Taking a fresh Disaster Recovery System backup, as an outdated backup can cause data loss or make the system impossible to restore 20.
Separately backing up custom ringtones and background images, which are not included in system backups 47.
Recording the registered device count with RTMT so endpoints can be checked after the upgrade 48.
Setting up a Customer Smart Account and creating a Virtual Account for Smart Licensing 52.

Upgrade Execution and Version Switching

Upgrade software can be loaded from DVD/CD, from the local filesystem, or from an SFTP server whose directory, address, and credentials are supplied by the administrator 58. The SFTP server bundled with PCD is the only SFTP server Cisco provides, tests, and fully supports through TAC; third-party SFTP servers are not officially supported by TAC 49. The Clusterwide Upgrade option is available only for direct standard upgrades where the pre-upgrade version is at least 12.5(1) 4.

Cisco defines version switching as installing the new version as an inactive version, then switching to it and reverting to the old version whenever the administrator chooses 59. During an upgrade, the administrator can select an option to switch to the new version automatically upon completion, though the default is not to switch automatically 2. Version switching is supported for direct standard upgrades, but it is not supported for migrations such as the PCD Migration Task 32. WarmTransfer's reading of the sources is that a cluster on 11.5 or earlier cannot use version switching to revert if a move to Release 15 fails, because its only paths to 15 are migrations or a fresh install 25.

When switching versions in a deployment with IM and Presence Service nodes, the Unified CM nodes must be switched first: the publisher, followed by the subscribers 23. If this switch order is not followed, some Software Upgrades menu pages will not display or work for the IM and Presence nodes 22.

If reverting a cluster to the previous version, switch back the publisher first, then all backup subscriber nodes, and finally all primary subscriber nodes 57. After reverting, database replication must be reset manually via the CLI command utils dbreplication reset all 46.

Disaster Recovery System Backups

DRS requires all cluster nodes to run the same version 17. Backups should be stored on a network device, as virtualized deployments do not support tape drives 14. DRS supports up to 10 backup devices 10. For network backup devices, the "Number of backups to store on Network Directory" setting controls how many backup sets are retained 16. Backups sent to a remote server that do not finish within 20 hours will time out 11.

DRS encrypts backup files with a randomly generated password, which is encrypted using the cluster security password 13. The cluster security password in effect at backup time is required to restore the files 13.

No OS Administration tasks should be performed while a backup is running because DRS locks the platform API and blocks OS Administration requests 15. DRS operations can also be driven from the CLI using the utils disaster_recovery command family, which includes device add network, backup network, status backup, and schedule add and enable 12.

DRS Restore Procedures

A DRS restore requires the target server's IP address, hostname, DNS configuration, and deployment type to match the values stored in the backup file 42. It also requires the version saved in the backup file to match the version running on the nodes, including the full version string with service updates 45. WarmTransfer's reading of the sources is that a DRS backup taken prior to an upgrade cannot be restored onto a cluster that has switched to the new version; restoring it requires a node on the exact pre-upgrade version 26. If the cluster security password changed after the backup was created, the restore fails unless the old password is available 43.

During cluster restoration, the publisher (first node) must be restored before subscriber nodes, and it must be restarted before subsequent nodes 44. Depending on the database size and selected components, a restore can take a few hours, and database replication after restarting subsequent nodes may take several hours depending on cluster size 41. After restoration, replication should be verified on every node with utils dbreplication runtimestate; the Replication Status value should be 2 on each node 40.

Licensing Considerations

In Unified CM Release 12.0(1) and later, Cisco Smart Software Licensing replaces Prime License Manager (PLM) 54. In older PLM 11.5(1) deployments, license migration applied when upgrading an instance from 8.x or earlier to 9.x or later 34. Unified CM can be registered to Smart Licensing from the CLI using license smart register idtoken followed by a token from Cisco Software Central 53. The IM and Presence Service requires no server or software version licenses; users are enabled individually 21.

After installation, Unified CM operates under a 90-day evaluation period 18. While running in this evaluation period, secure SIP trunks cannot be deployed 19. Once the 90 days end, adding new users or devices is blocked until the system registers with Cisco Smart Software Manager or a satellite 18.

Starting in Release 14SU4 and 15SU2, Call Home is deprecated as the Smart Licensing transport and Smart Transport is introduced 3. After an upgrade, Unified CM transitions automatically to Smart Transport if smartreceiver.cisco.com is reachable, and falls back to Call Home if that connection fails 55.

Applicability

Applies to: Cisco Unified Communications Manager, Cisco IM, Cisco Prime Collaboration Deployment, and Cisco Prime License Manager. Deployments: on-premises. Sources checked 2026-09-24. Unified CM Release 15 supports virtualized deployments only, and bare-metal servers are not supported 60. Direct standard upgrades to Release 15 are supported from Release 12.5 and Release 14 and its SUs, while upgrades from Release 14SU4 require at least Release 15SU2 as the destination 91. Unified CM 7.0(1) and older cannot be migrated to Release 15 27.

What remains uncertain

Whether the utils disaster_recovery CLI command syntax remains unchanged or fully supported in Release 15 is not covered by the sources below.