Surprising fact: 72% of small and mid-size IT teams report they can cut virtualization costs by over 30% after switching platforms—when the move is planned and tested.

We lay out a clear path for teams in Malaysia who manage mixed datacenters. Our guide explains how an open-source host with a web-based GUI, CLI and REST API maps to common enterprise concepts.

We focus on real outcomes: how unique VMIDs and Proxmox storage abstractions match your existing inventory, how the interface reflects familiar controls, and which feature choices reduce risk.

Readers get a practical process and a concise step checklist for non-production testing, careful backups, and low-downtime transfers. We balance automation and manual options so your team can pick the safest route.

Key Takeaways

• We recommend testing imports with non-production guests first.
• Understand VMIDs, storage targets, and Linux bridge networking early.
• Pick automatic import for speed or manual for control—match risk to timelines.
• Keep backups and a rollback plan—use Proxmox Backup Server for integrity.
• Expect BIOS/UEFI and driver checks after any import.

Why migrate now: aligning VMware to Proxmox migration steps with your goals

Many Malaysian operations now consider an open-host model for clearer licensing and faster iteration. We focus on outcomes that matter—lower operating cost, predictable support, and skills portability.

User intent and outcomes for Malaysian teams

Decision makers want reduced OPEX, stable updates from enterprise repositories, and better backup throughput with Proxmox Backup Server. Clusters need low-latency network links for Corosync quorum. We define success as measurable savings, reliable backups, and a documented list of migrated vms.

Downtime, risk, and compliance considerations

Most machines can use offline import; choose Live-Import only on 10Gbps+ links between the ESXi host and destination. Retain original VMs until cutover, snapshot or backup first, and document each operating system, disk, and NIC.

Note: Communicate windows, list stakeholders, and keep audit-ready change logs. Address common issues early—driver gaps, BIOS/UEFI mismatch, and NIC model changes—and plan the validation process before final cutover.

Prerequisites and preparation checklist before touching any machines

Preparation begins with network verification and secure credentials—small checks that prevent big failures. We outline the must-do items so teams in Malaysia can run a controlled process without surprises.

Network access and credentials

Confirm L3 reachability both ways between the esxi host and the proxmox server. Validate API ports, datastore access, and latency on production links.

Use administrative credentials on both platforms. Store them securely and grant time-bound access for the migration window.

Backups, snapshots, and encryption

Create fresh backups or snapshots per policy. Prefer proper backups with your existing tooling or the Proxmox Backup Server for deduplication and live-restore options.

Power off source vms and remove existing snapshots. Disable disk encryption and vTPM—encrypted files and TPM-bound keys block import tools.

Files, capacity, and BIOS notes

Inventory important files per VM—vmx, vmdk and -flat.vmdk—so operators know what data and file artifacts transfer. Add up provisioned disk sizes and include realistic growth for target storage.

Document bios/UEFI settings, controller type, NIC model, and any installed guest software. Finally, prepare a clear runbook that defines the import process, validation, and rollback for each server.

Plan storage, disks, and network on Proxmox for a clean landing

A clear storage and network plan makes every import predictable and testable. We match workload I/O and resilience needs to the right backends before any data moves.

Choose storage per role: ZFS for local resilience and replication; Directory for flexible qcow2 snapshots; NFS/SMB for shared file storage; iSCSI/FC when a SAN is standard in the data center.

Disk format and snapshot implications

Pick raw for peak throughput and simple tooling. Use qcow2 when snapshots and thin space savings matter.

Note: LVM thick volumes and TPM-bound disks may limit snapshot behavior. Document snapshot policies clearly.

Bridges, VLANs, bonds, and cluster networking

Map each vmnic to a vmbrX, predefine VLAN IDs, and use bonds for uplink resilience. Where available, apply SDN definitions for consistent cluster-wide networks.

Throughput guidance: Reserve live import for 10Gbps+ links. On 1Gbps WAN or MPLS, plan offline transfers and OVF exports to reduce file size.

Target VM best-practice configuration on Proxmox

A consistent virtual machine baseline speeds validation and improves runbook reliability.

We pick a CPU type for portability—use host if every node matches. For mixed hardware, select a generic x86-64-vX family so live migration remains possible across diverse systems.

Enable the Ballooning Device. It exposes real memory usage and lets the hypervisor reclaim memory safely under pressure. This keeps the server responsive and helps capacity planning.

Storage and I/O devices

