A VMware to Proxmox migration can look straightforward on paper: transfer the virtual machines, adapt their configuration and restart them on the target platform.
In the field, the hardest problems rarely come from disk conversion alone. They are more likely to involve application dependencies, networking, business validation, backup and the ability to roll back safely.
Here are seven mistakes observed in real operating conditions — and the precautions to take before scaling a migration across an entire environment.
Mistake 1: relying only on the VMware inventory
The first step is often to export the vCenter inventory: number of virtual machines, CPU, memory, disk capacity, operating systems and VMware Tools status.
This information is essential, but it is not enough to build a migration plan.
A seemingly simple VM may depend on:
- a specific DNS or NTP server;
- a file share;
- a database hosted on another machine;
- an IP address hard-coded in a configuration file;
- a network or security appliance;
- a licence tied to a hardware characteristic;
- a service with no clearly identified owner.
The inventory describes the machine. It does not necessarily describe the service delivered by that machine.
Before any migration, the technical inventory must therefore be supplemented with a map of application, network and organisational dependencies.
You need to know who uses the service, who can validate it and which other components are required for it to function.
Mistake 2: treating a booted VM as a validated VM
Seeing the login screen after a migration is reassuring. It is only the first step in the acceptance process.
A VM can boot successfully while still suffering from:
- an incorrectly detected network interface;
- an invalid IP configuration;
- a stopped application service;
- a failed scheduled task;
- a DNS resolution problem;
- a significant performance drop;
- a missing monitoring agent;
- a backup job that no longer works;
- a remote dependency that has become unreachable.
Validation must cover several levels:
- operating system boot;
- network configuration;
- service status;
- application operation;
- validation by the service owner;
- monitoring and backup;
- behaviour after an additional restart.
Validation criteria must be written before the migration. Otherwise, success depends on an improvised assessment during the cutover window.
Mistake 3: using the pilot as a simple demonstration
A pilot should not merely demonstrate that a VMware VM can run on Proxmox.
That demonstration is useful, but it does not yet prove that the same method can be applied to dozens or hundreds of machines.
The pilot must produce measurements:
- preparation time;
- transfer duration;
- conversion or restore duration;
- service downtime;
- acceptance-test duration;
- performance before and after migration;
- time required to return to the source;
- actual workload for the technical teams.
These measurements are then used to determine batch sizes, maintenance windows and the people required for the next stages.
A pilot that ends with “the VM works” is incomplete. It must also answer a more important question: is the method reliable, repeatable and documented enough to be industrialised?
Mistake 4: underestimating the network
Migration planning often focuses on disk formats, import methods and guest operating-system compatibility.
Yet a significant proportion of migration problems appear in the network layer.
Before migration, verify:
- the mapping between VMware port groups and Proxmox bridges;
- the VLANs allowed on physical interfaces;
- the MTU;
- routes and gateways;
- firewall rules;
- DHCP reservations;
- DNS records;
- application-to-application traffic flows;
- addresses hard-coded in configuration files.
An incorrect mapping between a VMware network and a Proxmox bridge can make a healthy VM appear to have failed when the problem lies entirely in its surrounding environment.
Network mapping must not remain implicit. It should be a migration deliverable, with a clear correspondence between the source environment and the target platform.
Mistake 5: deleting or changing the VMware source too early
A migration should not immediately create a point of no return.
During the pilot and the first migration batches, the VMware source should remain available until technical, application and business validation has been completed.
This safeguard must still be controlled. Simply leaving the former VM powered off somewhere in vCenter is not enough.
You need to define:
- its state before migration;
- the conditions under which it may be restarted;
- who is authorised to make that decision;
- how IP addresses and DNS names will be handled;
- how data created after cutover will be treated;
- how long the source will be retained before final deletion.
The rollback procedure must specify:
- the events that trigger it;
- the decision deadline;
- individual responsibilities;
- the restoration procedure;
- the checks to perform after returning to the source;
- the handling of any divergent data.
The source should only be deleted after final validation and after the agreed safety period has expired.
Mistake 6: organising batches only by technical convenience
Starting with low-criticality VMs is a good way to validate the method. Organising the entire project only by technical convenience, however, can create new inconsistencies.
Two VMs belonging to the same application may need to be migrated together. Conversely, two machines in the same VMware cluster may have different owners and completely different maintenance windows.
A coherent migration batch groups workloads that share:
- a business dependency;
- a change window;
- a validation team;
- a similar criticality level;
- a compatible rollback strategy.
The correct unit of migration is therefore not always the virtual machine. It is often the application service.
This approach also simplifies communication. Each batch has a clear scope, identified owners and shared validation criteria.
Mistake 7: forgetting day-two operations
An operational Proxmox platform does not guarantee that the organisation is ready to run it over the long term.
Before scaling the migration, the team must know how to:
- create and restore a backup;
- diagnose a VM that does not start;
- check storage health;
- verify replication;
- manage updates;
- interpret alerts;
- locate the relevant logs;
- apply a recovery procedure;
- contact the appropriate support level.
Changing hypervisors also changes operating practices.
Reproducing every VMware habit on Proxmox is not always appropriate. Replacing those habits without documentation, however, creates a new dependency: reliance on the individual who designed the platform.
Monitoring, backup and recovery procedures must therefore be validated during the pilot, not several weeks after production deployment.
How field experience changes the method
These mistakes show that a VMware to Proxmox migration should not be treated as a simple conversion exercise.
A robust method follows several principles:
- understand services before moving VMs;
- measure pilot results;
- define validation criteria in advance;
- prepare the target network;
- retain a controlled return path;
- organise batches around dependencies;
- prepare the team that will operate the new platform.
The technology used to transfer the machines matters. The ability to decide, validate and roll back matters more.
Checklist before issuing a GO
Before approving a migration or a new batch, verify that:
- the source VM is backed up and its state is known;
- its dependencies have been identified;
- the target network is ready;
- the migration procedure has been tested;
- the expected downtime has been accepted;
- the validation criteria are documented;
- the service owner is available;
- the rollback has both a trigger and a decision-maker;
- backup is configured on the target platform;
- monitoring is operational;
- results will be recorded after the change.
If several of these points remain uncertain, abandoning the migration is not necessarily the right decision.
It may be better to extend the pilot, reduce the scope or split the batch into several stages.
Point of view
Moving from VMware to Proxmox is technically achievable in many environments. Success, however, should not be measured by the number of VMs transferred.
It should be measured by the organisation's ability to maintain services, validate their operation and regain control when something deviates from the plan.
A controlled migration relies on three capabilities: understanding dependencies, measuring outcomes and preserving a path back.
Speed comes afterwards.