Intro

We covered quite some topics in the previous blogposts. We talked about how important the assessment phase is, which Technical & Common vSphere Challenges you could expect, and what the consequences are of certain choices and methods. We also talked about how you can define the “Ist”, and how it is a big part of the GAP-Analysis. The GAP-analysis is a method that I like to use for projects in general, but it also works really well with vSphere upgrades. Especially when the version jump is really big and there are lots of dependencies.
In this post, we’re going to discuss how you can create the last part of the GAP-Analysis, and that is defining the “Soll”. The “Soll” is the so-called desired state or future state. It is the end result of your upgrade, but in our case, this also includes all the changes that needs to be made in order for the upgrade to work. Based on the “Soll” we will define our Roadmap, and with that you can finally start to plan & execute. Let’s begin

BlogPost Serie Overview:
✓          Phase 1: Kick-off
✓          Phase 2: Assessment
✓          Phase 3: Defining the IST (Current State)
✓          Phase 4: Dependencies & Compatibility
✓          Phase 5.1: Technical vSphere Challenges
✓          Phase 5.2: Common vSphere Challenges
✓          Phase 5.3: Solving vSphere Compatibility Challenges with VVD
⇒          Phase 6: Defining the Soll & Roadmap (Future State)

Defining the Soll

So we know how to define the “Ist”, and we already discussed most of the important parts of the vSphere challenges & choices that you could face. Now that you have a clear overview, it is time to define the desired state. As I said in a earlier blogpost, I’ve created a template that can help you with defining the “Ist”. Once you have defined the “Ist”, you’ll make an overview of all the dependencies & compatibilities that the environment has. This can be third party products like backup, monitoring, anti-virus, but also hardware. Once you made an overview of all the dependencies and their compatible version, you can sort out what the highest possible and or desired version of your environment is. This is also a separate sheet within the template.Together with the technical questions that we discussed earlier, you are ready to define the “Soll”.

So an easy method I like to use, when I want to define the “Soll”, is to copy and pasting the answers of the “Ist” stheet, into the “Soll” sheet and coloring every type of information red. I personally like to work with colors, since it will help you to quickly gain an overview. In this case red means that you need to verify if the “Soll” changes in comparison with the “Ist”. This can be quickly done for most of the questions / options. For each verified piece that doesn’t change in the “Soll”, I’ll turn them back to the original color (black). When I do spot a change, like the vSphere version number, I change the set of information into green. This way, you can easily spot what you want to change as well.

This is a method I like to use which is quite simple, but really effective. I also like to turn some questions / options in the “Soll” sheet into orange or yellow. Yellow means for me that I still need to verify some stuff, but that I’m almost certain about the decision & Orange means that a choice can impact the type of upgrade or path that we take. Once you’ve completed your “Soll” sheet, you are ready to define the Roadmap.

Defining a Roadmap & Plan of Approach (PoA)

Once you’ve filled everything in for both the “Soll” Sheet as well as the Compatibility Sheet, you have gathered all the information to define your path. From that point on you should look back to the technical questions and ask yourself the following. What is the highest possible version that we could have, is it possible to do an “in-place” upgrade and stay compatible between all the versions of the dependencies? Which jumps can we make, and do we need to update the dependencies before we can continue? Do we even have an option to migrate, and are there enough resources? Those are all questions that we touched in the previous posts, and I think you get the point. Once you globally have defined how you want to proceed with the upgrade, you can start to plan the process and write it down in steps & define a Roadmap with a plan of approach. Now everyone writes his plans in his own ways, but I think your plan should & could have the following elements.

• Roadmap – Define the steps & order of sequence
  • I like to define clear steps of how and when we should proceed. This can be in a General overview, but also in a more detailed overview where you even define exactly which component should be configured. This can and should consist multiple elements, like how we upgrade the vSphere environment, what you do with certain dependencies after certain steps, the preparations that has to be done, at which moment you plan downtime, etcetera.
  • I like to write down my steps in General phases and sequence numbers for my steps. Using sequence numbers for each step, can be really helpful to refer to when talking to teammates, or when you want include the Roadmap in other documents and want to refer to certain steps as well.
• Define a Rollback plan
  • Even though the upgrade process or migration is most of the time a solid and reliable process, things can still go wrong. You want to think ahead of how you going to mitigate certain problems, and what your options are. This helps you also to think better about your steps and the impact that they might have.
  • In some cases, your rollback plan can define your upgrade path. Which was the case for one of my customers, who decided it wanted to do a migration instead of an in-place upgrade. For him, it was easier and quicker to roll back to an existing older environment, then doing a down grade or restore a backup when things go wrong.
  • In your rollback plan, you can refer back to certain steps in the Roadmap of where you think you might have the chance to rollback to.
  • should suggest you should always make backups before you continue.
• Define a Test plan (Functional vs Performance)
  • Depending on the needs, this can be a really simple test plan versus a complex and complicated test plan. In some cases, you make a distinction between Functional Tests & Performance tests.
  • Performance Test Plan: VDI environments are a great example that really have great benefits with a performance test plan. Since a performance changes can a great impact on the end user experience. With all the updated to mitigate spectre meltdown, this can become a interesting topic.
  • Functional Test Plan: In general you just want to know if everything is still working after an upgrade. This can be as simple as, can we still do a vMotion versus, is my monitoring application still working or can my VDI backend still connect and talk with the vCenter? This should always be a part of your plan, how big or small it maybe.
• Create Phases for Prerequisites & Preparation
  • Even when not everything is in place, you can start your roadmap with a prerequisite phase and or a Preparation phase.
  • Prerequisite should be done before you start with the project and preparation in my case, often refers to the steps we should take in or during the project.
• Include Creating backups in your PoA
  • This can be ESXi Config, Normal VM backups, dvSwitch configs, host profiles, Iso Backups, etc. It is important, and I
• Inform other IT teams for downtime
  • Sharing is caring 😉
• Plan Downtime with the organization & business if needed.

There are many steps that you could include in your Plan of Approach & Roadmap, but I think you’ll get the point. The list above has in my opinion, one of the most important topics that you should consider in your plan, but feel free to add or change that list as you see fit.

Alright, I hope that with all the information, templates, methods & tools that I shared in these posts, you feel more comfortable to start planning your upgrade. If you still not feel comfortable, feel free to contact me with any type of questions in the comment section or contact me at info@vsam.pro if you want to have some direct advice & consultancy.

Hope you had fun reading and hopefully, I’ll see you in another blogpost.
See ya.

Samir of vSAM.pro

Samir is the author of vSAM.Pro & a Life enthusiast who works as a consultant in the field of IT. With a great passion for Tech & Personal Development, he loves to help people with their problems, but also inspire them with a positive outlook on life.

Besides that, he is also a big Sport & Music junky that loves to spend a big chunk of his time on producing music or physically stretching himself.