A VMware vSphere to Proxmox VE migration needs a licensing inventory, a disk-transfer method for each guest, and an acceptance plan for the new cluster. The disk importer handles part of that work. It does not decide application support, rebuild backup coverage, or establish that a guest can recover after its destination host fails.
This guide covers the move itself using vendor documentation. If the platform decision is still open, start with Proxmox VE vs VMware ESXi, then return here to plan the migration.
The licensing models are structurally different
Proxmox VE’s licensing statement identifies the software as AGPLv3. Its optional subscriptions provide repository access and support entitlements rather than unlocking migration or HA features.
For a subscription budget, count occupied physical CPU sockets across the target cluster. Proxmox’s subscription page prices coverage per socket and requires the same subscription level across subscribed cluster nodes. Check the current plans, ticket allowances, and coverage hours when preparing the budget.
Broadcom’s VCF and VVF core-counting guidance uses physical cores with a minimum of 16 licensed cores per physical CPU. A dual-socket host with eight cores per CPU therefore counts as 32 licensed cores under that rule. That is a capacity calculation, not a price quotation or a rule for every historical VMware contract.
Keep three entries in the migration budget: the existing agreement through cutover, any temporary overlap while both estates exist, and the target’s ongoing support. Ask the relevant supplier to confirm the entitlements that apply to the actual agreement. Moving a VM’s disks is not evidence that its operating-system or application licence transfers unchanged.
Inventory the guests before choosing a move path
Build one worksheet per guest with its disk sizes and datastores, BIOS or UEFI mode, disk controllers, network adapters, VLANs, and configured CPU and memory. Record snapshots, disk encryption, virtual TPM use, and physical device dependencies. Add application-level acceptance checks beside the infrastructure settings.
Keep the transfer plan specific. A guest with several disks on different datastores needs every disk accounted for; a bootable system disk alone is not a complete migration. Record the source VM identifier and the intended target identifier so the acceptance record remains unambiguous.
Group related services into cutover batches. A database, application server, and authentication dependency may require coordinated downtime even if each imports successfully by itself. Decide who can approve application readiness, when writes will stop on the source, and how long the old environment must remain recoverable. These are proposed planning steps, not measured migration durations.
Migrating existing virtual machines: choose the path
The official migration guide documents integrated import, OVF import, and alternatives such as restoring through a compatible backup product.
| Move path | When to consider it | Preparation to record |
|---|---|---|
| Integrated ESXi importer | The source host and VM storage are supported by the installed importer | Host access, disk eligibility, destination storage, and network mapping |
| OVF export and import | An export-based handoff suits the migration window | Export completeness, available staging space, and the target VM settings |
| Backup-based restore | The existing backup product documents a usable Proxmox or bare-metal restore method | Product support, recovery media if needed, and a verified restore procedure |
Select the method using a representative noncritical guest before booking the remaining cutovers. Record the actual elapsed transfer and validation time in your own migration worksheet. Estimate later windows from that evidence, disk volume, and application checks, with allowance for guests that differ.
An export or backup is useful only when it can be restored. Keep the source guest recoverable until the destination’s disks, services, and backup path have been accepted.
ESXi import limits that affect the cutover
The Proxmox migration documentation describes important constraints on the integrated ESXi path. Read the guide for the installed release before starting:
- The source guest is shut down for migration. The live-import option still involves downtime on the ESXi source.
- vSAN-backed disks cannot be imported directly by the documented ESXi importer; the guide suggests moving them to another datastore first.
- Encrypted VM disks must have their encryption policy removed before that import path can read them.
- Source snapshots can substantially slow the transfer.
- Connecting through vCenter can reduce import performance compared with a direct ESXi connection.
- Special characters in datastore names can cause import problems.
VMware virtual TPM state is another migration dependency. The guide does not provide a transfer of that state to Proxmox. Preserve guest recovery keys and follow the guest operating system’s documented encryption procedure before changing its boot or TPM arrangement.
Resolve these prerequisites while the old guest is still available. Do not discover that the only decryption key is unavailable after committing to a cutover. Snapshot consolidation, datastore moves, and encryption changes also need their own source-side backup and maintenance plan.
Finalize the imported guest configuration
Compare the imported configuration with the inventory before its first production boot. Confirm firmware mode, boot order, every disk, and the destination bridge and VLAN. A guest attached to a reachable but incorrect network can look healthy from its console while remaining unavailable to its users.
The QEMU/KVM documentation explains VirtIO storage and networking and the QEMU guest agent. A Windows guest needs the appropriate VirtIO driver before it can boot from a newly selected VirtIO disk controller. Plan controller changes as a separate step if the imported guest initially needs a compatible emulated controller.
Review VMware Tools removal and QEMU guest-agent installation as separate guest maintenance tasks. The agent does not replace storage or network drivers. Enable its corresponding VM option after installing it in the guest.
For a cluster, choose a virtual CPU model that the planned destinations can support. A guest that boots on the first host still needs an eligibility check for the other hosts. Record hardware-dependent guests separately so ordinary migration expectations are not applied to them.
Cutover checks and rollback boundaries
Use a short acceptance record for each move. The following sequence is a planning checklist to adapt to the application, rather than a claim that any guest has been validated here.
- Confirm a recoverable source backup and any encryption recovery material.
- Stop application writes and shut down the source according to the selected migration procedure.
- Import or restore the guest, then compare the target disks and settings with the inventory.
- Boot on an isolated network where duplicate service addresses cannot affect production.
- Check application startup, data freshness, authentication, scheduled tasks, and dependent services.
- Connect the accepted target to its intended network and establish backup coverage.
Keep only one authoritative production instance. Once applications accept new writes on the Proxmox guest, turning the old VMware guest back on can discard those changes or create conflicting data. Define how new data would be recovered before describing rollback as simply powering up the old VM.
Proxmox Backup Server verification jobs can check stored backup integrity. Pair them with a restore exercise under a separate VM ID and isolated networking; application recovery remains an acceptance task beyond transferring disks.
Finish with the target cluster’s failure plan
Before importing the remaining estate, complete Proxmox VE cluster planning: voting majority, redundant Corosync links, storage availability, and resource capacity on surviving nodes. Ceph service memory and recovery bandwidth belong in that plan alongside guest memory.
Confirm that the operating procedure covers both planned maintenance and an unavailable host. If cluster configuration becomes read-only or a start returns a quorum error, use the Proxmox no-quorum troubleshooting guide to establish membership and storage state before attempting recovery.
Retire the source only after the agreed retention window and acceptance checks are complete. Keep the inventory, transfer record, backup evidence, and recovery procedure together so the next maintenance operation starts from the configuration that actually moved.
