Planning a vSphere Upgrade

Many of my customers request help when preparing for an upgrade to the latest version of vSphere (recently, they've been wanting to upgrade vCenter to 6.5 on the vCenter Server Appliance, but this is generally a recurring request for each new version).  And I get it, there's a lot of moving parts to consider when planning on an upgrade like this.  So, I figured that I'd do a quick write-up about the process that I go through when planning for an upgrade like this.

The first thing that I do is compile a big list of all of the solutions in the environment that are dependent on vCenter and ESXi.  I just build a big spreadsheet with 4 columns: Solution, Current Version, Desired Version, and Notes.  When collecting this list, it's important to consider other VMware solutions (such as vRealize Automation Center, Horizon, Network Insight, etc.), hardware platform (is this running on HP BL460c blades?  Nutanix?  IBM?), backup solutions (Avamar is very common amongst my customers and has some strict version requirements), antivirus (if using a vSphere-based product), storage platform, monitoring solutions, or anything else that talks directly to either vCenter or the ESXi hosts.  It's probably going to be a big list.

Once I've compiled my list of products and their current versions, it's time to use my black magic.  You see, I possess secret knowledge, a Word of Power that grants the arcane knowledge required to plan this sort of upgrade project: Interoperability.

First, I go to the easy source: the VMware Interoperability Matrices.  In the top section, I'll type "vCenter Server" and select the version that I want to move to (right now, 6.5 u1).  Then, in the bottom section, I'll search for every other solution on my spreadsheet (well, everything from VMware).

At this point, I'm looking for 1 crucial thing: is the current version of this solution compatible with the new version of vCenter that I want to move this customer onto.  If there's a green checkbox, I note "supported" and move onto the next solution.  When there isn't support between the two versions, it's up to me to figure out how to get from their current state to the desired end state.  For example, let's look at an imaginary customer who is running Horizon 6.1.1 and vCenter 5.5u3 (go ahead and type "vCenter Server" and "Horizon (with View)" into the Interoperability Matrix, I'll wait).

You'll see that we've got a bit of a problem here, as vCenter 6.5 does not support Horizon 6.1.1.  At this point, I need to figure out some options for the customer and help them to figure out their best path forward.  As I see it, there's a few options:

1. Upgrade vCenter to 6.0 with no hope of applying further updates, as that's the highest version that supports Horizon 6.1.1.
2. Upgrade Horizon to version 6.2.5 (the latest version in the 6 family), which will allow us to then go and upgrade vCenter to 6.0u3 (and may support potential future 6.0x updates).  This is safe because Horizon 6.2.5 supports the current vCenter version of 5.5u3 and so can be directly updated prior to any vCenter updates.
3. Upgrade Horizon to version 7.4.0 (the latest version), which will allow us to upgrade vCenter to our desired 6.5u1 target.  This is also a safe path because this version of Horizon also supports the currently running 5.5u3 vCenter, so no intermediate upgrades will be required for interoperability.

Next, I click on the Upgrade Path link and search for my solutions (vCenter and Horizon, in this case).  I want to make sure that there's a supported upgrade path from my current version to my desired version for each option.  I also pay special attention to any notes in that matrix, as they can be warnings about critical landmines in that path.  And I don't like stepping on landmines.  In this case, it looks like there's some considerations around going to Horizon 6.2.5, but 7.4.0 doesn't have any special notes.

Going up to vCenter 6.5 has some special requirements, stating that we need 5.5 u3b if we're using an external SSO server... and it reveals a problem with option #1 from above.  There's no upgrade path from vCenter 5.5 u3 to vCenter 6.0 - 5.5u3 is actually newer than 6.0, meaning that whole option is invalid.  The lowest version of vCenter 6.0 that we can upgrade to from 5.5 u3 is 6.0 u2, so even though option #1 doesn't work, it looks like both options #2 and #3 have survived this check.  With this in mind, I'll make notes on my vCenter line about the two options and move on to checking for interoperability constraints from other solutions.

Once I've checked all of the VMware solutions, I move to my best friend: Google.  I'll now search for each solutions' interoperability matrix, and run through this exact same exercise.  Eventually, a path forward will begin to emerge, showing which solutions must be upgraded either as prerequisites to my vCenter upgrade or as responses to it.

Unfortunately, the job's not quite done yet.  Now that I'm calling for a bunch of prerequisite upgrades, I need to repeat this process for each of those solutions, figuring out what other solutions touch them and how they might be impacted by the desired upgrades.  I frequently open support tickets with vendors at this phase, as I need to ensure that we're keeping everything on a supported path and I'm usually not very familiar with these 2nd+ degree technologies.  Hopefully these upgrades won't have further prerequisites... but if they do, we do it all over again, again and again, until we have established a supported path forward.  Like ripples in a pond, vCenter upgrades tend to spur upgrades for many other systems, which occasionally splash and cause ripples of their own.