he doesn't want any loss of service.
This is an unrealistic expectation. You can work to minimize it but there will be a blip at some point for each app.
He has decided to do a parallel configuration. I would like to know if it is possible to back up the config of the different servers to the new servers with the new versions. For example, back up the cucm config to version 11.5 to the new server with a different ip to version 15.
DRS backup and restores require all platform details - IPv4, hostname, DNS, NTP, security passphrase, etc. and source/destination software version be identical. So that's out. At a (very) high level you have a few options:
- Build an isolated staging environment so you can start with a DRS restore. Same subnet(s) - including layer three routing if the app is clustered across the WAN normally, same DNS servers (or at least emulated versions of them capable of resolving the A & PTR records of the app you're working on), same NTP server IPs (again, at least emulated versions), deploy the same VMs, install the same 11.5 build, restore. A cleverly configured router-on-a-stick can do all of this - even DNS and NTP. Once that exists you can upgrade it in place following the regular process outlined in the product documentation. When ready, you shutdown or disconnect the vNIC of each 11.5 production VM and change the VLAN of the 15.0 staging VMs so they're now in prod. It's sort of like pulling the table cloth out from under the place settings. This is a lot of work and is an older approach. Very few clients want to spend the money necessary to do this but if done well it's the smallest amount of downtime.
- PCD Migration Task
- Fresh Install with Data Import
The second and third approach are typically done one VM in the cluster at a time. They're effectively the same process, just different approaches to it. The cluster will be in a partitioned state during this: any node running 15 will not be able to communicate with nodes running 11.5.
I have a customer with CUCM, CUC, CMS and EXP infrastructure.
You have a fair amount of ground to cover here; this should be an expensive project. What I wrote above only applies to CUCM & CUC. Expressway is either in-place upgrade, isolated staging environment, or build new and switch DNS SRV records other systems (CUCM, CMS, public internet) use to find Expressway during the cut. The last option is useful when the Expressway config is a dumpster fire and you're better off starting over. Temporarily very short DNS TTL helps, if you go that route. Thankfully I have never needed to learn CMS, so I can't speak to that.
