VMware to Proxmox migration, done for you
You are leaving VMware and you do not want to run the migration yourself. RDEM Systems takes the project: inventory, target sizing, batch cutover, validation testing, then decommissioning vSphere once production is stable.
If you would rather migrate on your own, our technical guide to migrating VMware to Proxmox covers the four available methods, the commands and the common pitfalls. This page does not repeat them: it describes what we take off your hands.
If the decision to leave has not been made yet, why IT departments are leaving VMware, and how sets out the contractual, budgetary and technical reasons we see with our clients.
What the engagement covers
Included
- Full audit and inventory of the vSphere estate
- Sizing and installation of the target Proxmox VE cluster
- Network, VLAN and storage configuration (Ceph or ZFS)
- Disk conversion and virtio driver adaptation
- QEMU Guest Agent installed on every migrated VM
- Pilot migration then batch cutover
- Validation testing and a written acceptance report
- PBS backups in place before going back into production
- Operating documentation for the new environment
Not included
- Application redesign: a migrated VM is the same VM
- Buying or renegotiating your software vendor licences
- Desktop and end-user workstation migration
- Custom development of business tools
- Day-to-day operations after sign-off — that is managed Proxmox, subscribed separately
The method, in five phases
No production VM is moved before the pilot has validated real throughput, drivers and the cutover window.
- 1
Inventory and audit
We extract the real vSphere inventory: VMs, disks, snapshots, networks, VLANs, application dependencies, active licences. We identify the VMs that will resist — hardware passthrough, encrypted appliances, Windows failover clusters, licences tied to the host hardware fingerprint. The audit is free and produces a costed plan.
- 2
Defining the target
Sizing of the target Proxmox VE cluster (CPU, RAM, Ceph or ZFS storage, network), choice of destination — your datacentre or ours — and addressing plan. This is also where network connectivity is decided: private L2L link, VPN, or public access.
- 3
Pilot migration
Two to five representative VMs go first: one Linux, one Windows, one application VM with dependencies. They measure real throughput, validate virtio drivers and the QEMU Guest Agent, and calibrate the cutover window for the batches that follow.
- 4
Batch cutover
The fleet is split into batches by criticality and dependency. Each batch is migrated, tested, then signed off by your teams before the next one starts. Large VMs are pre-synchronised in advance so the downtime window only covers the final delta.
- 5
Rollback and decommissioning
The source VMware environment stays intact until final sign-off: as long as it is not decommissioned, rolling back means powering the original VM back on. Decommissioning — shutting down the ESXi hosts, terminating support contracts — only happens once you approve it in writing.
Downtime, VM by VM
The fleet is never stopped in one go. Each VM has its own window, driven by the method chosen and the volume to transfer. Windows are agreed with you, on the slots you pick.
| Case | Method | VM downtime |
|---|---|---|
| Non-critical VM, under 100 GB | Cold migration, outside business hours | Transfer time, usually under an hour |
| Large VM, several TB | Pre-synchronisation then incremental delta | A few minutes, for the last delta and the reboot |
| Service behind a load balancer | Node-by-node cutover | No user-visible downtime |
| Appliance or VM with dedicated hardware | Handled case by case, decided during the audit | Set in the quote, never discovered on the day |
What carries over as-is, and what does not
Carried over unchanged
- The guest operating system, with no reinstall
- Data and partitions, block for block
- IP addresses and VLANs, where the target topology allows
- UEFI boot, converted to OVMF with an EFI disk
- Windows volume licences (KMS, MAK)
Replaced or reworked
- VMware Tools, removed and replaced by the QEMU Guest Agent
- Disk and network drivers, replaced by virtio
- vSphere snapshots, consolidated before migration
- Hardware passthrough, reconfigured on the Proxmox side
- OEM licences tied to the host hardware fingerprint
- Backups, rebuilt on Proxmox Backup Server
Typical duration by fleet size
These cover the whole project, from audit to final sign-off, excluding hardware or network circuit lead times. Data transfer is rarely the limiting factor: the available cutover windows are what drive the schedule.
| Fleet size | Typical duration | Batching |
|---|---|---|
| 1 to 10 VMs | 1 to 2 weeks | One pilot, then one or two batches |
| 10 to 50 VMs | 3 to 6 weeks | One pilot, then weekly batches |
| 50 to 150 VMs | 2 to 4 months | Batches per application domain, staged sign-off |
| Over 150 VMs | Dedicated plan | Phased project, with extended VMware / Proxmox coexistence |
Real examples: 100 VMs moved to our infrastructure (fr) and a VMware to Proxmox migration case study (fr).
Where the migrated fleet lands
This is the structuring decision of the project, taken in phase 2. Both destinations use the same migration method; they differ in what happens afterwards.
On your own hardware
The Proxmox VE cluster is installed on your servers, on your premises or in your datacentre. You keep ownership of the hardware and the infrastructure.
After sign-off you either run the cluster yourself, or hand operations to us at €150 excl. VAT/month per hypervisor — see managed Proxmox.
On our infrastructure, wired to your offices
The fleet is hosted in our racks at Equinix Paris and connected to your premises by a private L2L link we provide: dedicated VLAN, private addressing, no transit over the public Internet. The fibre circuit is ordered and held by RDEM — you sign no telco contract of your own.
Your VMs become a resource of your internal network. VM rates are on the Proxmox hosting pricing page; the private circuit is quoted separately.
Why the private link changes the nature of the project
RDEM Systems runs its own network: AS206014, BGP routing, presence at Equinix Paris. The circuit to your offices we order from a local loop carrier, integrate into that network and hold the contract for. The result is a layer-2 link between the datacentre and your offices rather than plain Internet access to a control panel — and a single supplier facing you.
In practice, a VMware estate that used to live in your server room can move into a datacentre without becoming a service exposed on the Internet: same private address ranges, same VLANs, same filtering rules. The server, the link and the operations come from the same supplier — one contact when something goes wrong. A VPN remains available as an option for remote users.
How the engagement is billed
- The audit is free. It produces the real inventory of the estate, the list of hard cases and a costed migration plan. It is yours even if you do not proceed.
- The migration is a fixed-price quote, issued after the audit. The variables are the number of VMs, the volume of data to move, the number of cutover windows and the availability constraints.
- There is no licence cost. Proxmox VE is open source. Only the engagement, the optional support subscription and managed services are billed.
- Operations are a separate subscription: €150 excl. VAT/month per hypervisor for a managed dedicated cluster, or the VPS rates on the pricing page if the fleet is hosted with us.
- Network connectivity is its own line. If the fleet lands with us behind a private link, the fibre circuit is quoted after we qualify your address — it is not included in the VM rate.
To size the licence savings, our VMware vs Proxmox TCO analysis for 2026 works through three costed scenarios.
Frequently asked questions
Start with the audit
It gives you the real inventory of your VMware estate, the list of VMs that will cause trouble and a costed migration plan. It is free and carries no commitment.
You are handing your production estate to a supplier: who RDEM Systems is — a French company, a network operator, references and team.