Open source
Open code and standard formats: no black box.
VMware to Proxmox migration: a guide to the process
From the pre-migration checklist to go-live: everything you need for a controlled transition, based on our experience as Proxmox Gold Partner #1 in Italy.
No obligation · Real numbers from your environment
8.2
the Proxmox VE version that imports VMs directly from ESXi
0
perpetual VMware licences: subscription only
16
cores licensed at minimum for every CPU on VMware, even smaller ones
- 700+ active customers
- 24h support, every day
- GDPR data kept in Italy
VMware to Proxmox migration approaches
Two approaches cover most scenarios. Six alternative methods are available for specific cases.
Automatic import from ESXi (recommended)
Since version 8.2 (April 2024), Proxmox VE includes an importer that transfers VMs directly from an ESXi host through the web interface. The vendor has tested it on ESXi from version 6.5 to 8.0. The importer reads the VM configuration, maps it to the Proxmox VE model and converts the disks to the format of the target storage. The source VM must be shut down before the import, and the connection goes to the ESXi host: going through vCenter is possible, but it greatly reduces performance.
Ideal for: medium to large environments with standard configurations · Downtime: medium, the VM stays off for the whole import · Complexity: low
Live import (minimised downtime)
A feature of the importer that starts the VM on Proxmox VE while the import is still running: the data needed to boot is transferred first, and the rest follows in the background. The VM on ESXi must still be shut down before the start, so some downtime remains, and I/O performance is reduced in the initial phase. If the import is interrupted, the data the VM wrote after starting is lost: that is why it is tried first on a test VM and avoided on slow or unstable networks.
Ideal for: critical VMs and services in continuous production · Downtime: very low · Complexity: medium
Alternative approaches
Method
When to use it
Downtime and complexity
OVF/OVA import (from the web interface since version 8.3, or with qm importovf)
VMs exported with ovftool or appliances, ESXi versions outside the tested list, no API access to ESXi
Variable downtime · Low complexity
Direct disk import (qm disk import)
Granular control: VMDK conversion to the format of the target storage, raw or qcow2, from a network share
Variable downtime · Medium to high complexity
Attach & Move
VMs with large volumes of data: immediate start from the VMDK on a shared network drive, disk moved while the VM runs
Minimal downtime · High complexity
Restore from backup
Backup solutions with Proxmox VE integration, such as Veeam Backup & Replication from version 12.2
Variable downtime · Medium complexity
Direct cloning
Disk copy with tools such as Clonezilla, booting the source and target VMs from live media
Variable downtime · Medium complexity
Continuous replication with MultiPortal Migrator
VMs that must stay on until the cutover, migrations run by the in-house team
Downtime only at cutover · Medium complexity
With Attach & Move the VM runs on only one hypervisor at a time, never on VMware and Proxmox VE together: two simultaneous boots corrupt the disk.
Guided migration
The four phases of a VMware to Proxmox migration
VMware
vSphere · ESXi
Proxmox VE
HA cluster · PBS
Rollback plan tested before every cutover
-
Phase 02 Installation and configuration of Proxmox VE on the target hardware.
-
Phase 04 Migrations run according to the plan, in the agreed maintenance windows.
- 01 Analysis and planning
- 02 Environment preparation
- 03 Pilot migration
- 04 Production migration and go-live
-
Phase 01 Complete inventory of the virtual machines, with CPU, RAM, storage, operating system, critical applications and network dependencies.
-
Phase 03 First migrations on non-critical VMs, to validate the procedures and measure the real transfer times.
Our team can plan the migration together with you.
Phase 01 · Checkpoint
Analysis and planning
Migration order: non-critical VMs first (test and development), then supporting services, and production workloads last. Transfer times estimated from bandwidth and disk size.
- Complete VM inventory, with allocated resources and dependencies
- Storage mapping: datastores, disk format (thin or thick), active snapshots
- Network documentation: VLANs, port groups, firewall, static IPs, DNS
- VMware licence review: expiry dates and contractual constraints
- Verified backup of every VM, with a restore test on at least one critical VM
- Unnecessary snapshots removed and consolidated
- Cases that block the automatic import identified: disks on vSAN, disks encrypted with a storage policy, datastores with special characters in the name (such as "+"), vTPM with disk encryption
Output: a migration plan document with timeline, VM order, maintenance windows and rollback plan.
Phase 02 · Checkpoint
Environment preparation
Cluster (where planned), storage and network configured consistently with the source environment. Connectivity tested between the two environments. Source VMs prepared before shutdown.
- Proxmox VE installed at the latest available version, with updates applied and the web UI reachable (the ESXi importer requires at least version 8.2)
- Target storage ready, with at least 20% extra space
- Network bridges, VLANs and bonding configured consistently with the source
- Connectivity verified between the Proxmox VE node and the ESXi host (HTTPS, port 443, administrator account), with the host certificate trusted, or verification disabled if self-signed; direct connection to the host, not through vCenter
- Source VMs prepared: VirtIO drivers installed (in the initramfs on Linux), VMware Tools removed, network configuration recorded, static IPs removed on Windows VMs, DHCP reservations updated for the new MAC address
- Migration approach chosen and validated on a test VM
Output: a working Proxmox VE environment, connected to the source environment and ready for the import.
Phase 03 · Checkpoint
Pilot migration
Functional checks in the Proxmox environment: network, storage, applications, performance. Configurations tuned on the results.
- At least 2-3 non-critical VMs migrated and validated
- Real transfer times measured and compared with the estimates
- Applications working, network reachable, acceptable performance
- Any issues identified and solved before production
Output: validated procedures, measured times, team aligned.
Phase 04 · Checkpoint
Production migration and go-live
Continuous monitoring of every migrated VM. Functional validation after the migration. Gradual decommissioning of the VMware environment only once stability is confirmed.
- All VMs running on Proxmox VE
- Functional validation completed for every critical service
- Backup configured on Proxmox Backup Server
- VMware environment kept on standby until stability is confirmed
- Documentation updated with the new architecture
Output: every VM in production on Proxmox VE, VMware environment decommissioned, documentation complete.
After the migration: optimisation and common issues
Once go-live is complete, the migrated VMs need an optimisation pass to perform at their best on Proxmox VE. These are the steps to take, and the most frequent issues with their solutions.
VirtIO paravirtualised drivers. Imported VMs often keep emulated disk controllers and network cards, compatible with the source hardware but less efficient than paravirtualised ones. Switching to the VirtIO SCSI single controller and VirtIO network cards is the change with the greatest impact on performance. On Windows VMs without VirtIO drivers the boot disk stays on the emulated controller, or on IDE or SATA with the manual import: the VirtIO drivers are installed from the official ISO first, then the controller is changed.
CPU and memory settings. CPU type host if every node in the cluster has the same processor model; otherwise a generic x86-64-v2 model or higher, which keeps live migration between different nodes. Ballooning device enabled even when ballooning is not needed: it provides the memory usage statistics reported by the operating system. NUMA configuration checked on the largest VMs.
Disks and storage. VirtIO SCSI single controller with IO thread and discard enabled: discard returns to the storage the space freed by the operating system. The disk format depends on the storage: on ZFS, LVM-thin and Ceph disks are raw, and the storage handles snapshots and thin provisioning; on file-based storage (directory, NFS) the native format is qcow2, which enables snapshots. Automatic backup is set up with Proxmox Backup Server (page in Italian).
Firmware. SeaBIOS for VMs that boot in legacy BIOS mode, OVMF for those in UEFI, with an EFI disk that stores the boot entries.
QEMU guest agent. Installed in every migrated VM: it improves communication between the host and the guest operating system and allows coordinated operations such as a clean shutdown.
Monitoring. Proactive monitoring and alerting on the performance of the migrated VMs, and the new architecture documented.
Common issues and solutions
Issue
Solution
How to fix it
VMs with active snapshots: they slow the import down considerably
Consolidate before the import
Remove unnecessary snapshots; if they are needed, export to OVA
VM on a vSAN datastore: the automatic import from ESXi does not support it
Move or export
Disks on a non-vSAN datastore, or export to OVA and import from the web interface or with qm importovf
Disks encrypted with a storage policy: they cannot be imported
Remove the encryption
Remove the encryption policy before the import
vTPM with disk encryption: the vTPM state does not migrate from VMware
Disable the encryption
Or keep the recovery keys at hand
Datastore with special characters in the name, such as "+"
Rename the datastore
Before the import
API connection limit on ESXi, 503 errors
Serialise the imports
No more than four VM disks at a time; if the block persists, raise or disable the session limit of the ESXi host
The VM does not boot after the switch to VirtIO
Go back to IDE or SATA
Or boot the rescue kernel, install the drivers (in the initramfs on Linux), then switch back to VirtIO
The UEFI VM cannot find its boot entry
OVMF and EFI disk
OVMF firmware, EFI disk configured, boot entry added from the UEFI menu
Degraded performance after the migration: emulated controller and network
Upgrade to VirtIO
VirtIO SCSI single disk controller, VirtIO network; on Windows, drivers from the official ISO before the change
Proxmox vs VMware
Proxmox vs VMware: feature comparison
Criterion by criterion, what changes when you move to Proxmox VE. Costs differ from one environment to another: we estimate them in the free audit.
Criterion
Proxmox VE
VMware (VCF/VVF)
Licence model
Open source AGPLv3 · optional subscription, per socket
Subscription only, per core: at least 16 cores per CPU
Management console
Included on every node: the cluster has no separate management server
vCenter Server, an appliance to install and maintain
Integrated backup
Proxmox Backup Server, same vendor, no extra licence
Third-party products (Veeam and others)
HA, live migration, SDN
Included
Included
Hyperconverged storage
Ceph and ZFS built in, no capacity fee
vSAN: a capacity allowance included, the rest purchased
Features by licence level
All of them, in every subscription: support changes, not the product
Tied to edition and bundle
Without a subscription
The cluster keeps running: only the update channel changes
No licence, no service
VMs and containers
KVM and LXC on the same platform, same console and same backup
VMs only: containers go through separate products, such as Kubernetes
Hardware compatibility
Standard x86 hardware, no rigid list
Strict compatibility lists
Transparency
Open code, inspectable at any time
Closed code: updates and price lists cannot be inspected
Import from VMware
Native ESXi importer since 8.2, including live import
Not applicable
Lock-in
None: open formats, European vendor
Proprietary stack
First-level support
From us, in English or in Italian: Proxmox Gold Partner
Broadcom and its partner network
Business software certification
Less widespread: checked with the vendor before migrating
Broad: many enterprise applications certify only vSphere
Where it is strongest
SMEs, public sector, research, MSPs, predictable costs
Very large integrated VCF stacks, software certification constraints
Sources: Broadcom, "Counting Cores for VMware Cloud Foundation and vSphere Foundation", for the minimum of 16 cores per CPU; Proxmox VE price list for feature parity across the four subscription levels; Proxmox VE 8.2 release notes for the native ESXi import, tested by the vendor on ESXi 6.5 to 8.0.
When staying on VMware makes sense
If critical software is certified only on vSphere, if you use deep VCF features (advanced NSX, stretched vSAN) or if the renewal has just been signed, migrating today may not pay off. We tell you in the assessment, and even then you leave with useful numbers for the next renewal.
Migrating with your own team
MultiPortal Migrator moves VMs from vSphere to Proxmox VE with continuous replication: they stay on until the cutover, and if something goes wrong the VMware VM starts again on its own. The licence is paid per VM, once, and we supply it.
Proxmox as a VMware alternative, beyond the price
European vendor
Proxmox Server Solutions GmbH, Austria: no dependence on decisions taken in the US.
No lock-in
Open formats: you can always migrate elsewhere, away from us included.
Backup included
Native Proxmox Backup Server: no third-party licence needed for backup.
Everything included, at every level
Clustering, high availability, live migration, backup, storage and software-defined networking are in every subscription: support changes, not the product.
VMs and containers together
KVM and LXC on one platform, with one console and one backup: no need for two products.
Verifiable security
Two-factor authentication, role-based permissions, LDAP and Active Directory, containers isolated with AppArmor and namespaces, and code anyone can inspect.
If you do not renew, it keeps running
The subscription is optional and has four levels. Without it the cluster keeps working: the update channel changes, not the features.
Professional support from Rackone
Migrating from VMware to Proxmox VE is an infrastructure project: it takes skills on both platforms, a structured plan and a partner able to keep operations running at every stage.
Proxmox Gold Partner #1 in Italy. Rackone is the first certified Proxmox partner in Italy for consulting (page in Italian) and support. Every day we support companies, public bodies and research centres as they adopt Proxmox VE.
Free initial assessment. We assess your current infrastructure, identify the VMs to migrate, estimate timing and costs and define the migration plan that fits your context. Request the assessment
Support during the migration. Our certified technical team works with you at every stage, from planning to execution and from validation to go-live, with dedicated assistance and a rollback plan tested before every cutover.
24h support after the migration. After go-live, our 24h technical support (page in Italian) remains available, with contractual SLAs and continuous monitoring, in English or in Italian.
Frequently asked questions about VMware to Proxmox migration
How long does a complete migration take?
The duration of a complete VMware to Proxmox migration depends on the number of VMs, the size of the disks, the available bandwidth and the agreed maintenance windows. In the assessment plan every VM has its own estimate and window, and the pilot migration measures the real times before production.
Is it possible to migrate without downtime?
No, zero downtime does not exist in a VMware to Proxmox migration, but it can be kept to a minimum: with live import or Attach & Move the VM restarts on Proxmox VE right after it is shut down on VMware, and with MultiPortal Migrator it stays on until the cutover. For every critical service the migration plan states the window of the intervention.
Which VMware ESXi versions are supported for the automatic import?
The vendor has tested the Proxmox VE automatic import on VMware ESXi from version 6.5 to 8.0. For earlier or later versions, the VM is exported to OVF with ovftool and imported from the web interface or with qm importovf, or the importer is tried on a test VM before proceeding.
Can I import from vCenter instead of a single ESXi host?
Yes, the Proxmox VE importer can also connect to vCenter, but the vendor reports a marked drop in performance: connecting directly to each ESXi host is the better choice. Either way the source VM must be shut down before the import, and no more than four disks are imported at a time.
What happens if something goes wrong during the migration?
A professional VMware to Proxmox migration plan always includes a rollback plan for every critical VM. The source VMware environment is not changed during the import: the original VMs stay intact and running until the new environment is confirmed stable.
Can Rackone run the migration on behalf of my organisation?
Yes. Rackone offers a complete migration service: from the initial assessment to planning, from technical execution to assisted go-live, through to 24h support after the migration. A free assessment evaluates your environment first.
Do Windows licences and business software stay valid?
Windows Server licences are counted on the physical cores of the host and are not tied to a hypervisor: moving from ESXi to Proxmox VE means no new ones to buy. Windows may ask for reactivation because the virtual hardware changes, and the VirtIO drivers must be installed. For business software the constraint is not the licence but the certification: some vendors state support only on vSphere, and in the assessment we check them one by one before moving anything.
What happens to existing Veeam backups?
Existing Veeam backups stay readable and also act as a safety net: Veeam Backup & Replication restores a VMware backup directly to Proxmox VE. After the migration, Proxmox VE joins the Veeam infrastructure with the dedicated plug-in (supported since version 12.2 and improved in 12.3), or you move to Proxmox Backup Server, which deduplicates and verifies backups with no extra licences. The choice is made in the assessment, not afterwards.
Who supports us after the migration?
Rackone does. After the cutover comes hypercare, close monitoring in the first weeks, and then ongoing 24h support from our systems engineers, in English or in Italian: you open the ticket with us and the person who answers knows your cluster. As the first Proxmox Gold Partner in Italy, Rackone handles first-level support and manages the escalation to the vendor.
Is the assessment worth it if I then stay on VMware?
Yes, the assessment is worth it even if you stay on VMware: an alternative evaluated and costed gives you leverage at the renewal. Either way the assessment leaves real numbers, mapped risks and a plan ready to use, whether you migrate now or later.
Can a company outside Italy migrate with Rackone?
Yes, Rackone migrates environments for companies anywhere in the world and already works on international projects in English: assessment and migration run remotely, on-site work is agreed project by project, and you reach us at the same contacts as our Italian customers.
Resell this service: for MSPs and system integrators
White-label migration subcontracting for your VMware customers. We never contact your end customers.
Plan your migration with Rackone.
We analyse your VMware infrastructure, define the migration plan and work alongside you at every stage, up to go-live.