CUCM migration v8.6 (restricted) to v11.5 (unrestricted) on new hardware

[richfellows]

Hey all,

I've been browsing through the forum here and Cisco support documents and I'm finding a lot of little hints as to what I need to do but am not quite seeing the whole picture.  First off let me describe the situation and what we're planning.

Current:

• Version 8.6
• Restricted version
• 1 pub, 1 sub

Future plan:

• Moving to version 11.5
• Unrestricted version
• New hardware, new VMs

I understand that this is a migration, not an upgrade, as it is new hardware and moving from restricted to unrestricted.  Once we have the new 11.5 VMs fired up what's the best way to migrate our data from 8.6 into the new environment?  Is there a way to backup everything and restore it onto the new version or will this not work due to the version differences?  I noticed that in BAT I seem to be able to export and import just about every setting I can think of, is this the preferred method of migrating the data across between versions?  I saw a post on here mention that there are differences in the export files from 8.6 that need to be rectified before importing into 11.5 but no mention of what those changes are.  Is there a document somewhere that provides instructions for this or at least shows the field differences so that it can be fixed before importing?

Thanks for any help you can provide, even if you only know a little bit of the story any bit helps.

Rich

[Jaime Valencia]

BAT only works with the EXACT SAME version, and it only works for the same option, either restricted, or un-restricted.

If you want to migrate the info into an ALREADY installed 11.5, you can only use BAT.

No, there are no docs that tell you how to massage the BAT files between releases (8.6 to something else, or restricted-unrestricted), that is a all a manual procedure you need to find out by exporting the same option in both systems, and comparing them.

I'd probably install the same release you have on the new hardware, then upgrade to the un-restricted version to keep all the data. This would be a one way only, once in un-restricted, there is no way back to restricted (other than BAT, or if you're lucky and can do a rollback, use that method)

Unless strictly necessary, I'd suggest you keep using restricted.

[richfellows]

So if we were to load the legacy restricted v8.6 software on our new hardware, restore the backup to it and do an in-place upgrade to the unrestricted v11.5 version this would solve our issue?

Also, would it be a smoother process to migrate the VM from the old hardware to the new hardware to save a few steps or is this not a supported method/a completely terrible idea?  :)  

Regarding restricted vs unrestricted.  As far as I know the reasoning for this is that we're moving from this environment being US only to now including a ton of other countries where we have operations.  This legacy system was owned by a company we merged with (US only) and we're a multi-national company operating in the US, Europe and APAC.  From what I understood from my manager we needed to do this to operate with this platform in all of the locations we have a presence.  Though that might have been incorrect, I'm not 100% sure.  For reference we don't have locations in places like North Korea, Iran, Libya, China, etc.  We are in places like US, UK, Germany, Austria, France, Switzerland, Finland, Denmark, Sweden, Singapore, Japan, Australia, etc.  Does that mean that we don't have any concern using the restricted version?

[Jaime Valencia]

Yes, you can upgrade from restricted to unrestricted, but not the other way around.

You can move the VM with vCenter (while the VM is off) or a cold migration (manually move the files), either will work.

I'd probably reach out to your local Cisco SE for assistance on finding out if you actually need to move to an unrestricted version, or not.

Then take it from there.

[richfellows]

Thanks for the assistance.  Before we go forward with loading the unrestricted version I'll verify that it's what we definitely need.  Perhaps there's something I missed in the initial conversation with our vendor, unfortunately I wasn't involved in the first round of this so I'm filling in gaps now.