The first artefact in every platform migration is a spreadsheet with forty tabs. Somebody ran RVTools, exported everything, and sent it over. Then a tool ingests it and produces a node count, and the node count goes on a slide, and the slide goes to a steering committee.
I have spent enough time on the wrong side of that node count to be suspicious of all of them, including the ones produced by tools I am supposed to like.
The structural problem
Every vendor assessment tool does three things: it reads an inventory, it applies assumptions, and it emits a recommendation. The inventory is the same for everyone. The recommendation is what gets discussed. The assumptions are where the entire argument lives, and they are almost never printed.
Consider what has to be assumed to turn a VM list into a node count. Target CPU overcommit ratio. Memory overcommit, and whether the platform’s memory dedup is counted. Data reduction ratio on storage. Headroom for failure. Growth. Peak versus average utilisation, and what “peak” means — 95th percentile of a month, or the highest sample ever seen.
Change data reduction from 1.5:1 to 2.5:1 and the storage half of the answer moves by forty percent. Nobody is lying. The default was simply chosen by a person who works for a company that sells the thing.
The twelve columns
If I only have the vInfo and vCPU and vMemory tabs and an hour, these are the fields I read, roughly in order:
Powered state. A shocking proportion of any estate is powered off and has been for years. It is still in the inventory, it still shows as provisioned capacity, and it still gets sized for unless someone filters it. Ask about every powered-off VM. Some of them are somebody’s quarterly job.
Provisioned vs used disk. The gap between these two numbers is the single biggest swing factor in a storage proposal. Sizing on provisioned is how you triple a quote.
vCPU count and actual CPU usage. The estate is oversubscribed in the source and will be oversubscribed in the target, but not necessarily by the same ratio. Also: count the VMs with more than eight vCPUs. They are the ones with licensing consequences and NUMA consequences.
Memory allocated vs active. Same story, different resource, and much more contentious because memory overcommit behaves differently on every platform.
VM hardware version and guest OS. This is your list of things that will not migrate cleanly. Unsupported guest operating systems are a project inside the project.
Snapshot age. Old snapshots are consumed capacity that nobody has counted and a data integrity conversation waiting to happen.
Cluster and host mapping. Because affinity, licensing boundaries and failure domains all live here, and a flat VM list destroys that structure.
Datastore and multipathing. Where the storage dependencies actually are.
Network adapter and portgroup. The shape of your network migration, in one column.
Tools status. A proxy for how well managed the estate is, and a predictor of how many VMs will need hands-on attention.
Creation date. Correlates suspiciously well with “nobody knows what this does”.
Annotation and custom attributes. Frequently empty. When they are not, they contain the only documentation that exists.
What I do with the gaps
The columns above tell you what is there. They do not tell you what the workload does over time, and no inventory snapshot can. For that you need performance data over at least a month, ideally a quarter, and if nobody collected it then your sizing has an honest error bar that should appear on the slide.
I have started writing the error bar down. “Between eight and eleven nodes, with the range driven by a data reduction assumption we cannot validate without thirty days of performance data.” Customers respond to that far better than I expected. It reads as competence rather than hedging, and it makes the conversation about getting the data instead of about defending the number.
The habit worth building
Before you accept any tool’s output, make it show you its assumptions, and write them on the same page as the result. If the tool will not show them, treat the output as a marketing document, because that is what it is.
I am slowly building my own version of this for exactly that reason: same inventory in, every parameter visible, and a result I can explain line by line to someone who is about to spend money. It is not finished. But the discipline of having to expose every default has already changed how I read everyone else’s.