Standardize on SCSI with VirtIO SCSI single and attach the boot disk on SCSI0. Turn on IO threads per disk to improve parallel I/O under load.

For thin-provisioned pools, enable discard/trim so freed blocks return to the underlying pool. That prevents long-term file bloat and keeps capacity predictable.

Guest agent and device choices

Install the QEMU guest agent in every guest. It improves shutdowns, reports IPs, and supports freeze/thaw during backups.

Choose NIC models by OS generation—VirtIO for modern systems, E1000/e1000e for legacy machines—and migrate to VirtIO after drivers are staged. Set the machine type (Q35 for UEFI Windows) and match firmware to the source system.

Validation tip: Build a golden template per workload class and record chosen version baselines. Automate creation through API or Terraform to keep configuration consistent across vms.

BIOS versus UEFI, boot order, and first-boot pitfalls

Matching firmware and boot configuration prevents needless troubleshooting on first power-up.

We mirror the source firmware: legacy BIOS becomes SeaBIOS, and UEFI maps to OVMF. This avoids early halts and missing boot device messages.

SeaBIOS and OVMF mapping

Confirm the original firmware before changing the machine type. Use Q35 for modern UEFI guests; keep i440fx for older systems.

EFI paths and efidisk handling

Ensure an efidisk exists for UEFI guests. Some OSes use custom EFI paths instead of /EFI/BOOT/BOOTX64.EFI — inspect NVRAM and add a boot entry if needed.

• Boot order: put the primary disk first, then CD/ISO, then PXE.
• If VirtIO drivers are missing, attach the system disk temporarily on IDE/SATA to boot and inject drivers.
• Verify partition style—MBR aligns with BIOS, GPT with UEFI—to reduce loader confusion.

Test first boot with console access enabled — serial or web console shows errors immediately. Capture any changes in the runbook so future vms follow the tested order and device choices.

VMware to Proxmox migration steps using the built-in ESXi import tool

We guide a practical, GUI-first import path that keeps configuration predictable and auditable. Start by enabling the test/no-subscription repositories and upgrading the node. Then install pve-esxi-import-tools (8.1.10+; recommended production 8.2) and verify the package version.

Add the ESXi server and pick the VMX

In the web interface go: Datacenter > Storage > Add > ESXi. Provide the server IP and root credentials. Scope which nodes can see the source inventory and, only if policy permits, skip cert verification.

Ensure the source VM is powered off, then select its .vmx. The interface pre-populates disks and hardware so we can review parity before any transfers.

Storage choices, live-import, and advanced options

Choose destination per disk—Directory for qcow2, ZFS for performance and replication, or LVM on SAN. In Advanced, set controllers: keep PVSCSI or disable VirtIO-SCSI for guests that lack drivers.

Avoid Live-Import unless the esxi host and target server share a 10Gbps+ low-latency network. Prefer offline copy for integrity on slower links.

Run and validate

Run the import and monitor the Task viewer. Confirm disk transfers complete and the end-state shows TASK OK. Preserve original files on the source until validation finishes.

Document any controller or storage deviations and capture the import log as an audit artifact.

Manual migration path: copy, convert, import, attach, and boot

Here we show a reliable manual flow — record hardware, copy VMDK files, convert images, and boot the machine safely.

Inventory first. Record CPU, memory, controller type, NIC model, and firmware. Detach any ISO media and keep a note of installed tools; we defer VMware Tools removal until the guest boots cleanly on the new host.

Copy file artifacts. Enable SSH on the ESXi host, stop the VM, then copy the .vmdk descriptor and -flat.vmdk data files via scp into the Proxmox images/VMID directory. Verify sizes and checksums after transfer.

OVF/OVA export as an alternative

When thin-provisioned disks matter, use ovftool to export an OVF or OVA. This reduces transfer size and keeps a single file for the file-level export path.

Convert and import

Use qemu-img convert -O qcow2 source-flat.vmdk dest.qcow2 when snapshot support helps. For speed, run qm importdisk VMID source.vmdk [-format qcow2] — this places the disk correctly and preserves metadata.

Attach, set boot order, and verify controllers

In the web interface attach the imported disk as the primary SCSI/SATA/IDE device. Pick IDE or SATA when drivers are missing, then move the drive to VirtIO SCSI after drivers install.

• Rescan storage with qm rescan and confirm file ownership and sizes.
• Set the hard disk as first boot device and match BIOS or UEFI firmware.
• Start the machine, watch the console, and troubleshoot controller or bootloader issues early.

