Following Broadcom’s acquisition of VMware, significant changes have taken place across VMware’s product portfolio, licensing model, and packaging strategy. These changes, particularly the transition toward subscription-based licensing and the resulting cost increases, have pushed many organizations to reassess their virtualization platforms. As a result, interest in alternative virtualization solutions has increased considerably. Commercial platforms such as Sangfor, VergeIO, and HPE VM Essentials are now being evaluated alongside KVM-based open-source solutions. Among these alternatives, Proxmox VE has gained significant attention as a potential replacement for VMware environments. However, selecting a new hypervisor is only the first step. The real challenge is migrating virtual machines, applications, and services that may have been running on VMware for many years to the new platform in a controlled, measurable, and reversible manner. A VMware-to-Proxmox migration should never be considered as simply: “Copy the VMDK file and boot the VM on Proxmox.” A successful migration requires careful consideration of the guest operating system, storage controllers, network adapters, firmware mode, CPU features, encryption, application dependencies, licensing, backup strategy, monitoring, performance, and rollback procedures. For this reason, the migration project should be treated as an infrastructure transformation, not merely a VM conversion task.

Treat the Migration as a Platform Transformation

One of the most common mistakes during a VMware-to-Proxmox project is attempting to reproduce the existing VMware architecture exactly as it is on Proxmox. The two platforms differ in several architectural areas, including networking, storage, clustering, high availability, backup integration, and virtual hardware models. Therefore, the target Proxmox architecture should be designed before any production VM is migrated. For example, the team should determine how existing VMware datastores will map to technologies such as:

• ZFS
• Ceph
• LVM-Thin
• NFS
• iSCSI
• Other shared storage platforms

Similarly, VLANs and distributed switching configurations used in VMware should be mapped properly to Proxmox concepts such as:

• Linux Bridge
• Bonding
• VLAN-aware bridges
• Proxmox SDN

If VMware HA is being replaced with Proxmox HA, cluster quorum, fencing, node availability, and storage design must also be reviewed. The correct sequence should therefore be: Design the target platform first, then migrate the workloads.

Start with a Detailed VMware Inventory

Before beginning the migration, create a complete inventory of the existing VMware environment. This inventory should contain much more than just VM name, CPU, RAM, and disk capacity. For each virtual machine, collect at least the following information:

• Operating system and version
• CPU and memory allocation
• Number and size of virtual disks
• Thin or thick provisioning
• Storage controller type
• Network adapter type
• IP addresses
• VLAN information
• MAC addresses
• DNS configuration
• Default gateway
• BIOS or UEFI mode
• Secure Boot status
• TPM or vTPM usage
• BitLocker or disk encryption status
• VMware Tools version
• Snapshot status
• USB, GPU, or PCI passthrough requirements
• Raw Device Mapping or shared disk usage
• Application dependencies
• Backup policy
• Monitoring configuration
• Application licensing model
• Acceptable downtime

This inventory becomes the foundation of the entire migration project. Without it, migration teams often discover critical dependencies only after a VM has already been moved.

Classify Virtual Machines by Risk

Not every VM should be migrated using the same method or during the same maintenance window. A simple Linux web server is not equivalent to a SQL Server cluster, Domain Controller, ERP application, or vendor appliance. A practical classification could look like this:

Risk Level	Example Workloads	Recommended Approach
Low	Test servers, basic web servers, standalone Linux systems	Pilot migration
Medium	File servers, application servers, IIS, standalone SQL Server	Planned migration with application testing
High	Domain Controllers, ERP, critical databases, license servers	Detailed runbook and rollback plan
Very High	Vendor appliances, GPU workloads, vTPM systems, shared-disk clusters	Vendor review and specialized migration strategy

In production environments, I strongly recommend starting with a small number of low-risk systems. These pilot migrations help identify environment-specific issues and allow the team to build a repeatable migration standard before moving critical workloads.

Remove or Consolidate VMware Snapshots

Snapshot status should be reviewed before migration. Long-running VMware snapshots can increase migration complexity and significantly reduce transfer performance. Where possible, the source VM should not have active snapshots when the migration begins. The VMware environment should be checked for: Snapshot Manager → Delete / Consolidate Disk consolidation should be completed before migration. This is particularly important for large virtual machines, where snapshot chains may increase the amount of data that must be processed. However, one point must be emphasized: A snapshot is not a backup. Taking a snapshot immediately before migration does not replace the need for an independent, recoverable backup.

