What a VMware to Proxmox VE migration involves
A VMware to Proxmox VE migration moves virtual machines from ESXi hosts or a vSphere environment onto a Proxmox VE cluster that you operate. The work goes beyond copying disks. Each VM's firmware type, disk controller, network adapters, guest drivers and boot configuration must map to KVM equivalents, and the guest operating system has to boot cleanly on the new virtual hardware. Projects usually start with a trigger such as a licensing change that alters the cost of staying on VMware, a hardware refresh that forces a platform decision, or a support deadline on current hosts.
The target cluster must exist before any VM moves. Decide the node count, shared or replicated storage, VLAN layout and backup target first, then confirm the cluster has enough capacity to run the pilot workloads with headroom. Migrated guests need the same network reachability and storage performance they had on ESXi, so verify both before the first production VM is imported. Teams often underestimate how much of the effort sits in this preparation and in mapping dependencies between VMs.
Check the source version before choosing a method. The Proxmox VE import wizard, available since Proxmox VE 8, is documented as tested with ESXi 6.5 through 8.0. Confirm the exact ESXi or vCenter version in your estate against that range. If a host falls outside it, OVF export or disk import may still work, but that path needs its own pilot. Also inventory VMs with snapshots, encrypted or shared disks, and passthrough devices, since each usually needs a separate test.
In-house or partner? Teams with Linux and virtualization experience and a small estate, where most VMs are standard and change windows are flexible, often run the migration themselves with a pilot group. Larger estates with many interdependencies, tight change windows or regulated workloads often bring in a partner for planning, dependency mapping and cutover support. Whichever route you choose, require a documented pilot result and a tested rollback plan before the production cutover begins.
What the work includes and what you receive
The migration runs as a set of work streams that feed a staged cutover, and each one ends in a document or verified result you keep. The list below shows what is done and what you receive at the end.
VM and dependency inventory
Every VM, its disks, network interfaces, guest OS, and the services, databases and external systems it depends on are recorded before any move is planned. This is where hidden dependencies such as hard-coded IP addresses, licensed software tied to hardware IDs, and backup agents are found. Check that the inventory covers VMs that are powered off or rarely used.
Target cluster readiness check
The Proxmox VE cluster is checked for node sizing, storage capacity and type, network bridges and VLAN paths, and backup targets before any guest is imported. The check confirms that the target storage can hold the converted disks with headroom and that the source and target networks can reach each other during transfer. Ask for the readiness results in writing.
Import method selection
Each VM is assigned one import path: the integrated ESXi import wizard, OVF import, qm disk import, backup restore, or attach-and-move. The choice depends on guest OS, disk format, downtime allowed and whether the source host stays reachable. Confirm the ESXi version of your hosts against the tested range in the Proxmox documentation before choosing the wizard.
Guest driver and network changes
Each guest OS is adjusted so it boots and networks correctly on the new virtual hardware, including storage controller drivers, network adapter drivers, guest tools removal, and interface naming. Windows and Linux guests need different steps, and some guests need network configuration reapplied. Test each OS family on a copy before it reaches production.
Pilot moves
A small set of representative VMs is moved first, covering each guest OS family, storage type and network segment in your estate. Pilot results record boot behavior, application checks, performance and rollback timing. Use the pilot findings to confirm or change the import method and runbook steps for the production waves.
Staged production cutover with rollback
Production VMs move in planned waves, each with a defined change window, freeze point, validation steps and a rollback path that restores the source VM. Cutover order follows the dependency map so that databases and identity services move before the applications that rely on them. Confirm with your change board how many waves are planned and how each one is approved.
Migration runbook per wave
Each wave has a runbook listing the exact steps, owners, commands, timing checkpoints, validation tests and go or no-go criteria. Operators follow the same document during the change window, which keeps the cutover repeatable across waves.
VM mapping register
A register maps each source VM to its target VM ID, Proxmox node, storage location, network bridge or VLAN, import method and wave. It becomes the reference for audits, capacity planning and later support, so keep it under version control with your other infrastructure records.
Validated pilot results and rollback procedures
Pilot results document what was tested, what passed, what failed and what was changed, along with written rollback procedures for each VM class. Rollback steps are tested in the pilot so that the team knows how long a restore takes before the first production wave starts.
Post-cutover checks and handover notes
After each wave, checks confirm service health, backup jobs, monitoring coverage and access controls on the moved VMs. Handover notes describe the final configuration, open issues, decommissioning steps for the VMware environment and the operating procedures your team will follow.
What drives cost and duration
Each row names one factor that changes the effort of a VMware to Proxmox VE migration, why it moves the estimate, and a practical way to keep it under control.
| Driver | Why it changes effort | How to keep it down |
|---|---|---|
| Number and type of VMs | Every VM needs its own inventory, import, boot test and validation. Large database or ERP guests need longer test windows than small utility servers, so a count alone understates the work. | Classify VMs into tiers such as simple, standard and business critical, then group them into migration waves so each wave has a similar test profile. |
| Guest operating systems and drivers | VMware tools and paravirtual SCSI or vmxnet3 drivers must be replaced with virtio drivers and QEMU guest agent settings. Older or unsupported OS versions may fail to boot or need driver work before the move. | Standardize on a short list of supported guest OS versions and build reference images with virtio drivers and the guest agent before the first pilot move. |
| Disk sizes and total data to move | Import time and storage capacity both scale with provisioned and used disk data. Multi-disk VMs, thin versus thick layouts and snapshot chains add conversion steps and check time. | Consolidate snapshots and remove stale disks before export, and inventory total capacity per wave so the Proxmox VE storage pool has room for both source copies and targets. |
| Network complexity | VLAN tags, distributed switch port groups, MTU settings and firewall rules must map to Linux bridges, VLAN-aware bridges or SDN zones in Proxmox VE. Each mismatch surfaces as a reachability fault during cutover. | Document every port group and its VLAN, MTU and firewall policy in one mapping sheet, then build the target bridges and test reachability in a pilot network before any production move. |
| Dependencies between applications | Multi-tier applications, shared databases, licence servers and directory services must move together or be bridged across both platforms during coexistence. Each dependency adds test scope and rollback planning. | Map application dependencies with the owners before wave planning, and move each application stack as one unit rather than moving individual servers independently. |
| Number of environments and change windows | Development, test, staging and production each need their own import and validation pass. Limited change windows force smaller waves and more coordination with business owners. | Move non-production environments first to prove the runbook, then reuse the same steps for production with a fixed rollback procedure for each window. |
| Compliance evidence needs | Assessors may expect records of what moved, when, who approved it, how integrity was checked and how access changed. Gathering that evidence after the fact takes extra time per system. | Agree the evidence list with your assessor before the pilot, and capture change tickets, checksums or validation results and configuration exports as each wave completes. |
| Proxmox VE edition and cluster size | Cluster node count, shared storage choice and HA design determine how much testing is needed before guests are trusted on the platform. Support tier affects who you call during cutover, not the migration steps themselves. | Confirm node count, storage backend and subscription tier in writing before scoping, and size the pilot cluster to match production so test results carry over. |
Project phases and outputs
The migration runs in ordered phases, and each phase closes with a written output that the next phase depends on, so the move stays controlled from inventory to decommissioning.
Inventory and classify every workload
We catalog virtual machines, their disks, network attachments, guest operating systems, licensing dependencies, backup jobs and owners, then classify each one by business criticality and migration difficulty. The closing output is a reviewed inventory with a named owner and cutover constraints for every workload, which gates readiness work.
Prepare the target cluster
We confirm the Proxmox VE cluster design, including the high availability and shared storage decisions covered on the sibling pages, network mapping to VLANs, and backup targets. Done means the cluster passes acceptance checks for quorum, storage, networking and restore testing, and the design is signed off by your team before any guest moves.
Select the import method per workload
For each workload we choose among the ESXi import wizard, OVF import, disk import with qm disk import, backup restore or attach-and-move, based on guest OS, disk layout and downtime tolerance. The output is a method decision record per workload that lists required driver, network and boot changes, which gates the pilot.
Run pilot moves on non-critical virtual machines
We migrate a small set of non-critical virtual machines end to end, including boot, driver and network changes, monitoring and backup verification. Each pilot closes with a runbook update and a documented result for every check, and the wave plan does not start until the pilot results are accepted by the application owners.
Plan migration waves
We group the remaining workloads into waves by dependency, owner, maintenance window and risk, then agree the order and the rollback criteria for each wave. The output is an approved wave plan with a rollback trigger for each group, which gates the production cutover for that wave.
Cut over production with rollback
For each wave we perform the final sync or restore, switch services to the Proxmox VE guest, validate application function and keep the VMware copy available until the rollback window closes. A wave is complete when owners sign off on functional tests and the rollback window has passed without a triggered reversal.
Decommission the hypervisor
Once all workloads have run stably on Proxmox VE, we remove VMware-specific tooling, backups and access, retire ESXi hosts and vCenter, and document the final inventory. Done means a signed decommissioning record that confirms no production dependency remains on VMware and that the handover to your operations team is complete.
What usually goes wrong
Most failed VMware to Proxmox VE moves fail in predictable places. The risks below are the ones to plan for before the first guest is converted, along with the checks that catch them early.
Lost network configuration and MAC changes
Imported guests often come up with a new virtual NIC, a new MAC address, or no interface mapping to the right Proxmox VE bridge or VLAN. Static IP settings, DHCP reservations, firewall rules and license bindings tied to MAC addresses can then break. Prevent this by recording each guest's NIC settings before cutover, mapping source port groups to Proxmox VE bridges, and proving connectivity on a pilot guest first.
Missing virtio and guest tools drivers
After disk conversion, Windows guests may fail to boot or lose disk and network access because the storage and network drivers they need are not the ones Proxmox VE presents. Linux guests can have a similar problem with initramfs images that lack virtio modules. Prevent this by installing virtio drivers before migration, confirming the boot disk controller type, and testing boot on representative Windows and Linux guests.
BIOS and UEFI boot mode mismatches
A guest built with UEFI firmware and a GPT partition layout will not boot if it is created with SeaBIOS, and the reverse also fails. The firmware type, EFI disk and boot order must match what the guest was built with on VMware. Prevent this by checking the source firmware setting for every guest in the inventory and matching it in the target VM definition before the first boot test.
Snapshots and independent disks
Guests with existing VMware snapshots carry delta chains that may not convert cleanly, and independent disks are excluded from snapshots and backups in ways that can surprise teams. Either can leave a guest with a stale or incomplete disk after import. Prevent this by consolidating snapshots, listing independent disks per guest, and confirming each disk's contents against the running source before the copy starts.
Backups that were never restore-tested
A backup job that reports success does not prove the guest can be restored, especially for databases, domain controllers and application servers that need consistent state. Restore failures often surface only during an emergency. Prevent this by restoring a sample of each guest class into an isolated Proxmox VE network, checking that the application starts, and recording the result before any source disk is removed.
Cutovers without a rollback path
A cutover that deletes or overwrites the VMware copy leaves no way back if the migrated guest fails under production load. Teams then troubleshoot under pressure with no working fallback. Prevent this by keeping each source VM powered off but intact until its target has run through agreed acceptance checks, and by writing down the rollback steps and owner for each wave.
Costs after cutover
This table separates one-time migration costs from recurring Proxmox VE costs after cutover, showing who pays or does the work and what changes the amount.
| Cost component | Who pays or does the work | One-time or recurring | What drives it |
|---|---|---|---|
| Proxmox VE subscription | Your organization pays Proxmox Server Solutions | Recurring, billed per year | Socket count and tier. Community 120, Basic 370, Standard 550 and Premium 1,100 euros per socket per year (Proxmox VE pricing page) |
| Subscription tier differences | Set by the Proxmox VE subscription tiers | Recurring, part of the subscription | Features are the same in every tier. Tiers differ in support tickets, response times and enterprise repository access. Choose by support need. |
| No-subscription repository | Your platform team applies updates | Recurring staff effort, no license fee | Suited to testing and non-production use. Production patching from this repository needs your own testing and change control. |
| Proxmox Backup Server | Your team or partner builds and operates it | One-time build, recurring storage and operations | Backup capacity, retention, off-site copies and hardware. Confirm with Proxmox whether any subscription applies to your setup. |
| Support staff time | Your internal platform and operations team | Recurring | Host and guest count, skills coverage and on-call load. Vendor support response depends on your subscription tier. |
| Patching and upgrades | Your team, or a partner under a support retainer | Recurring | Release cadence, cluster size, maintenance windows and repository choice. Plan major upgrades before Debian support ends for each release. |
| Current VMware renewals | Your procurement and finance teams | Recurring comparison, not a Proxmox cost | Compare Proxmox subscription lines with your current VMware licensing and support renewals in your own quote and contract. |
How the work changes by starting point
Use this path when the source hosts run ESXi within the range Proxmox VE tests against and the team can reach them over the network. The integrated import wizard reads VM configuration and disks from ESXi, so the main effort is planning, not conversion.
- Test first: the ESXi import wizard on a non-critical VM with a representative disk layout.
- Confirm the exact ESXi release against the Migrate to Proxmox VE wiki, which documents testing with ESXi 6.5 through 8.0.
- Plan driver and network changes for each guest, since virtual hardware such as network adapters and disk controllers differs after import.
- Effort concentrates in cutover sequencing, guest validation and rollback steps rather than in the import itself.
- Ask the partner to quote per-VM validation work separately from the wizard runs.
Use this path when VMs are managed through vCenter. Access and inventory run through vCenter, so the team must decide how Proxmox VE reaches the source data and who holds the credentials for the duration of the move.
- Test first: the import path that connects to the source inventory, confirming that the wizard can see the VMs you intend to move.
- Plan a read-only service account in vCenter and remove it after the migration window.
- Map vSphere folders, resource pools and port groups to Proxmox VE pools and bridges or VLANs before the first move.
- Expect more effort in network design than in disk conversion, because port group mappings drive guest connectivity.
- Confirm with your vSphere administrators which VMs use features that need separate handling before you begin.
Use this path when the source ESXi release falls outside the range the import wizard is documented against. The wizard may still work, but the team should not assume it does. Export or backup-based methods become the primary route.
- Test first: OVF export and disk import with the qm disk import command on one VM from the oldest release in your estate.
- Compare an OVF export with a backup-based restore for the same VM and keep the faster method that produces a bootable guest.
- Budget more validation time for each release family, because disk formats and guest tools may differ.
- Ask the partner whether the older release was tested in the pilot, and what fallback applies to VMs that fail import.
- Confirm the vendor support position for the older ESXi release in your own contracts before you schedule moves.
Use this path when VM disks sit on SAN LUNs that Proxmox VE hosts must access directly. Storage design, multipath and LUN mapping become part of the migration, and they usually take more effort than the VM conversion itself.
- Test first: attaching a mapped LUN to a pilot Proxmox VE node and running a disk import from it to a target storage pool.
- Confirm which storage backends your target design supports, including iSCSI, NFS and LVM, against the Proxmox VE administration guide.
- Plan LUN masking and zoning changes with your storage team, and schedule them outside the cutover window.
- Verify that multipath settings are consistent across all Proxmox VE nodes before any production disk is copied.
- Ask the partner to quote storage work and migration work as separate line items.
Use this path when the source and target networks have no direct route, or when change control requires evidence for every move. Media transfer and evidence collection add steps that the other paths do not have.
- Test first: an OVF or backup export carried across the approved transfer media, then restored into the isolated Proxmox VE pilot.
- Record checksums, transfer logs and approval records for each VM, since reviewers will ask for them.
- Plan package delivery for the Proxmox VE repositories and updates through your approved process, because public repository access may be unavailable.
- Allow time for approvals at each media transfer, which often matters more than technical effort.
- Confirm with your compliance lead which evidence format your auditors accept before the first move.
What you need to provide
Before work starts, the client supplies the inputs that every later phase depends on. The most important is a current VM inventory that lists each virtual machine with its operating system, application, owner, criticality, dependencies and the data it holds. Without named owners, nobody can approve a pilot move or sign off a cutover, so the inventory should name a person for each workload, not a team alias. Access to the ESXi hosts or vCenter, with a read-only account for discovery and an account with rights to export, plus access to the target Proxmox VE cluster, should be arranged early.
Network and storage details come next. Provide a documented network and VLAN map showing which port groups on the source map to which bridges or VLANs on Proxmox VE, along with IP addressing, gateways and firewall rules that cross those segments. On the target side, confirm free capacity for every disk being moved, plus headroom for conversion, because imported disks are written to the target before the source copy is retired. Confirm which storage backends the target will use, such as LVM, ZFS, NFS or Ceph, since that choice affects how disks are imported and how they are protected.
Every VM in scope needs a verified backup copy taken before the first pilot. This gives the team a rollback point if a disk import or driver change fails. Change windows must also be agreed with each application owner, including freeze periods for month-end, batch jobs or regulated reporting. Name the people who approve pilots and cutover, and agree how long they have to respond during a window.
The client also makes several decisions that shape the plan. Decide the target storage layout, including which pool holds which workload class. Decide the HA design for migrated guests: whether they need the cluster's high availability features, which requires at least three nodes and shared storage, or whether restart on a single host is acceptable. Decide which VMs stay on the source platform during the transition, typically those with licensing, vendor or hardware dependencies. Record each decision in writing, because changing one late usually means re-testing pilots.
Frequently asked questions
How much does a VMware to Proxmox VE migration cost?
The cost depends on the scope of the migration, and no fixed figure applies to every environment. The main drivers are the number and size of virtual machines, how many of them have custom drivers or licensed software that needs rework, the network and storage design on the Proxmox VE side, and how many pilot and cutover rounds your change process requires. Migration effort is typically a one-time cost, while Proxmox VE subscriptions are priced per CPU socket per year. Proxmox VE subscription tiers were listed on the Proxmox pricing page at 120 euros for Community and up to 1,100 euros for Premium per socket per year, and the software itself can run without a subscription. Ask for a quote built from a written scope that lists each workload group, its dependencies and the acceptance tests.
How long does a VMware to Proxmox VE migration take?
The duration depends on scope, so treat any single number with caution. Timelines are driven by the count of virtual machines, the number of distinct operating systems and application stacks, the amount of data to move, the availability windows each application allows, and whether you need a pilot phase before production. Small estates with simple Linux guests move faster than estates with Windows servers, databases and tightly coupled application tiers. Ask for a written schedule that separates discovery, pilot moves, each production wave and the rollback window, and confirm the assumptions behind each phase before work starts.
Can our team run the migration without an outside partner?
Yes, many teams migrate in-house, and Proxmox VE is open source with documented import methods, so no license is needed to start. The question is whether your staff have the time and skills for the work. Your team needs working knowledge of Linux, KVM, networking, storage and the applications being moved, plus a test environment and a rollback plan. A fixed-scope partner engagement can cover planning, pilot moves, driver and network changes, cutover support and documentation, so your staff can focus on application owners and acceptance testing. Compare both options against the same written scope.
What does the work require from our staff?
Expect to commit application owners, a network and storage contact, a change manager and someone with administrative access to both VMware and the Proxmox VE hosts. Application owners must confirm what each system does, which data must be preserved, and how they will test it after the move. Your network team must approve VLAN and IP mappings, and your security team should review access and authentication changes. Ask the implementation partner to list these roles and hours in the written scope so that staff allocation is planned rather than discovered during the cutover.
Can the ESXi import wizard move every virtual machine?
No. Proxmox VE's import wizard, available since Proxmox VE 8, can import virtual machines directly from VMware ESXi, and it was tested with ESXi 6.5 through 8.0. However, it does not cover every guest, disk layout or configuration. Machines with unusual disk controllers, encrypted disks, snapshots, virtual hardware features or non-standard firmware may need OVF import, disk import with the qm disk import command, a backup restore, or an attach-and-move method. Confirm the ESXi version in your estate and run a pilot on representative machines from each group before you plan the production waves.
What happens to VMware Tools and guest drivers after the move?
VMware Tools is tied to the VMware hypervisor and should be removed or disabled as part of the guest cleanup, while Proxmox VE guests need the appropriate virtio drivers and guest agent for disk, network and shutdown behavior. Windows guests often need virtio drivers installed before first boot, and Linux guests usually need the network and disk configuration adjusted. Plan driver installation, network interface renaming, and boot checks as explicit steps in each pilot, and confirm the exact driver and agent packages your guest operating systems require against the Proxmox VE migration documentation before the production waves.
How does rollback work if a production cutover fails?
Rollback should be designed before the first production move. The usual approach keeps the source virtual machine intact and powered off, not deleted, until acceptance testing is complete, so you can restart it on VMware if the target fails. Each wave needs a defined go or no-go checkpoint, a maximum rollback window, a record of DNS, IP and firewall changes, and a named decision owner. Data written to the target during a failed cutover must be reconciled before the source is restarted. Ask the partner to document rollback steps for each workload group in the written scope.
How DeployOpen delivers this migration
DeployOpen plans and runs VMware to Proxmox VE migrations inside your own infrastructure, from inventory and pilot moves through a staged production cutover. Engagements are fixed-scope, with the scope, deliverables and timeline agreed in writing before work starts.
How we scope
- The written scope lists which VMs, templates and hosts are in and out of the move.
- Inventory covers guest operating systems, disk formats, network attachments and VMware-specific dependencies such as tools and snapshots.
- The scope names the import method for each workload: ESXi import wizard, OVF, disk import or backup restore.
- Pilot workloads and acceptance criteria for each pilot are agreed before any production guest is touched.
How we build
- We stand up the target Proxmox VE cluster, storage and network layout in your environment, as defined in the scope.
- Pilot VMs are imported, then driver, boot, network and storage changes are made and tested against the agreed criteria.
- Rollback steps are written and rehearsed for each wave so a failed guest can return to VMware without data loss.
- Production waves are cut over in stages, with the cutover window and sequence recorded in the change plan.
How we hand over
- Handover documents the migration runbook, per-VM import method, changed settings and the final inventory of moved guests.
- Your team receives a record of pilot results, cutover outcomes and any guests left on VMware with the reason.
- Access, administrative roles and the Proxmox VE subscription or repository decision are documented for your team to own.
- We walk your operators through the day-two tasks needed to run the migrated guests.
How we support
- Post-cutover support covers a stabilization period defined in the written scope, including fixes to migration-related issues.
- Ongoing support, upgrades and continuous testing are available as a DeployOpen retainer after handover.
- Proxmox VE subscription support is a separate contract with Proxmox Server Solutions and is not included in DeployOpen fees.
- Retainers can cover later Proxmox VE upgrades, backup restore tests and changes to migrated workloads. Confirm terms in the quote.
