VMware Migration Checklist: A Practical Guide for SMBs
Most SMB teams approach the Broadcom migration wrong: they start with the platform choice instead of the inventory audit. Here is the actual sequence, from pre-migration planning through post-migration security validation.
By William Bradshaw | April 6, 2026 | 8 min read
Broadcom's VMware acquisition created the largest involuntary IT migration in SMB history. The no-cost ESXi hypervisor that tens of thousands of small businesses had been running in production was discontinued in early 2024, with perpetual licenses eliminated and per-core subscription bundles replacing the pricing model most SMBs had budgeted around. The question stopped being "should we evaluate alternatives" and became "in what order do we do this."
This is the checklist we use when running these migrations. It is organized as a sequence because the order matters. Teams that start with the platform decision before completing the inventory audit consistently discover migration-blocking dependencies they did not know about. For context on why Proxmox has become the default SMB replacement, start with our strategic overview of VMware alternatives. For the low-level technical execution, see our complete ESXi to Proxmox migration guide.
Pre-Migration Audit
Do not touch your hypervisor selection until this phase is complete. The audit defines the scope of what you are actually migrating and surfaces the dependencies that determine which platform you can realistically use.
VM Inventory
- • Document every VM: OS, vCPU/RAM/disk allocation, running services, and who owns it
- • Identify which VMs are production-critical vs. non-critical (this determines migration sequence later)
- • Note disk format: VMDK thin vs. thick provisioned, and whether linked clones are in use
- • Flag any VMs with VMware Tools dependencies or vSphere API integrations. These need a replacement plan before migration
Workloads That May Not Move Cleanly
- • Windows VMs (viable, but require VirtIO driver injection before migration for reliable disk/network performance on KVM)
- • VMs with SCSI passthrough, USB passthrough, or physical device dependencies
- • VMs under compliance scope that reference a specific hypervisor vendor in their audit framework (uncommon in SMB, but verify)
- • Applications with VMware-specific licensing (some ISVs tie license activation to VM hardware fingerprint)
Licensing and Backup Status
- • Record current VMware licensing: contract expiry, renewal date, and what options Broadcom has offered
- • Verify all VMs have current, tested backups before any migration work begins. Not just scheduled, but restoration-tested
- • Identify your current backup tooling: Veeam, Nakivo, or native VMDK snapshots will need to be replaced with Proxmox Backup Server or equivalent
Do not start the platform decision until this inventory is complete. Migrations fail when teams commit to a timeline before they know what they are actually moving.
Platform Selection
Now that you know what you are migrating, you can make an informed platform decision. For most SMBs, this comes down to Proxmox VE vs. Microsoft Hyper-V vs. cloud migration. Here is the criteria matrix:
Proxmox VE
Open-source (AGPL v3), Debian-based, KVM + LXC, native ZFS and Ceph support, full web UI. No host OS licensing cost.
Best for: Teams comfortable with Linux, on-premises workloads, environments where licensing cost reduction is the primary goal. The default choice for most SMBs under 50 employees.
Microsoft Hyper-V
Built into Windows Server. Solid enterprise support path, familiar tooling for Windows shops, good SCVMM integration.
Best for: Environments already running Windows Server on every host, with strong Windows administration skills and no interest in learning Linux.
Cloud Migration
AWS, Azure, or GCP. No on-premises hardware investment, elastic scaling, managed patching.
Best for: Latency-insensitive workloads where capital refresh is overdue. Cloud VM costs ($200-800/month per instance) often exceed on-premises amortization for file servers and local databases.
For a detailed comparison of Proxmox VE against VMware on a feature-by-feature basis, see our Proxmox vs VMware for SMB environments article.
Migration Sequence
The sequence matters. Infrastructure components have dependencies, and moving them in the wrong order creates outages. Follow this order:
Step 1: Lab validation (before any production work)
Install Proxmox on test hardware (or repurpose a non-critical host). Migrate two or three non-critical VMs. Validate networking, storage performance, and backup tooling work correctly before committing to production.
Step 2: Networking first
Configure VLANs on Proxmox Linux bridges to match your existing network segmentation before migrating VMs. Reconfiguring network topology after VMs are running is significantly more disruptive than getting it right at install time.
Step 3: Storage layout and backup infrastructure
Configure your ZFS pool layout (mirror vs. RAIDZ) and install Proxmox Backup Server on dedicated hardware or a separate VM. Confirm backup jobs run and restore correctly before moving production workloads.
Step 4: Non-critical VMs first
Migrate development, staging, and low-criticality workloads. Run them on Proxmox in parallel with the VMware environment for at least two weeks before touching production. This validates your process and builds team confidence before the stakes are high.
Step 5: Production VMs in tiers
Migrate production workloads in dependency order: infrastructure services (DNS, DHCP, AD) before application servers, application servers before end-user workstations. Allow a stabilization period between each tier. A well-planned migration of 10-20 VMs takes 6-12 weeks done responsibly.
Step 6: Decommission VMware only after 30-day parallel run
Do not shut down the VMware environment the same day the last VM migrates. Run both platforms in parallel for at least 30 days to catch anything that only surfaces under real-world load before you lose the rollback option.
The technical migration (VMDK conversion, VM import) is mechanical. The planning (inventory, dependency ordering, cutover sequencing) is where migrations fail.
Post-Migration Validation Checklist
Before you declare the migration complete and decommission VMware infrastructure, work through this validation list:
Performance
- • Baseline CPU, memory, and disk I/O on migrated VMs, then compare to VMware baselines
- • Confirm Windows VMs have VirtIO drivers active (not running on emulated IDE)
- • Verify QEMU Guest Agent is installed and reporting on all VMs
Backups
- • Run a full backup job and confirm all VMs complete successfully
- • Perform a restoration test on at least two VMs: one Linux, one Windows
- • Verify off-site backup replication is active and completing
Security
- • Run a vulnerability scan of the new environment to catch misconfigurations introduced during migration
- • Verify Proxmox management interface is not exposed to the internet (firewall rules)
- • Audit firewall rules. Migration often results in overly permissive rules that were "temporary" during cutover
Documentation
- • Update network diagrams and IP documentation to reflect the new environment
- • Document ZFS pool layout, Proxmox cluster configuration, and backup schedule
- • Update runbooks for any procedures that referenced vCenter or ESXi-specific tools
Running netvuln-tool after migration is a fast way to catch misconfigurations introduced during the transition: things like management interfaces accidentally exposed, services listening on unexpected ports, or firewall rules left open from the cutover window. Getting a clean scan before declaring the environment production-hardened is standard practice.
When to Bring in Help
Most SMB teams can execute a straightforward ESXi to Proxmox migration with good planning and this checklist. There are scenarios, however, where bringing in outside expertise is the right call:
- • More than 20 VMs or multiple ESXi hosts. The coordination complexity scales nonlinearly. Dependency mapping, cutover sequencing, and rollback planning for a larger environment benefit from a structured project approach.
- • Zero downtime requirements. If any workload cannot tolerate a maintenance window for migration, live migration tooling or a more sophisticated staging process is required.
- • Compliance scope. If migrated VMs are in-scope for PCI DSS, HIPAA, or SOC 2, the new environment needs to be validated against those frameworks before the migration is considered complete. A post-migration vulnerability assessment is typically a requirement, not optional.
- • No Linux expertise on the team. Proxmox runs on Debian. If no one on the team is comfortable at the Linux command line, investing in training or bringing in support for the initial configuration is significantly cheaper than a failed migration.
- • Tight deadline driven by a license expiry. Artificial urgency is the primary cause of migration incidents. If your license renewal is approaching and the pressure to rush is building, involving an experienced team to compress the timeline responsibly is worth the cost.
A migration done in 12 weeks the right way is better than one done in 4 weeks with a P1 incident in week 5. If the timeline feels aggressive given your environment's complexity, it probably is.
Need Help With Your VMware Migration?
Whether you are in the planning phase or mid-migration and need a second opinion: we have run this process in production across a range of SMB environments. We can help with everything from audit and planning through post-migration security validation.