Always Maintain a Recoverable Backup

Every migration project needs a reliable Plan B. Before migration, ensure that the source VM has a recent and recoverable backup. For critical systems, do not stop at: “The backup job completed successfully.” The more important question is: “Can we actually restore this workload if the migration fails?” Where possible, backup restore testing should be performed in advance. The source VMware VM should also remain as unchanged as possible during the migration process so that rollback remains practical. A migration without a tested recovery path is unnecessarily risky.

VMware Tools and VirtIO Driver Planning

VMware-based Windows and Linux VMs typically use VMware Tools. After migration to Proxmox, the guest integration model generally changes to: VirtIO Drivers + QEMU Guest Agent For Windows systems in particular, VirtIO drivers should be prepared before migration. However, VMware Tools should not necessarily be removed too early. From an operational perspective, removing VMware Tools long before the cutover may make rollback more difficult if the VM needs to be started again on VMware. A safer approach is often: Prepare VirtIO drivers in advance, keep VMware Tools until the cutover, and remove VMware Tools after the first successful Proxmox boot or at a controlled point during migration. This maintains flexibility while still allowing the guest to transition cleanly to the Proxmox environment.

The Most Critical Windows Issue: Storage Controllers

One of the most common problems when migrating Windows Server workloads from VMware to Proxmox is the storage controller. A VMware VM may be using controllers such as:

• LSI Logic SAS
• LSI Logic Parallel
• VMware Paravirtual / PVSCSI
• SATA

On Proxmox, a common performance-oriented configuration is: VirtIO SCSI Single The challenge is that Windows must already have the appropriate VirtIO storage driver available. If the driver is missing, Windows may fail to recognize the boot disk. The result is often a boot failure or the well-known: INACCESSIBLE_BOOT_DEVICE BSOD. This is why VirtIO preparation should be considered a mandatory step in Windows migration planning.

SATA as a Temporary Workaround for Windows Boot Problems

If the migration is complete but Windows cannot boot using VirtIO SCSI, a temporary workaround is to attach the boot disk as SATA. The process can be summarized as: Migration → Attach Boot Disk as SATA → Boot Windows → Install VirtIO Drivers → Shut Down → Reattach Disk as VirtIO SCSI → Boot Again Because Windows generally has native SATA support, the system is more likely to boot successfully. Once Windows is running, the VirtIO ISO can be mounted and the required storage and network drivers installed. After driver installation, shut down the VM and move the disk back to: VirtIO SCSI Single This approach is especially useful for manually imported OVF, OVA, or VMDK workloads.

Be Prepared for Network Adapter Changes

VMware environments commonly use VMXNET3 adapters. On Proxmox, the preferred virtual network adapter is generally: VirtIO The guest operating system may detect VirtIO as an entirely new network interface. Before migration, record:

• IP address
• Subnet mask
• Default gateway
• DNS servers
• VLAN ID
• MAC address
• Static routes

On Windows systems, the old VMXNET3 adapter may remain registered even though it is no longer visible. When assigning the same static IP address to the new VirtIO interface, Windows may report that the IP address is already assigned to another adapter. In such cases, the old hidden network adapter may need to be removed. If DHCP reservations are used, either preserve the original MAC address where appropriate or update the reservation for the new VirtIO adapter.

Validate the Entire Network Path

Do not limit troubleshooting to the guest operating system. The full network path must be checked: VM → Bridge → Bond → Physical NIC → Switch Port → VLAN In VLAN trunk environments, the Proxmox VLAN configuration must match the physical switch configuration. If Jumbo Frames are used, MTU must be consistent end to end, including:

• Proxmox host
• Switches
• Storage network
• VM interfaces

When LACP is used, the Proxmox bonding mode and physical switch port-channel configuration must also match. An incorrect VLAN or MTU configuration can easily be mistaken for a guest OS network problem.

Check BIOS, UEFI, and Secure Boot

The source VM firmware mode should always be documented before migration. For Legacy BIOS systems, Proxmox commonly uses: SeaBIOS For UEFI systems: OVMF should generally be selected.

