Audit of the current estate
Before planning, we measure. The goal is to have an exhaustive map of what is running, on what, under which licence, with which dependencies.
Complete list VMs / hosts / clusters / datastores in CSV. Tool: `Get-VM` PowerCLI or native vCenter export.
VMware now bills per core (32 cores minimum/socket). Count precisely to compare with target licences.
vSphere Standard, Enterprise Plus, VVF, VCF? Expiry date? Post-Broadcom subscription? It is the project's countdown.
Document standard/distributed vSwitches, port-groups, dvSwitch, MTU, LAG, NIC teaming. Essential to reproduce in Proxmox.
vSAN? FC SAN? iSCSI? NFS? Volumes, snapshots, occupancy rate, observed IOPS. Drives the Ceph / ZFS / NFS choice on Proxmox.
DRS, HA, vMotion, FT, NSX, vSAN, SRM, Horizon View: note what must be functionally replaced (Ceph, Corosync, PVE-HA, etc.).
Veeam? VDP? How are VMs restored today? Dated restore tests? PBS can replace the majority of cases.
Windows 2008 R2? CentOS 6? Ubuntu 14.04? Identify VMs too old for recent VirtIO — they will have to be stabilised before migration.
Top 20% of VMs that carry 80% of the criticality. These are migrated last, after perfect validation of the others.
Which VM depends on which VM? Shared databases, NFS, shared files. A broken migration is avoided with this graph.
Target choice & sizing
Proxmox VE is the default target at DYB for 90% of exit-Broadcom migrations. But hardware sizing and storage / network / HA trade-offs deserve calculation.
Open-source, GPL, optional support. Proxmox subscription €115 to €1,080/CPU/year for priority bug fixes. Compared with: Hyper-V, Nutanix AHV, OpenStack.
Count +20% margin on CPU/RAM (historic vSphere over-sizing is often identified). 3-node cluster minimum for HA.
Ceph (equivalent to vSAN, distributed, scalable) for > 5 nodes. Replicated local ZFS for 2–3 nodes. Shared NFS acceptable but SPOF.
Corosync (Proxmox HA) must have its own low-latency network (10G recommended). Separated from VM and storage networks.
PBS replaces Veeam in 80% of cases, free, global deduplication. Veeam remains relevant if multi-hypervisor compatibility is needed.
Hardware cost (recent ESXi hosts can often be reused) + DYB project. Budget signed before POC.
Target infrastructure preparation
We build the future Proxmox cluster IN PARALLEL with the existing VMware. No destructive switchover. During this phase, vSphere remains in production.
System disks in ZFS mirror, separation of mgmt/cluster/storage/VM networks. Disk encryption if regulatory requirement.
Create cluster, add nodes, configure Corosync on dedicated network. Initial HA failover test.
Ceph cluster 3+1 minimum for replication, OSDs on dedicated disks (NVMe or enterprise SSD). Pool configuration (1 per usage).
vmbr0 mgmt, LACP bonds with multi-vendor switches, VLANs reproduced identically. Connectivity test VM by VM.
Dedicated datastore (~2× fleet size), write tests, incremental and retention configuration. Optional offsite replication.
Reproduction of vCenter permissions in Proxmox: LDAP/AD for authentication, RBAC for per-folder permissions.
Integration with Zabbix / Centreon / Wazuh: cluster SNMP, Ceph metrics, alerting. Grafana dashboard for management.
Cluster diagram, host-addition procedure, restoration procedure, incident escalation. Delivered before the first VM migration.
POC & validation
We migrate 5 to 10 representative VMs — a Windows, a recent Linux, an old Linux, a database, a VM with a snapshot. Everything is validated before scaling up.
Coverage of use cases: Windows OS, modern Linux OS, legacy Linux OS, database, application with shared storage.
Tool: qemu-img convert. Checksum validation before/after. Read/write performance compared with vSphere.
Windows: install VirtIO drivers from Fedora ISO before switchover. Modern Linux: already included. Legacy Linux: initrd recompilation sometimes needed.
Boot, disk/network/CPU performance, 72h stability, HA behaviour (kill node), live migration, snapshot, PBS restore.
The application team tests: user login, performance, integrations, backups/restores. Go/no-go documented.
Presentation of POC results to management. Official decision to launch mass migration, scope by batch, schedule.
Migration in batches
No big-bang. We migrate in batches of 10 to 30 VMs, from least to most critical. Each batch validated before the next. Rollback possible until the end.
Batch 1: test/dev VMs. Batch 2: non-critical internal VMs (DNS, monitoring). Batch 3: standard applications. Batch 4: critical applications. Batch 5: databases and core IS.
Planned date, switchover window (15–30 min per standard VM), DYB owner, client contact, rollback plan.
D-7 announcement with expected impact (short or zero outage). Internal memo. Emergency number during the window.
Final snapshot on VMware side. Incremental qemu-img conversion. Boot on Proxmox. Connectivity, services and application test. Live documentation.
Immediate PBS backup on the migrated VM + restore test on pre-prod cluster. As long as the restore is not validated, the VM is not considered migrated.
Each application is tested by its business owner within 48h post-switchover. Anomalies raised and tracked.
Green/red batches, anomalies addressed, process adjustment for the next batch. Weekly coordination committee.
As long as the source VMware VM is not decommissioned, rollback is possible in under 30 min. It is an indispensable safety net.
Final switchover & cutover
When 100% of VMs are migrated and validated, we officially switch the production flows: network, backups, supervision, user access.
No more vCenter read/write access for ops teams. All operations go through the Proxmox interface.
Deactivate vCenter probes in Zabbix/Centreon. Activate Proxmox probes. Validate the absence of monitoring gaps.
If PBS chosen: Veeam disabled on migrated VMs. Validate PBS backup chains over a minimum of 7 days before complete Veeam shutdown.
Simulate loss of a Proxmox node + restore of a critical VM from PBS on an empty cluster. Documented and signed off.
Final presentation, KPIs (cumulative downtime, anomalies, realised vs estimated savings). Official decision to close the migration project.
Announcement to all teams: the switchover is complete, new operational flows are in place. Emergency number remains active for 30 days.
Final diagrams, complete runbook, register of operations performed, training delivered, contacts. Everything at the client in the clear.
VMware decommissioning
Often overlooked — and yet the most important on the budget side. As long as vSphere runs, you pay. As long as hosts are configured in a vCenter cluster, you risk errors.
We keep vSphere on for 30 days after the last migrated VM, read-only, for emergency intervention. No VM runs on it any more.
Termination notice, return of licences, contract archiving. Confirm end of subscription for the next renewal.
Complete export: configurations, logs, alarms, audit trail. Retention 12 months minimum (traceability audit).
If physical hosts are reused as additional Proxmox nodes: complete wipe, Proxmox install, cluster integration. Resale otherwise.
vCenter VM stopped, backed up, archived and then deleted. DNS/AD cleaned. No more vCenter reference in the documentation.
Post-migration optimisation
Once in cruise mode on Proxmox, we get the maximum out of the new platform: density, automation, operational costs.
Measure used vs allocated CPU/RAM ratio. Often, +18% density possible without degradation = hardware consolidation.
Automated VM provisioning via Terraform Proxmox provider. Configuration via Ansible. No more manual UI provisioning.
Retention by VM criticality, automatic monthly restore verification, alerting if PBS chain broken.
Available capacity, next hosts to purchase, Ceph/ZFS evolution, planned Proxmox 8 → 9 upgrade.
Verification of actually realised savings vs initial estimate. Inputs for the next exit-Broadcom migrations in the group.
A 30-minute audit to validate your scope.
You describe your fleet, we tell you what is migratable, what needs particular attention, and a rough order of magnitude for the project and the savings. No commitment, no sales PowerPoint.
Everything we get asked about this checklist
For 20–50 VMs on 2–4 hosts: 6 to 10 weeks including audit, POC, batch migration and training. Beyond 200 VMs or with a vSAN cluster to rebuild, it becomes a 3- to 6-month project split into phases.
Yes — it is the very guarantee of zero risk. Throughout the migration phase, both clusters run. A VM is considered migrated only after business validation AND PBS restore test. vSphere decommissioning only after 30 days of stability.
Veeam supports Proxmox since 2024 (Veeam Backup & Replication v12.2+). But we recommend Proxmox Backup Server (PBS): free, global deduplication, Zstd compression, infinite incrementals. PBS replaces Veeam in 80% of cases with licence savings of €2,000 to €8,000/year.
This is our most frequent case. DYB orchestrates the entirety: audit, POC, batch migration, training, post-switchover operations. Your teams remain decision-makers on business trade-offs, but the technical side is handled by our certified Proxmox team.
90% yes. The phases are identical, only phase 4 (POC) changes: .vhdx conversion instead of .vmdk, Windows VirtIO drivers to install before switchover. Ask us for the Hyper-V version if relevant for you.
Not yet. For now, you can use it online — your ticked boxes are saved in your browser (you can close and come back). A PDF version is coming soon, write to us to be notified.
