Surprising fact: after a major vendor acquisition, over 40% of Australian IT teams considered alternative platforms within a year — many driven by licensing uncertainty and the need for cost control.
We outline a clear path for a smooth migration that balances speed and control. Proxmox VE bundles KVM and LXC on Debian and gives you a unified web GUI, CLI and REST API for guests, storage, networking and clusters.
There are two main methods: an Automated ESXi Import Wizard for fast imports and a Manual workflow using qemu-img and qm importdisk for complex cases. We show how to plan, stage and validate each phase of the process so downtime stays minimal and data integrity is preserved.
We also highlight resilience options — like Proxmox Backup Server with deduplication and incremental transfers — and common pitfalls such as encrypted disks and vSAN that need careful handling.
Key Takeaways
- We provide a pragmatic approach to reduce licensing risk and retain enterprise capability.
- Choose automated imports for speed or manual control for complex workloads.
- Use Proxmox Backup Server for safe rollbacks and incremental backups.
- Plan for Australian governance and maintenance windows during cutover.
- Validate performance and SLAs before decommissioning legacy hosts.
Why move from VMware to Proxmox VE in Australia
Cost and control have become top priorities for businesses reviewing their virtualisation platforms.
Licensing pressure after recent acquisitions pushed many organisations to reassess budgets and risk. We favour open-source solutions that offer transparency, predictable costs and optional paid support with tested enterprise repositories.
Cost, licensing and strategic drivers post‑acquisition
Australian teams cite licence volatility and audit risk as drivers for change. Subscriptions exist for enterprise support and a stable update channel. That mix gives firms control over change cycles and compliance.
What Proxmox VE brings: KVM, LXC, web UI and storage plugins
What you gain: KVM for vms, LXC for lightweight machines, and a unified web UI plus CLI and REST API for administration. Storage plugins support ZFS, Ceph RBD, NFS and CIFS — flexible backends for production server use.
- Operational simplicity — centralised cluster management per host.
- Performance — paravirtual drivers and optimised storage formats improve responsiveness.
- Versioned updates — stable channels help meet Australian change‑control needs.
Understand the environment: concepts that impact migration
A clear grasp of architecture, network design and storage choices makes cutover predictable and low risk.
At cluster level, core configuration lives in /etc/pve and is synchronised by pmxcfs. Nodes share that configuration so VMIDs remain authoritative for disks and backups across the system.
The management interface comes in three layers: web GUI for daily ops, CLI for scripted tasks and a REST API for integration with automation and monitoring.
Networking basics
Proxmox uses Linux bridges (vmbrX) as virtual switches, bonds for link aggregation, and VLAN tagging either per NIC or at the host stack. SDN offers cluster-wide policy for complex network designs.
Storage fundamentals
Storage plugins support file-level (qcow2, NFS, CIFS) and block-level backends (ZFS, Ceph RBD, thin LVM). Local storage is node-bound; shared storage enables live migration and HA for clustered vms.
- Map equivalents: identify where each disk and NIC will land on the new host and which VMID will own it.
- Predefine landing zones: set bridges, VLANs and storage pools before cutover.
- Secure the control plane: isolate management networks and apply role-based access.
Pre‑migration planning and prerequisites
Good preparation cuts risk and keeps downtime predictable during any host transition.
We begin with a concise inventory of vms, inter‑app dependencies and service SLAs. Catalogue guest OS, controllers, BIOS/UEFI mode and disk layout so target configuration matches the original.
Take full backups and define a rollback plan using Proxmox Backup Server — it offers deduplication and incremental backups for live restore. Power off the source VM for a consistent file state where possible. Disable disk encryption and remove vTPM on the vmware esxi side to avoid blocked reads.
Validate the proxmox server: refresh repositories, update packages and confirm pve-esxi-import-tools is installed. Test network reachability between the esxi host and your proxmox node — measure latency and throughput so transfers don’t stall.
Quick checklist
- Document IP addressing, NIC models and consider DHCP to prevent conflicts.
- Estimate total data and disk sizes to size maintenance windows and storage headroom.
- Agree naming conventions for VMs and storage pools before cutover.
- Decide manual vs automated method based on complexity and acceptable downtime.
VMware to Proxmox migration steps
We weigh the two common routes and set clear expectations for downtime, data consistency and first‑boot checks.
Choose your method: automated import vs manual workflow
Automated import (the ESXi Import Wizard with pve‑esxi‑import‑tools) is guided via the web UI and speeds bulk transfers. It supports Live‑Import — useful when uptime matters but must be tested because I/O can be affected.
Manual workflow gives granular control: create a target virtual machine, copy or export VMDKs, use qemu‑img and qm importdisk, then attach disks and set boot order.
Downtime windows, snapshots, and vTPM/encryption notes
Plan to power off the source esxi host VM for a consistent copy. Consolidate snapshots on the vmware esxi side — chained snapshots slow transfers and increase failure risk.
“Disable vTPM and disk encryption before any import; encrypted devices often block reads and halt progress.”
- Size downtime conservatively — test Live‑Import for critical vms if you need minimal outage.
- Match BIOS/UEFI and controller types to avoid boot surprises for Windows and Linux machines.
- Preconfigure bridges and VLANs on the new proxmox target so network mapping is immediate at cutover.
- Replicate CPU/memory and key hardware models, then tune drivers after first boot.
Final step: prepare, transfer disk, attach and set boot order, perform first‑boot checks, then validate performance and application health.
Method A: Automated ESXi import wizard in Proxmox VE
We favour a guided import for bulk virtual machines when consistency and speed matter.
Prepare the proxmox server and tools first. Enable the No‑subscription/test repositories if required, run apt update && apt full-upgrade, verify the pve-esxi-import-tools package with dpkg -l | grep pve-esxi-import-tools, and reboot if a new kernel was installed.
In the web interface go to Datacenter > Storage > Add > ESXi. Provide the ESXi server address, administrative username and password, pick a target node, and decide whether to skip certificate verification.
Once the ESXi storage appears, select the VM’s .vmx file and click Import. Choose target storage for each disk, assign bridges for each NIC, and map devices by name so disks and network remain predictable.
Advanced options allow per‑disk placement on faster storage tiers, attaching or removing CD‑ROM ISOs, and changing NIC models where hardware drivers differ.
Live‑Import is available as an option to reduce downtime. It boots the virtual machine during import and streams remaining data asynchronously. Note that initial I/O may be slower and data written after start can be lost if the import fails.
- Check file mappings carefully when multiple files form a single disk.
- Relocate vSAN‑hosted disks first — they cannot be imported directly.
- Review the resulting configuration block before creation to confirm parity with the source virtual machine.
Final note: start the machine after import, verify device enumeration, and test network and disk throughput on the new server.
Method B: Manual migration and disk import
For complex or custom builds, a hands‑on disk import gives precise control over every hardware and storage choice. We prefer this when layouts, encryption or bespoke drivers need careful handling.
Prep on the ESXi host
Power off the source virtual machine and enable SSH (Host > Manage > Services > TSM-SSH). Record CPU, controller, BIOS/UEFI and NIC details — these guide target configuration.
Create the destination on the proxmox server
Create a VM that matches CPU, memory and network. Remove the placeholder disk and ensure the chosen storage pool has space and correct permissions.
Copy and convert disk files
Transfer VMDK and -flat.vmdk files via SCP from /vmfs/volumes///. Alternatively export an OVF with ovftool for efficiency.
Convert or import with qemu-img (vmdk → qcow2) or use qm importdisk <VMID> <file> <storage> with -format qcow2 as an option.
Attach, boot and verify
Add the imported disks as unused, assign a compatible controller (start with SATA/IDE if unsure), set the boot order and start the virtual machine.
On first boot check the OS finds its boot loader, confirm NICs and IP addressing, then install VirtIO drivers and the QEMU guest agent for Windows machines.
- Integrity: compare sizes and hashes where possible.
- Optimise: move system disk to VirtIO SCSI and enable IO threads after successful boot.
- Cleanup: remove temporary vmdk files from storage once cutover is validated.
Target VM configuration for optimal performance
Choosing the right runtime settings makes a big difference in day‑to‑day performance and live migration success.
We start with the CPU model. Use host if all nodes share identical silicon. For mixed nodes, pick a generic x86‑64‑vX family to preserve live migration options as the cluster grows.
CPU type selection and live‑migration friendliness
Match the CPU choice to your cluster topology. Host mode gives the best raw performance when hardware is uniform.
Generic models reduce migration failures when nodes differ. Document the chosen cpu model in templates for repeatable configuration.
VirtIO for network and disks, IO threads and discard
Paravirtual devices are key: move system and data drives to VirtIO SCSI single and switch NICs to VirtIO once drivers are present.
Enable IO threads for heavy disk workloads and set discard (TRIM) on thin provisioning. These options improve throughput and reclaim storage efficiently.
Install QEMU guest agent and VirtIO drivers (Windows/Linux)
Install the QEMU guest agent for better shutdowns, IP reporting and orchestration hooks. It improves host‑guest communication during backups and live tasks.
Windows needs the VirtIO ISO mounted and drivers installed before switching controllers. For Linux, include VirtIO modules in initramfs so the operating system boots after controller changes.
| Setting | Best option | Live migration | Notes |
|---|---|---|---|
| CPU model | host or x86‑64‑vX | High (host) / Flexible (generic) | Choose host if hardware matches; generic for mixed nodes |
| System drive | VirtIO SCSI single | High | Install drivers before controller switch |
| IO tuning | IO threads + discard | Neutral | Improves performance on heavy disk systems |
| Guest tools | QEMU guest agent | Supports operations | Better orchestration and monitoring |
Final checks: confirm BIOS or UEFI matches the source and validate the boot path if using EFI. Benchmark key workloads after changes and capture results for SLA acceptance.
Storage and network mapping without surprises
Storage design and network mapping decide whether cutover is routine or chaotic.
Choosing storage backends
We align storage tiers to workload needs. Directory storage offers flexibility for test systems and small virtual machines.
ZFS gives checksums, snapshots and local replication. Ceph scales across clusters for large server farms.
NFS and CIFS suit shared access for application servers and user data. Consider NAS/SAN with multipath for redundancy.
Shared vs local storage and HA implications
Shared storage simplifies failover and makes high availability predictable.
Local storage can work for standalone nodes or replicated ZFS designs — but it adds operational complexity for HA.
Bridges, VLANs and preserving IP addressing
Standardise bridges per segment and use bonds for resilience and throughput.
Map VLAN IDs consistently across hosts and pre‑stage routes so addresses remain stable.
| Area | Recommended option | Why it helps |
|---|---|---|
| Storage backend | Directory / ZFS / Ceph / NFS | Matches flexibility, integrity, scale and shared access |
| HA model | Shared storage or replicated ZFS | Simplifies failover and restores service quickly |
| Network | vmbrX + bonds + VLANs | Consistent mapping keeps IP and name assignments intact |
Final step: document storage IDs, bridge names and VLANs in a runbook. Validate reachability and performance before cutover to avoid last‑minute surprises.
Post‑migration validation, HA and tuning
After import we run a short, structured validation so the new environment operates reliably under production load. We focus on boot paths, core services and key performance metrics before decommissioning the old host.
Boot mode sanity: BIOS vs UEFI and default paths
First, confirm BIOS or UEFI matches the source system. Some operating systems do not set the default UEFI path (/EFI/BOOT/BOOTX64.EFI), so you may need a manual boot entry for the virtual machine.
Note: verify boot order, firmware option settings and that disks present as expected. Fix any missing EFI entries before further testing.
Functional tests, performance tuning and clean‑up
We run application checks, authentication flows and scheduled jobs to validate real behaviour. Next, benchmark disk throughput, latency and network performance.
Adjust caches, IO queues and CPU pinning where required. Clean up temporary import files and confirm file permissions and shares are intact.
Cluster and HA basics: Corosync, quorum and recovery
Confirm Corosync links are redundant and low‑latency. We recommend at least three votes for quorum or use QDevice in two‑node setups.
HA requires shared storage for guest disks; nodes that lose quorum will self‑fence to protect data. Simulate a host failure to validate automatic recovery of virtual machines.
| Check area | Action | Expected result |
|---|---|---|
| Boot mode | Verify BIOS/UEFI and default EFI path | VM boots reliably; boot entry exists |
| Performance | Benchmark disk, network and CPU | Results meet SLA thresholds |
| HA | Test quorum and fencing | Cluster recovers VMs without data loss |
| Cleanup & docs | Remove temp files, update runbook | Environment documented; naming consistent |
Final steps: add hosts and vms to monitoring, set alerts for storage and disk health, and schedule a follow‑up review after a week of production traffic. We then capture versions, tools and tunables in a final runbook so future changes remain predictable.
Conclusion
Final validation and documented runbooks turn a one‑off import into an operational routine. We recommend a phased pilot, clear BIOS/UEFI checks and target VM settings that use VirtIO and an appropriate CPU model.
Choose the automated import where scale matters, or pick the manual route for complex workloads. Start with lower‑risk vms and iterate the runbook before wider rollout.
Align storage and network mappings early so each machine finds its bridges, shares and boot path without surprises. Use Proxmox Backup Server to protect data and enable live‑restore during cutover.
With methodical planning, measured validation and a pilot import, your migration will meet SLAs and reduce operational risk across the estate.
FAQ
What are the main reasons organisations in Australia switch from VMware ESXi to Proxmox VE?
Organisations often cite cost savings, simpler licensing, and a desire for open‑source control. Proxmox offers KVM and LXC support, an integrated web UI, and a rich plugin ecosystem for storage and backups — all of which appeal to IT teams seeking flexibility and lower recurring fees.
How do nodes, VMIDs and the Proxmox GUI/CLI/API affect our migration planning?
Proxmox uses node identities and VMIDs to locate and manage virtual machines. We must map ESXi host names and VM identifiers to Proxmox nodes and IDs, and decide whether to use the web GUI, CLI or API for bulk tasks. Clear mapping prevents conflicts and simplifies post‑import automation.
What networking concepts should we address before moving VMs?
Plan bridges, bonds and VLANs to match existing network topology. Ensure Proxmox bridges mirror ESXi port groups and preserve IP addressing. If you use SDN or special NIC models, test compatibility and plan for VirtIO drivers if switching virtual NIC types.
Which storage types matter when mapping ESXi datastores to Proxmox backends?
Understand file versus block semantics and local versus shared options. Proxmox supports directory storage, ZFS, Ceph, NFS and CIFS. Choose backends that match performance and HA needs — for example, Ceph for distributed storage or ZFS for snapshots and data integrity.
What baseline checks should we perform before starting the transfer?
Inventory all VMs, record CPU, RAM, disk layout, NICs, snapshots and dependencies. Capture performance baselines and identify latency‑sensitive workloads. Confirm network reachability between ESXi hosts and the Proxmox server and validate repositories and package versions on Proxmox.
How do we ensure rollbacks are possible if something goes wrong?
Keep current backups and create rollback plans using Proxmox Backup Server or your existing backup solution. Snapshot or export critical VMs before migrating and verify backup integrity. Define clear rollback steps and test them in a lab environment.
What migration methods are available and how do we choose between them?
Choose between an automated ESXi import wizard and a manual workflow. Use the import wizard for convenience when compatibility is high. Choose manual disk export/import for custom layouts, troubleshooting or when you need granular control over conversion (qemu‑img, qm importdisk).
What prerequisites are needed to use the Proxmox ESXi import tool?
Enable the appropriate Proxmox repositories, update the host, and verify the pve‑esxi‑import‑tools package. Grant API or storage access to the ESXi host and ensure SSH or authenticated storage access is available to transfer files.
How does the automated import flow work in Proxmox VE?
The flow lets us select a VMX, choose target storage, pick bridges and map devices. It can import VM configuration, convert disks and assign NIC models. We review advanced options like per‑disk storage choices, CD‑ROM handling and NIC model selection before finalising the import.
What are live‑import considerations to reduce downtime?
Live import can reduce downtime but adds complexity and risk. Ensure VM quiescing, network bandwidth and storage throughput are adequate. For critical Windows servers, consider application‑aware backups and schedule a brief maintenance window for final cutover.
If we choose manual migration, what are the core steps on the ESXi host?
Power off the VM, enable SSH, collect configuration files and export VMDK files or OVF using ovftool. Capture the VMX and any advanced settings so we can reproduce CPU, memory and device configurations on the new Proxmox VM.
How do we convert and import disks into Proxmox?
Transfer VMDK files via SCP or export an OVF. Use qemu‑img for format conversion (vmdk to raw or qcow2) or qm importdisk to write directly into Proxmox storage. Choose raw for performance or qcow2 for features like snapshots, depending on workload requirements.
What must we configure on the destination VM for a smooth first boot?
Create a VM with matching CPU, memory and disk sizes. Attach converted disks, set the correct boot order and match BIOS/UEFI mode. For Windows VMs, install VirtIO drivers and the QEMU Guest Agent prior to or immediately after the first boot.
Which CPU and device settings improve live‑migration friendliness?
Select a generic CPU model that matches across cluster nodes to prevent device mismatches during live migration. Enable features like CPU passthrough only when necessary. Use virt‑type settings that balance performance with portability across hosts.
Why and when should we install the QEMU guest agent and VirtIO drivers?
The QEMU guest agent improves shutdowns, backups and quiescing. VirtIO drivers deliver better network and disk throughput for Linux and Windows. Install them to gain stable performance, correct ballooning and reliable guest communications.
How do we map shared storage and maintain HA after the move?
Decide between local and shared backends. For HA, use shared storage like Ceph or an NFS/CIFS cluster. Ensure Proxmox nodes have consistent access and configure HA resources accordingly. Understand quorum and Corosync requirements to avoid split‑brain scenarios.
What networking steps preserve IP addressing and VLANs during cutover?
Recreate bridges and VLAN tags on Proxmox that match ESXi port groups. Attach virtual NICs with the same MAC or update DHCP/static records before cutover. Test connectivity in a staging environment to ensure services retain IPs and routes.
What boot‑mode issues should we check post‑migration (BIOS vs UEFI)?
Verify the original VM’s firmware mode and replicate it in Proxmox. A mismatch can prevent boot. Check boot order and disk mapping — correct target disk identifiers and ensure EFI variables are present for UEFI guests.
How do we validate functionality and performance after migration?
Run functional tests for application services, check logs and confirm networking. Compare performance against pre‑migration baselines, tune IO threads, enabling discard where appropriate, and remove orphaned snapshots or temporary files.
What cluster and HA basics should we verify after bringing nodes online?
Confirm Corosync cluster membership, node quorum and datacenter replication settings. Validate fencing and recovery paths and test failover of a non‑critical VM to ensure HA resources behave as expected.
Are there special notes for encrypted or vTPM‑protected VMs?
Encrypted disks and vTPM may prevent direct import. Plan for key migration or decryption on the source host. Document encryption settings and consult vendor guidance for secure key handling during the transfer.
What tools help streamline large‑scale imports and post‑migration tasks?
Use Proxmox import utilities, qemu‑img, ovftool, SCP and automation scripts via the Proxmox API. Proxmox Backup Server aids backup and rollback. Combine these tools with configuration management and monitoring to speed large rollouts.
How do we handle Windows activation and licensing after moving virtual machines?
Moving hardware virtualisation can trigger activation prompts. Keep records of licensing keys and plan a validation step after migration. For enterprise licences, check Microsoft licensing policies for virtualised environments.
Comments are closed.