UEFI systems may also require an EFI disk. Incorrect firmware settings can cause errors such as:

• No bootable device
• Boot failed
• Operating system not found

It is also important not to change too many virtual hardware components at once. Changing all of the following simultaneously can make troubleshooting unnecessarily difficult:

• BIOS to UEFI
• Machine type
• Storage controller
• Network adapter
• CPU type
• Secure Boot configuration

The first objective should be simple Boot the VM successfully. Optimization can be performed afterward in a controlled manner.

Do Not Overlook vTPM and BitLocker

Modern Windows workloads may depend on virtual TPM devices. This is particularly important when BitLocker or full-disk encryption is enabled. A VMware vTPM state may not transfer directly to the new virtualization platform. As a result, the migrated system may request the BitLocker recovery key. Before migration, always verify that the required recovery keys are available and securely stored. Otherwise, the migration itself may succeed while access to the operating system or encrypted volume is lost.

CPU Compatibility Matters

CPU compatibility should also be reviewed between the source VMware hosts and the target Proxmox nodes. Applications may depend on instruction sets such as:

• AES
• AVX
• AVX2
• SSE4.x

If all Proxmox nodes use identical processors, using: CPU Type = host can provide excellent performance. However, this may reduce migration flexibility in clusters with different CPU generations. In mixed hardware environments, a compatible x86-64-vX CPU model may provide better mobility between nodes. Extra attention should be paid when migrating between: Intel → AMD or AMD → Intel platforms. Some applications, databases, licensing mechanisms, and virtual appliances may behave differently when the underlying CPU vendor changes.

Check Application Licensing Before Migration

This issue is often overlooked. Some applications bind their licenses to virtual hardware characteristics such as:

• MAC address
• CPU ID
• BIOS UUID
• Machine UUID
• Disk serial number
• Host ID

When the hypervisor changes, one or more of these values may also change. The VM may boot successfully while the application reports: License Invalid or similar licensing errors. This is especially important for:

• ERP platforms
• CAD applications
• License servers
• Industrial applications
• Security products
• Vendor appliances

Windows activation can also be affected by significant virtual hardware changes. Application licensing should therefore be verified before the migration window, not after it.

Vendor Appliances Require Special Attention

Just because an appliance technically boots on Proxmox does not mean the software vendor officially supports Proxmox. Examples include:

• Firewall appliances
• Backup appliances
• Network management platforms
• Security appliances
• Database appliances

Some vendors officially support only VMware or Hyper-V. Before moving any critical appliance, review the vendor’s support matrix. Otherwise, the appliance may technically work but the vendor may decline support if an incident occurs later.

Special Storage Scenarios Need Their Own Plan

Not every VMware storage configuration can be treated like a basic standalone VMFS datastore. Special attention is required for:

• vSAN
• Encrypted virtual disks
• RDM
• Shared disks
• Clustered disks
• Large thin-provisioned disks
• Storage-level snapshots

In some cases, it may be safer to move the VM to a standard VMware datastore before starting the Proxmox migration. The migration method should be selected based on the actual storage architecture, not just the VM format.

Available VMware-to-Proxmox Migration Methods

There is no single migration method that is best for every environment. The right choice depends on downtime tolerance, network bandwidth, storage capacity, VM size, application criticality, and operational risk.

1. Proxmox VE Import Wizard

For standard VMware environments, the Proxmox VE Import Wizard is one of the first options worth evaluating. An ESXi host can be added as an import source and virtual machines can be imported directly from the Proxmox interface. This approach can significantly simplify many small and medium-sized migration projects.

2. VMware OVF / OVA Export

A VM can be exported from VMware as OVF or OVA and then imported into Proxmox. For example:

qm importovf 100 Server.ovf local-zfs

After the import, always verify:

• Storage controller
• Network adapter
• CPU type
• Boot order
• Firmware mode

3. Manual VMDK Import

VMDK files can also be copied manually and imported into the target storage. For example:

qm disk import 104 Server.vmdk local-zfs

The imported disk must then be attached to the correct VM and configured with the appropriate controller.

4. Backup and Restore

If the backup platform supports Proxmox restore workflows, backup-based migration can be an excellent option. Products such as:

• Veeam
• NAKIVO
• Commvault
• Cohesity
• Acronis
• Vinchin

may offer migration or restore capabilities depending on product version and platform support. Always verify the current compatibility matrix before planning the migration around a backup product.

5. Third-Party V2V Tools

Additional tools may also be useful in certain environments, including:

• StarWind V2V Converter
• Clonezilla
• virt-v2v
• NetApp Shift Toolkit
• Commercial migration platforms

The migration tool should not be selected simply because it appears easier. The real decision criteria should be: Downtime, data size, rollback requirements, workload criticality, and vendor support.

Live Import Does Not Mean Zero Downtime

Proxmox Live Import can help reduce downtime for large virtual machines. However, it should not be confused with a true cross-hypervisor live migration. The source VMware VM is still powered off. The target Proxmox VM may be started before all disk blocks have been fully transferred, while remaining blocks continue to be retrieved from the source. This can significantly reduce downtime, but it also increases dependency on stable network connectivity. Therefore, Live Import should be carefully tested before being used for critical production workloads.

Linux Migrations Are Often Easier, But Not Risk-Free

Linux workloads are generally easier to migrate because VirtIO support is commonly available directly in the Linux kernel. However, several issues can still occur. The network interface name may change. For example: ens192 may become a different interface name after migration.

Review network configuration in:

• Netplan
• NetworkManager
• /etc/network/interfaces

Older or customized Linux distributions may also require VirtIO modules to be included in the initramfs. Another point to review is /etc/fstab. Systems that refer directly to device names rather than UUIDs may experience boot problems if disk enumeration changes.

Domain Controllers, SQL, and Clustered Systems Deserve a Different Approach

Not every workload should be migrated using V2V conversion. For certain systems, rebuilding or migrating at the application level may be safer. Examples include:

• Active Directory Domain Controllers
• SQL Server clusters
• Oracle databases
• File clusters
• Shared-disk clusters
• Highly available database platforms

For Active Directory, creating a new Domain Controller on Proxmox and allowing AD replication to synchronize the directory may be cleaner and safer than converting an existing DC. Similarly, SQL Server may be migrated using technologies such as:

• Always On
• Log Shipping
• Backup/Restore
• Replication

depending on the application architecture. The important question is not: “Can this VM be migrated?” but: “Is VM migration actually the safest way to move this service?”

Plan Target Storage Capacity Carefully

Do not calculate storage requirements only from the amount of data currently in use. For example, a thin-provisioned 4 TB VMware disk may contain only 800 GB of real data, but the migration process may still require additional temporary capacity. Depending on the method used, you may simultaneously need:

• Source VM storage
• Export or temporary storage
• Target Proxmox storage

Large OVA/OVF workflows can be particularly storage-intensive. Always calculate migration workspace before starting the operation. Running out of storage during migration can lead to failed imports, corrupted temporary files, or service interruption.

Establish Performance Baselines Before Migration

A VM booting successfully does not prove that the migration was successful from a performance perspective. VMware and Proxmox may behave differently in terms of storage, network, CPU scheduling, and memory management. Before migration, capture baseline values for critical workloads, such as:

• CPU utilization
• Memory utilization
• Disk latency
• IOPS
• Throughput
• Network throughput
• Application response time

Repeat these measurements after migration. This gives the team objective data rather than relying on subjective comments such as: “The application feels slower than before.”

Install and Enable QEMU Guest Agent

After migration, QEMU Guest Agent should normally be installed and enabled. It improves communication between the Proxmox host and the guest operating system. Benefits may include:

• Cleaner shutdown operations
• Guest IP reporting
• Improved backup coordination
• Filesystem freeze/thaw support in appropriate scenarios

It should be considered part of the standard post-migration configuration.

Verify Time Synchronization

After VMware Tools is removed, any time synchronization mechanism provided through VMware Tools also disappears. Time synchronization should therefore be validated after migration. On Windows Windows Time / NTP. On Linux: chrony, systemd-timesyncd, NTP This is especially important for:

• Domain Controllers
• Database servers
• Authentication systems
• Log correlation
• Security monitoring

Clock drift can create serious authentication and application issues.

Rebuild Backup and Monitoring Integration

