Turn your RVTools export into an exit assessment

Privacy, in plain words: the file is parsed by JavaScript running in this tab. There is no upload, no server, no analytics event carrying its contents, and nothing persists after you close the page. This page works identically if you load it, disconnect from the network, then drop the file.

What the analyzer checks

RVTools (a free utility by Rob de Veij, effectively the industry standard for vSphere inventory) exports your estate as an .xlsx workbook. The analyzer reads the vInfo, vHost, vDisk, vSnapshot, vUSB, and vCD tabs and looks for the things that decide migration difficulty in practice:

• Licensing exposure. Total physical cores across hosts, the number vSphere's per-core subscriptions actually bill, pre-counted for the cost calculator.
• Hard blockers. Raw device mappings, shared-bus disks, and Fault Tolerance, the configurations no V2V conversion handles for you.
• Friction items. USB passthrough, independent-mode disks, open snapshot chains, and monster VMs that dominate cutover windows.
• Free wins. Powered-off VMs and mounted ISOs, scope you can delete from the project before it starts.

The output is a prioritized blocker list with affected VM names and a downloadable assessment you can paste into your migration planning doc. Pair it with the renewal planner to see whether the cleaned-up scope still fits before your renewal date, and with the per-path guides (Proxmox, XCP-ng, Hyper-V, Nutanix AHV, OpenStack) for the execution detail.

New to the tool, or inheriting someone else's export? Our RVTools reference covers running it against vCenter with a read-only account, what every worksheet means, why an export fails or comes back incomplete, and whether it is safe to run.

Limitations, honestly: the analyzer reads what RVTools captures. It cannot see application-level dependencies, backup-job coupling, or network micro-segmentation (NSX), those still need human discovery, and the guides cover how. vGPU and SR-IOV passthrough do not appear reliably in RVTools exports, check those by hand in vCenter.

How to read the blocker report

The report is deliberately ordered by how much a finding changes your plan, not by how many VMs it touches. Ten VMs with mounted ISOs is a five-minute cleanup; one VM with a raw device mapping can add a fortnight and a storage-team dependency. Read it in that spirit.

• Raw device mappings (RDMs). The single most common reason a "simple" migration slips. An RDM means the guest is talking to a LUN rather than a virtual disk, so no V2V tool can carry it across for you. Every RDM is a separate decision: convert it to a virtual disk if the size and performance allow, migrate the data at the application layer instead, or keep that workload where it is for now. Physical-mode RDMs used for shared-disk clustering are the hardest case, because the cluster, not just the VM, has to be rebuilt on the target.
• Fault Tolerance. FT-protected VMs do not have an equivalent on most destinations. The honest question is whether the workload still needs continuous availability at all, or whether it was enabled years ago and never revisited. Often it is the latter, and the finding costs you a conversation rather than an engineering effort.
• Shared-bus disks. These signal a guest cluster (typically Windows Failover Clustering or Oracle RAC). The workload will need its clustering rebuilt on the target rather than converted, so treat every shared-bus group as its own mini-project with its own test plan.
• USB passthrough. Usually a licence dongle for a line-of-business or engineering application, and usually the last thing anyone remembers. It needs either a network-attached USB solution on the target or a licence-model change with the software vendor, and vendors can take weeks to respond, so raise it in week one rather than week ten.
• Open snapshot chains. Rarely a blocker, frequently a nasty surprise. Long chains slow every copy operation and occasionally fail mid-migration. Consolidating them before you start is free and shortens your cutover windows.
• Monster VMs. The largest handful of VMs usually dominate the cutover schedule out of all proportion to their number. Knowing which they are lets you schedule them into their own windows instead of discovering the problem during a wave.

A useful sanity check on the licensing figure: the analyzer counts physical cores across hosts because that is what per-core subscriptions bill, which is often very different from the vCPU total your team quotes from memory. If the two numbers disagree sharply, the physical-core figure is the one your renewal quote will be built on.

What to do with the output

The assessment is most useful as the opening section of a migration plan rather than as a standalone document. In practice three things come straight out of it. The core count feeds the 3-year TCO calculator, so the cost comparison rests on your real estate rather than an estimate. The blocker list becomes the scope-reduction conversation: powered-off VMs and orphaned templates are workloads you can delete rather than migrate, and it is common for that alone to remove a tenth of the estate before anyone writes a runbook. The remainder, the genuine blockers, becomes your risk register, and each item should have a named owner before the pilot starts.

Two habits make the result meaningfully more accurate. Export from RVTools during normal working hours rather than overnight, because powered-off and suspended VMs look different at 3am and you want the estate as it actually runs. And re-run the analysis after the cleanup pass: teams routinely find the second report is materially smaller, which is both a morale point and a better basis for the timeline you commit to.

If the verdict is that the estate is larger or messier than the runway allows, that is a scheduling answer rather than a defeat. The renewal planner will tell you whether the reduced scope fits before the contract decides for you, and the switching cost calculator puts a number on the move for the business case. If you have not settled on a destination yet, the Alternative Finder ranks the options against your constraints rather than in the abstract.