Gaining Confidence in Your VMware Exit Plan: Discovery & Assessment

Exiting VMware is not just a technical exercise – it is a business-critical transformation that touches cost, risk, agility, and long-term platform strategy. Yet too many organizations approach it either as a simplistic “lift-and-shift” or as an over-engineered analysis that stalls progress before it begins. This blog series is designed to strike the right balance: providing a structured, pragmatic framework that removes unnecessary complexity while preserving the rigor required for success. The goal is not to prescribe vendors or destinations, but to establish clear principles and proven steps that build confidence in your VMware exit plan, starting with Discovery and Assessment, the foundation upon which every successful migration is built.

My observation is that Migration plans are either far too simple and not well thought out or overly analyzed, time consuming, and complicated. Like physics, they need to be as simple as possible but not simpler.

Migration projects can be overwhelming and even if you've done one before, there's a good chance it turned out far more difficult and expensive than anticipated. Having done many migration projects, there's more than a modicum of blood, sweat, and tears in these words. In terms of where or what to migrate to this set of blogs will not recommend anything specific, it will remain Cloud and technology agnostic. But hopefully it will define a set of principles and tenants in a structured framework to make your projects as simple as possible (but not simpler).

So where do you start? The first step is Discovery and Assessment. Technically they are very different objectives although the methods usually overlap. Discovery is understanding what you have or verifying that you have what you think you have. It's pretty simple actually, but your datacenter may be a bit like your sock drawer. You know about your favorite socks, the ones you use all the time. You know where they are, how they are organized and know what socks are used for what purposes. You know you have a lot more than the ones you wear the most, and some are way in the back that you never think about (like some of your servers) but they are there, taking up space.

Your servers are probably a lot like this. Your Discovery needs to be automated with an easy-to-use tool that gives you fast, accurate data. Discovery should not take long other than just making sure you have Discovered everything you have. You should be able to summarize your Discovery data in different ways, an inventory of servers, networks, storage, types of storage, applications, Operating Systems, etc. There are important elements to understand here, at least at a high level. It's important to understand, at a high level, the resources needed in the Target environment. This data can also be used to start evaluating viable Target environments. Even if you've already decided on a Target environment, it's a best practice to do a quick Discovery of what you have, make sure you know what you have and overall how much. How many TeraBytes of data do you have and how long will that take to transfer over your planned network connection. At this step, take a first pass at the "no-brainer" servers and resources to eliminate. For now, any servers that are questionable, keep them in the plan and evaluate them after the Assessment phase. Understand high level costs and how long it will take to transfer and seed the first iteration of data given your network.

Discovery should be married to Assessment. Whereas Discovery is quantitative Assessment will be qualitative. A good assessment tool will identify over and under utilized resources and match usage over time to understand peak usage that will facilitate right sizing. Its very common to find servers that are not used at all.

Assessment includes analyzing application affinities and infrastructure requirements to gain a high level view of wave planning. This is also a good time to review security and authentication.

It's a common mistake to spend too much time on Discovery and Assessment. Don't spend too much time at this step – focus on inventorying, verifying against existing records, identifying eliminations, estimating high-level costs, and network transfer time. You don't want to spend any more time on servers that will fall outside the project. Remember, this is first defining quantitative scope followed by a qualitative analysis.