BlogPost Series: Creating a Roadmap for vSphere Upgrades – Phase 3 (Defining the IST)

Intro
Defining the IST. The IST is so called starting point or baseline if you will. It describes and evaluate the current state of your environment and it is key for a project to be successful. It helps with defining the scope of the project and obtaining in-depth knowledge about the environment of the customer. Depending on the in-house knowledge of engineers and administrators, available documentation, and accessibility for you as consultant (or internal engineer), makes the difference in the amount of time this phase can take. Like the assessment, defining the IST correctly is crucial for setting up the right expectations, but also to spot roadblocks, challenges, and ultimately defining a roadmap towards the Soll. This is especially crucial when you’re upgrading difficult environments like in Health Care. You don’t want to end up in a situation where some undocumented highly dependable legacy application has stopped working, and nobody knows why. In this post we’re going to cover: The methods that we use for obtaining information, how to validate the information that has been obtained, and most importantly, a checklist of the information we need to define the IST before we even can start plotting a roadmap for the vSphere Upgrade. Let’s begin.

BlogPost Serie Overview:
          
Phase 1: Kick-off
✓          
Phase 2: Assessment
⇒         
Phase 3: Defining the IST (Starting Point / Current State)
⚬  
         Phase 4: Dependencies & Compatibility List
⚬           
Phase 5: Technical vSphere Challenges & Decisions – Part I
⚬           
Phase 5: Technical vSphere Challenges & Decisions – Part II
⚬           
Phase 6: Defining the SOLL (End Goal / Future State)
⚬           
Phase 7: Create the Roadmap
⚬           
Phase 8: Create a Rollback plan
⚬           
Phase 9: Documenting and backup
⚬          
 Phase 10: Planning and executing

How to define the IST
There are several ways to define the IST, but the best way is to use methods that can be verified. You know what they say:

“Assumption is the mother of all f*ck ups.”

When defining the IST, I always like to keep a list that shows which information is verified and which info is still under assumption. Once finished, the best scenario is that all of your information has been verified. If you haven’t or weren’t able to verify all the information, start considering the risks and impact when in the end some assumptions don’t seem to be legit. By explicitly defining and reporting about which info in your IST are assumptions and what risks there are involved with this, you can get an organization to start moving and help you to verify that last bit of information for you. It also helps to cover your own ass, so that it doesn’t backfire on you when in the end the info is false or incorrect.

That doesn’t mean you shouldn’t use methods that cannot be verified. Some methods are quite useful even though they are not the best way for verifying.

For example, interviews are a great way to quickly gain lots of knowledge and getting up to speed. Still, as long certain info has not been verified by you or the organization, that info shouldn’t be fully trusted. People can make mistakes and that is no problem, but if you’re relying on wrong or outdated information while defining your roadmap, you can end up with some serious surprises.

Defining the IST: (Free Excel) Upgrade Template & Checklist
Finally, the part that we are getting more technical and also in-depth. After defining several roadmaps for different vSphere Upgrades, I made a list of key questions that I found necessary to be answered. Once answered, I noticed that I gained enough
information for defining the IST and creating the scope. The following excel document is a template that I’ve created, which can be used as a guideline for your upgrades, as well as a decision maker for the path you will choice. The template can be freely downloaded here:

Besides the Questions for the IST, the document has several other tabs left which will be discussed later in this series. For now, you should know that all the questions that are listed in the IST are fairly complete, but that you should always validate if you aren’t missing any vital information for your situation. Like 3th party dependencies or vSphere integrations. In the Note section you can find tips and hints of why certain information is helpful in your project.