Finish strong. After successful boot, install VirtIO drivers and the QEMU guest agent, then remove leftover VMware files. Document the final controller and NIC models for repeatable results.

Post-migration optimization of Windows and Linux guests

After cutover, we focus on guest-level tuning to ensure stable performance and minimal service disruption.

First, mount the virtio-win ISO and install drivers and tools. For Windows, add a small temporary disk on VirtIO to stage the block, netkvm, balloon, and QEMU guest agent. This reduces boot risk and enables graceful shutdowns.

Linux guests usually include virtio drivers but may need an initramfs update. Rebuild initramfs, load virtio_scsi and virtio_net, and reboot to lock in drivers.

Switching disks and NICs to VirtIO safely

We convert the primary disk to VirtIO SCSI single after staging drivers. Then we change NIC models to VirtIO while preserving MACs. Confirm link state and IP inside the operating system before removing fallback adapters.

Network settings restoration and driver order

Document original network settings and restore static IPs, DNS, routes, and VLAN tags in Proxmox if needed. Verify device naming stability—udev names on Linux and interface indices on Windows—to avoid service binding issues.

Validation, backups, and cluster or HA readiness

Before cutover, we run a concise set of tests on each host and guest. These checks confirm boot order, storage health, and network paths. We treat the checklist as a gate — no production change without passing it.

Functional tests: storage I/O, network throughput, boot order

Validate each VM: confirm correct boot order, run storage I/O tests, and measure network throughput. Record baselines and compare them to the original system so performance regressions are clear.

Set up Proxmox Backup Server and schedule backups

We configure Proxmox Backup Server targets with deduplication and incremental transfers. Schedule regular jobs and run live-restore tests to confirm RTO/RPO targets.

Cluster quorum, Corosync links, and shared storage notes

Build a robust cluster with at least three votes, or add a QDevice for two-node designs. Verify Corosync runs on low-latency, redundant links and tag shared storage—NFS, iSCSI/FC, or Ceph—in the configuration.

“Test HA failover by stopping a host and confirming guests recover on other nodes. Document timings and logs.”

• Run HA failover drills and capture results.
• Codify datacenter policies for backups, snapshots, and retention.
• Start with a pilot group of vms, refine the process, then scale.

Finalize handover with runbooks, incident contacts, and stored documentation. Confirm encryption at rest and backup integrity before opening the production window.

Troubleshooting common issues and safe rollback options

When imports fail, a short, methodical checklist helps recover systems with minimal service impact.

Non-booting guests: firmware and controller fixes

First, align firmware—SeaBIOS or OVMF—and confirm boot order. An absent efidisk or wrong NVRAM entry often stops the boot process.

If the OS refuses to start, attach the primary disk on IDE or SATA. This lets the guest load legacy drivers and regain access.

Disk size bloat and storage reclaim

Thin files can expand into thick copies during raw transfers. Prefer OVF exports or convert to qcow2 to preserve thin space.

After boot, run fstrim or defrag inside the guest and enable discard on the storage backend. That reclaims wasted blocks and reduces long-term growth.

Network loss after import: adapter model and MACs

If networking drops, revert to the original adapter model and preserve MAC addresses. This restores IP bindings and avoids service disruption.

Once drivers are staged, migrate NICs to VirtIO and verify DHCP or static settings. Test connectivity before removing fallback adapters.

“Keep the original VM powered off but intact—ready to revert if a recovery window is needed.”

Operational notes: collect Task viewer logs, system journal entries, and timestamps for root cause analysis. Verify drive and controller mappings in the GUI—unused disks often reveal attachment errors.

We keep a clear rollback option: original server remains powered off but available. Document every fix in the runbook so each machine benefits from what we learned.

Conclusion

We close by tying practical outcomes to measurable operational goals for Malaysian teams. A structured move reduces platform cost, adds enterprise-grade features, and gives clearer vendor options for future growth.

Follow the sequence: prepare, import (tool or manual), optimise guests, validate, then operationalise backups and HA. Keep a running list of migrated vms and final configs as an audit-ready artifact.

After full validation, sign off apps and decommission original esxi servers to avoid drift. Consider subscriptions for support and standardise golden images for new proxmox builds — learn more about paid vs free options in our new proxmox features. We remain available to guide pilots, waves, and KPI tracking.