Once the VM is running on Proxmox, old VMware backup jobs may no longer protect it. Backup policies should immediately be reviewed and recreated on the target platform. Verify:

• Backup schedule
• Retention
• Off-site replication
• Immutable copies where applicable
• Restore testing

The same applies to monitoring. Monitoring solutions that previously collected VM health through vCenter may no longer see the migrated VM. Review integrations with:

• Monitoring platforms
• SIEM
• Backup systems
• Vulnerability scanners
• Asset management
• CMDB
• Automation platforms

Migration is not complete until these operational systems are updated.

Prepare the Rollback Plan Before the Migration Plan

The most important part of a migration plan is not the success scenario. It is the failure scenario. A typical cutover timeline might look like this:

22:00 – Application access disabled
22:05 – Application services stopped
22:10 – Source VMware VM shutdown
22:15 – Final backup verification
22:20 – Migration starts
23:30 – Proxmox VM boot
23:45 – Network validation
00:00 – Application testing
00:20 – User acceptance testing
00:30 – Go / No-Go decision

The critical point is the predefined decision threshold. For example: “If critical functionality is still unavailable at 00:30, rollback to VMware.” Without a clear decision point, engineers may continue troubleshooting indefinitely until the maintenance window has already expired.

Do Not Delete the Original VMware VM Immediately

Even after a successful migration, the original VMware VM should not be deleted immediately. A safer approach is to:

• Keep the source VM powered off
• Disconnect its network interfaces
• Rename it with a prefix such as OLD_ or MIGRATED_
• Retain it for the agreed rollback period

After the rollback window has expired and Proxmox backups have been verified, the old VM can be removed. However, never power on both the old and new production VMs on the same network unless explicitly planned. Doing so may result in:

• Duplicate IP addresses
• Duplicate hostnames
• Database inconsistency
• Application corruption
• Split-brain behavior

Perform a Real Post-Migration Acceptance Test

A successful ping does not mean a successful migration. Migration validation should take place across at least four layers Infrastructure → Operating System → Application → User First, verify

• CPU
• Memory
• Storage
• Network
• Boot configuration

Then verify the operating system:

• Event Viewer
• System logs
• Device Manager
• Failed services
• Disk status

Next, test the actual application:

• SQL Server
• IIS
• ERP
• File Server
• Web services
• Database connectivity
• Application-specific services

Finally, where possible, perform a functional test with a real application user. Only then should the migration be considered complete.

Recommended Migration Strategy

For large VMware environments, migrating every VM during a single weekend is rarely the safest approach. A wave-based migration model is usually better.

Wave 0 – Lab / Test : Validate tools, procedures, drivers, and runbooks.

Wave 1 – Low Risk : Migrate development, test, and simple production workloads.

Wave 2 – Medium Risk : Migrate web servers, application servers, and file servers.

Wave 3 – Critical Systems : Migrate databases, ERP systems, and business-critical workloads.

Wave 4 – Special Workloads : Migrate systems involving:

• Clusters
• Appliances
• GPU passthrough
• TPM
• Encryption
• Vendor-specific dependencies

After each wave, update the migration runbook with lessons learned. This creates a continuously improving process and reduces risk as the project moves toward more critical workloads.

Migrating from VMware to Proxmox VE is technically achievable and can be highly successful when properly planned. However, the success of the project depends much more on preparation, testing, and rollback planning than on the conversion tool itself. For Windows Server workloads in particular, the following areas deserve special attention:

VirtIO drivers
Storage controllers
Network adapters
BIOS / UEFI
Secure Boot
TPM / vTPM
BitLocker

Beyond the VM itself, organizations should also consider:

Application licensing
Vendor support
Backup
Monitoring
Storage architecture
Performance baselines
Time synchronization
Application dependencies

A practical migration approach can be summarized as follows:

Design the target Proxmox architecture first.
Build a complete inventory.
Create tested backups.
Run pilot migrations.
Create a standard migration runbook.
Migrate workloads in waves.
Validate performance and application functionality.
Preserve rollback capability at every stage.

The objective of a VMware-to-Proxmox migration is not simply to make a VM boot on another hypervisor. The real objective is to move business services to a new virtualization platform without losing data, without creating unnecessary downtime, without reducing performance, and with a reliable path back if something goes wrong.