Methods for gaining information
Since you now know which information is needed for defining the IST, it is time to obtain it. Let’s make a quick overview of how we can obtain the information and which methods can be used. Most of them are self-explanatory, but it is still good to know which information you should classify as trusted or as assumptions, and which tools can help you.

  1. Documentation
    • Easiest way to gain knowledge and an overview of the environment you’re dealing with. If the customer doesn’t have much documentation in place, you’ll already found one of your first challenges. This should give you a hint that there are maybe more surprises coming your way than the customer or you initially have anticipated.
    • Always keep in mind that documentation can be outdated, and therefore should always be checked for being up to date. If not, you can still consider documentation of the customer as being an assumption.
    • Reading the documentation also helps you to prepare for the next step and that is interviews.
  2. Interviews
    • Having (useful) documentation is great, but interviews always help me to get more feeling about the assignment or project I’m dealing with. It is the best way for knowing how the organization acts, think and work. It also helps you to quickly find out what kind of issues or challenges the customer is dealing with.
    • Even though interviews aren’t always the most reliable source for information, it is the best way for quickly getting up to speed and for setting up the right expectations for multiple parties. Besides that, it also helps you getting the organization involved with the process, and this can be crucial for a successful project. You don’t want to fight the internal organization because of some miscommunication or undesired feeling that you surpassed someone with a certain role. So having lots of interviews is key to learn about the organization and the people within.
    • Always try to interview people with different roles and or from different departments that are involved and are using or depending on the (vSphere) environment.
    • Another great take away with interviews, is that you sometimes find skilled people who already have thought about a certain challenge for your project, and even found a solution for it. Getting those people involved can help you tremendously. Just be sure to give credit, where credits is due. Not only will they be more eager to help you next time, it is also just the right thing to do 😉.
  3. Testing & Checking the environment yourself
    • It is simply the best way to verify information but can also be time consuming. Still when you’re also executing the upgrade, you should know how the environment looks and feels like. With the (web)client, cli, scripts and (third party) tools, you can quickly find most of your valuable information.
    • The vSphere upgrade can consist of more than only the VMware part, and therefor access to Storage, Network components and other dependencies or integrations like, backup software, monitoring, Security Solutions, etc. can be extremely helpful for verification. If not possible, make sure you can verify your information so that you know what is going on.
  4. Tools
    • RVTools is one of the best tools ever created and it’s a great way to quickly create a complete overview of a vSphere environment. The data output contains helpful information, and I always use it right before I start a project. RVTools helps me to quickly define the IST in an easy way and readable excel document. Since it contains loads of information, I usually keep it as a reference document and copy the information that I need to my own documents. RVTools can be found on the website www.robware.net/rvtools of Rob de Veij. Lots of respect and a big thank you to him for creating this awesome tool.
    • Powercli or ESXcli, lots of info can be found through cli. Even though it is less user friendly then a tool like RVTools, it is still one of the best ways to find information of multiple resources or info that is not viewable in the GUI.
    • OOBM for hosts. Out-Of-Band-Management like ILO, DRAC, etc. contains lots of information about the host hardware. It is also a nice way to open a console, and to connect to the ESXi host directly.
    • VMware Health Analyzer (Partners Only), not necessarily the best tool for an upgrade analyze, but still a great assessment tool. You can find lots of interesting information about the environment, like best practices that could be applied or issues that come up.
    • VMware ESXi compatibility Checker
      The ESXi Compatibility Checker is a python script that can validate VMware hardware compatibility and upgrade issues of ESXi. Not necessarily a tool needed for defining the IST, but it can definitely help in the process of the GAP Analysis and to spot roadblocks ahead. It is an awesome fling, that is worth checking.
      https://labs.vmware.com/flings/esxi-compatibility-checker
  5. Official Vendor Channels and or documentation
    • When dealing with dependencies of other Vendors, you want to be sure that certain information is also checked with them. Especially when they are a crucial part within the ecosystem.

Summary
There are lots of ways to obtain your info, but the most important thing is that you create a reliable and validated document, that gives you a great overview that can be used as your starting point. With the excel template as your guideline, I’m sure that the obtained info will help you to get prepared for (most of) the different questions, challenges and scenario’s you will face. With the IST defined, you can create a Roadmap towards the Soll. But before we start with creating the Soll, we first need to define and list up all the dependencies and create a compatibility list with the different vSphere versions.

Alright, that’s it for now.
See you in the next post.

↑↑ Follow me on my Socialz ↑↑ - Or - ↓↓ Care & Share ↓↓

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.