VMware to Proxmox VE migration

Scope and decision record

Begin with a workload inventory and business owners. Record vCenter/ESXi and Proxmox versions, VM count, guest OS/support, CPU/memory, used and provisioned disk capacity, firmware, controllers, VLANs, IP/DNS, time synchronization and application dependencies. Agree acceptable downtime, RPO/RTO, maintenance windows and acceptance owners.

Compare keeping VMware, migrating to Proxmox and other options against requirements, support, skills, application certification and licensing. Hardware and subscription savings are not guaranteed; include operational and backup costs. OUTSEED scopes assessment, pilot, wave execution and handover separately.

Source constraints and prerequisites

Review snapshots and disk chains, VMware vSAN-backed disks, encrypted disks, virtual TPM/key dependencies, secure boot, raw device mappings, passthrough/GPU/USB, independent/shared disks, linked clones and application clustering. These can prevent a direct importer path or require a separately validated procedure. Do not assume feature equivalence.

Preserve tested backups and recovery keys under the customer’s approved handling process. Do not delete snapshots, decrypt workloads, remove tools or change drivers merely because a checklist mentions them; first select the method, verify rollback and approve the change. Current vendor import guidance lists version-specific support and limitations.

Proxmox target design

Size CPU, RAM and storage using observed workload peaks and headroom for one host failure where HA is required. Review CPU compatibility across migration nodes, storage IOPS/latency/capacity, thin provisioning, overcommit and storage snapshot support.

Design bridges, VLAN tagging, bonds, MTU, routing, firewall and management isolation. Map source port groups to target networks explicitly. A shared storage label is not proof that every node sees the same data. Validate multipath and supported SAN/NAS plugins when applicable.

Agree cluster quorum/Corosync design, HA behavior, fencing, backup and restore procedures. HA restart after host failure is not lockstep fault tolerance. Do not choose a two-node design without a reviewed quorum strategy or assume asynchronous replication has zero data loss.

Guest readiness: Linux and Windows

Match BIOS/SeaBIOS or UEFI/OVMF and plan EFI variables/boot entries. Verify VirtIO storage/network drivers and boot initramfs, filesystem/mount identifiers, network naming, static addresses, DHCP reservations and time synchronization. Preserve the application’s identity and reactivation/licensing requirements.

For Windows, stage vendor-supported VirtIO drivers and follow the documented boot-controller transition; an immediate controller switch can make the guest unbootable. For Linux, verify that required drivers are in the installed kernel/initramfs rather than assuming all distributions behave alike.

Decide when to remove VMware-specific guest tools and install the QEMU guest agent with the rollback path in mind. Guest-agent presence aids management but is not proof that backups are application-consistent.

Select an import method and pilot

Options include the supported Proxmox ESXi importer, OVF/OVA or disk import, and backup restore/application-level migration where supported. Verify exact installed versions, source datastore types and target storage support. Direct vCenter/ESXi discovery in OUTSEED is not the Proxmox importer itself.

Use a representative non-production pilot including one Linux and one Windows workload when those platforms exist. Test a recovery from your actual backup product. Measure shutdown, copy/import, first boot and application-validation time; large disks and bandwidth/API limits affect the window.

Live-import still involves source shutdown and can have additional recovery/data-loss considerations if the import fails. Do not advertise cross-hypervisor live migration or zero downtime. Prefer a controlled cold pilot until the chosen method and recovery path are demonstrated.

Plan migration waves and dependencies

Group workloads around dependencies, business criticality, data consistency and operational ownership—not merely VM count. Identify databases, identity, DNS, load balancers, firewall rules, storage and external integrations. Agree a freeze point and stakeholder communications.

A wave checklist names source VM, target VMID/node/storage/bridge, version-specific method, backup reference, driver/boot prerequisites, operator, approver, expected duration, abort thresholds, validation checks and evidence location. Keep source and target inventories separate to avoid selecting the wrong workload.

Cutover and rollback decision points

Confirm a recoverable backup and capacity before the approved window. Quiesce applications where required, capture a final baseline and stop the source according to the application consistency plan. Import/restore with the reviewed method, confirm mappings and boot the isolated target before enabling production traffic.

Never run source and target with the same production identity/IP/storage access simultaneously. Do not attach both hypervisors to the same writable guest disk without a supported design. Preserve source rollback materials until formal acceptance.

Define when rollback is still possible and who approves it. Once the target accepts writes, powering the source back on can lose or fork data. Plan how to reconcile target-side changes; a snapshot is not automatically a safe database rollback. Record an unresolved state if the final data owner cannot verify consistency.

Validation and acceptance evidence

Check firmware/boot, guest drivers, services, disk/filesystem state, network/VLAN/DNS/routes, time, authentication, scheduled jobs and monitoring. Application owners execute agreed synthetic transactions, data-consistency checks and integration tests.

Compare baseline and target performance under a representative workload; distinguish cache warm-up, CPU model and storage differences. Confirm backup schedules and perform an isolated restore test. HA/live migration tests require separate approved scope and adequate capacity.

Document pass/fail/unknown for each acceptance criterion, observed timings, versions, access scope and evidence references. A successful import or running VM is not application acceptance. Obtain owner sign-off before source decommission and coordinate disposal of backups/keys according to retention policy.

Deliverables and operational handover

Deliver the source-to-target inventory/mapping, readiness findings, target design, pilot results, approved wave/cutover/rollback plans, completed validation record, known exceptions, backup/restore evidence and operating runbooks.

Define ownership of Proxmox subscriptions, guest OS/application support, monitoring, patching, credentials, certificate renewal and capacity. Provide operator training and a support escalation path. Do not imply vendor partnerships or certifications that have not been established.

Using the OUTSEED MCPs

Use VMware inventory.read for VM discovery, Proxmox inventory.read for VM/storage/cluster status and Linux inventory.read on authorized guests for baseline evidence. Supplement with manual disk/controller/encryption/snapshot review because this preview does not collect all migration constraints.

Use migration.assess only with explicit reviewed records; it flags blockers, remediation and unknowns. evidence.compare reports changed top-level fields. These tools generate assessment evidence, not an automated migration plan accepted by a vendor or application owner. No tools here execute disk conversion, shutdown, import or infrastructure writes.