CUCM 12.5 to 15.x - Migration with Data Export/Import

[TONY SMITH]

Hi,

We have a cluster running 12.5, Publisher and two Subscribers.  It needs to be upgraded and our current idea is to skip 14.x and go straight to 15.x. Looking at the available upgrade paths the migration with data export/import looks attractive, we can move to his new VMware infrastructure in one step, install into a nice new VM built with the up to date OVA, and leave behind any potential issues from previous upgrades, disk resizing or anything.

But information on the process is sketchy, virtually nothing in the install or upgrade guides. I've been reading through ..

https://www.cisco.com/c/en/us/support/docs/unified-communications/unified-communications-manager-callmanager/222244-install-cucm-cluster-using-data-export-a.html

And a few questions arise.

(1) Does running the data export from the source servers make any changes? I would certainly hope not but the documentation refers to shutting them down immediately after the export.  Obviously I'm thinking of back out plan, you would hope the old servers could be started back up if the worst came to the worst, essentially if we hit a roadblock on the Publisher migration.  There's reference to rolling back, which does imply some changes were made ..

"If you want to roll back to the previous release, install ciscocm.DataExport_rollback_v1.0.cop.sgn COP file"

(2) Can it be staged so the cluster isn't out of service for the whole duration?  Again I would hope so, but again the documentation has all the source servers shut down before even starting the 15.x installation.  Screenshots show their example install taking around two and a half hours for the Publisher.  Presumably we also need to install Locale files and maybe Timezone update as well before the new Publisher is properly in service.

So can this be staged?  Run data export on all source servers first. Then shutdown Publisher only and leave the old Subscribers running until the new Publisher is up. Ditto with backup Sub. Meaning the cluster is still alive on the old version until finally we shutdown the live Subscriber(s) at which point the phones can re-register with the backup.

Or do we have to plan around completed outage for at least three hours or so?

(3) Final question for the moment, again I hope this isn't an issue but are all certificates replicated to the new servers, so that the phones will trust them and register correctly without and certificate export/merge/import stages?  We will keeping the same IP addresses if that makes a difference.

Thanks,

[Roger Kallberg]

You’ll likely find a few answers to your questions in this blog post that @Nithin Eluvathingal wrote a few days ago.

https://community.cisco.com/t5/collaboration-blogs/fresh-install-with-data-export/ba-p/5219431

[Nithin Eluvathingal · Accepted solution]

When you export data using Data Export, AFAIK, it makes changes to some features on the source nodes from which the data gets exported. These changes on the source nodes can be reverted using the COP file ciscocm.DataExport_rollback_v2.0.cop. I have never done a rollback on the source cluster, but as per my understanding, it is required when you stay on the source cluster again.

Taking a backup before the upgrade activity is always highly recommended. You must perform this either using the PCD or a fresh install with a data export to ensure that, in the worst case, you can restore the applications to their old working state.

You must shut down the node when installing if they are getting migrated to the same IP address. If not, they don’t need to be shut down, and you must perform the bulk certificate exchange for the phones to trust the new cluster.

You can perform the migration one by one. Export the data from all the clusters and keep them on an SFTP server that both the new and old clusters can reach. If you are using the same IP, shut down the publisher, install the new publisher by importing  the exported data. Once completed, continue the same process with the subscriber nodes.

The same old certificates will be imported to the new cluster. If using different IPs, a bulk certificate exchange is required as mentioned above.

[TONY SMITH]

Thanks. Actually I realised there's no need to worry about rollback at all. Since since CUCM went Vmware, we always take a full copy of the Publisher VM before starting any upgrade. So in this case we could run the export from the copy, leaving the former Publisher shutdown but otherwise untouched. Or vice versa, keeping the backup as our rollback.

If needed, it's a much quicker backout than needing to carry out a fresh install and DRS restore.

[TONY SMITH]

Having just marked this as "solved" I now have another question. While the export is being run on the Publisher, or afterwards, does it have any impact on the Publisher's normal function, or the function of the whole cluster?

As before I'm thinking about scheduling and downtime. Ideally I'd like to get the Publisher upgraded before otherwise disturbing the cluster. Possibly we could (virtually) move it to an isolated network. But that involves hassle of also moving the SFTP server, with associated hassle of trying to administer both in their isolated state.

Same goes for the new install/import. If that's done on the live network is that likely to impact the Subscribers? Or will it functionally be pretty much the same as if it had been upgraded?

[Nithin Eluvathingal]

As far as I know, it’s recommended to run the rollback COP if you plan to keep the Source CUCM cluster for some time.

In the recent migration to version 15, all the phones were on the subscriber. I exported the publisher, built the publisher, took the subscriber down, and then built the subscriber. During the subscriber build, the phones registered with the publisher. Once the subscriber was live, the phones fell back to the subscriber. Even though it was live, I performed this task over the weekend to give us extra time to fix any issues that might arise.

I didn’t test all the operations of the CUCM, but since the phones fell back to the publisher and calls were working, I expect everything to work as normal.

No issues were observed post migration till now.

[TONY SMITH]

Thanks, the sequence you described is pretty much exactly what we'd prefer to follow. Just turning over whether we could do the Publisher export/install/import prior to the change and downtime window, as we've done previous upgrades for this cluster.