ARTICLE

VMware renewal coming up? A Proxmox migration checklist

ILS Networks July 26, 2026 An 8-step checklist

Since Broadcom acquired VMware, a licensing renewal has turned from a routine technical step into a strategic decision. This is a practical 8-step checklist: what to verify, what to decide, and how a migration to Proxmox VE is run as a controlled, staged process.

Broadcom’s acquisition of VMware changed the commercial model: perpetual licenses were discontinued in favor of subscriptions, standalone products were consolidated into bundles, and partner programs changed. Many enterprises now receive a renewal quote that looks very different from the previous one — which makes the next renewal a decision point, not an automatic action.

That does not mean every organization must leave VMware. It does mean the decision deserves a complete picture: what actually runs in the environment, what the alternatives cost, and what an orderly migration to Proxmox VE looks like — an open-source virtualization platform with clustering, HA, live migration, and a dedicated backup stack.

At ILS Networks we run these migrations as a controlled, staged infrastructure change — with a rollback plan for every phase — as we did in the Ariston Group project. The checklist below summarizes the steps we walk through with every organization weighing the decision.

Understand what actually changed at renewal

Before comparing alternatives, understand why the new quote looks different. Broadcom’s changes are the market context for the decision:

Perpetual licenses were discontinued — VMware licensing moved to a subscription-only model.
Standalone products were consolidated into bundles such as VMware Cloud Foundation and vSphere Foundation — your quote may include capabilities you do not use.
Pricing is per-core, with a minimum number of cores per CPU.
Partner-program changes affected the purchasing and support channels of many customers.
Mark the renewal date and plan backwards: a serious evaluation and an orderly migration take months, not weeks — start well before the quote expires.

Inventory and assess the current environment

You cannot plan a migration on assumptions. The first step is a complete picture of what runs today:

List every virtual machine: operating system, vCPU, memory, disks, snapshots, and VMware Tools status.
Map hosts and clusters: CPU generations, memory, local versus shared storage.
Document storage: datastores, SAN/NAS arrays, protocols (iSCSI, NFS, FC), and any RDM disks.
Map networking: vSwitches and Distributed Switches, VLANs, NIC teaming, and firewall dependencies.
Inventory non-VMware licensing: Windows Server, databases, and software tied to hardware, MAC addresses, or UUIDs.
Document backup jobs and every integration that talks to vCenter (backup, monitoring, automation).
Classify workloads: critical (migrate last, with the most preparation), sensitive (special handling — for example, hardware-bound licensing), and move-first candidates (low risk).

Decide the target architecture

Proxmox VE has design decisions to settle before a single machine moves:

Cluster design: number of nodes, quorum (an odd node count or a QDevice), and failure domains.
Storage: ZFS (single node or replication between nodes), Ceph (three or more nodes, scale-out), or shared iSCSI/NFS storage — each with different HA and performance characteristics.
Networking: Linux bridges, VLANs, and bonding, with separation of management, storage, and VM traffic.
HA and live migration: which workloads need automatic recovery and which are fine with manual handling.
Decide which workloads, if any, stay on VMware — for example, vendor appliances supported only on ESXi. A partial migration is a legitimate outcome.

Plan licensing and cost

The right comparison is between the complete pictures, not between license line items:

Price the VMware renewal in full: per-core subscription, bundle tier, and commitment term.
Proxmox VE is open source with no per-core licensing; an enterprise subscription is optional, priced per CPU socket, and provides the stable update repository and vendor support.
Budget the migration as an infrastructure project: planning, a pilot, a staged cutover, hardware or storage changes if needed, and team training.
Do not rely on generic savings figures from the internet — model your own before/after costs on your environment. The result differs from one organization to another.
Settle the support question: who answers at 3 a.m. — a Proxmox subscription, an Israeli integrator, or an in-house team.

Re-architect backup and disaster recovery

A platform migration is the opportunity (and the obligation) to re-examine the entire data-protection design:

Proxmox Backup Server: incremental backups, deduplication, and encryption, with built-in backup verification.
Veeam supports Proxmox VE since Veeam Backup & Replication 12.2 — existing Veeam customers can stay on the backup platform they know.
ZFS replication between nodes for fast local recovery of selected machines.
An offsite copy: PBS remote sync to a secondary site or a DR location.
Define RPO and RTO per workload class, derive schedules and retention from them — and test actual restores, not just that the backup job “ran”.

Pilot on non-critical workloads

Before touching production, prove the process on an environment that can tolerate mistakes:

Pick a small set of low-risk machines that covers the organization’s main operating-system types.
Validate the conversion path: importing VMware disks, installing VirtIO drivers on Windows, and re-mapping networking.
Compare performance before and after under real load.
Run a full backup-and-restore cycle on the pilot machines with the new backup design.
Define a rollback plan per stage: what triggers a rollback and how long it takes.
Only after the pilot passes every check do you move on to production.

Cut over in staged waves

Production is not moved all at once. Work in waves, ordered by business priority:

Split workloads into waves: low risk first, critical systems last.
Schedule a pre-agreed maintenance window for each wave with the business stakeholders.
Verify each wave — services up, applications tested, backups running — before starting the next.
Keep the source machines powered off but intact until the wave is fully verified.
Communicate maintenance windows and expected impact to users in advance.

Validate, document, and hand over to operations

The migration is finished only when someone has proven that everything works — and documented how:

Acceptance testing with system owners and users, not just infrastructure checks.
Restore tests that prove the defined RPO/RTO targets: restore real machines and files and measure the time.
Full documentation of the final architecture: cluster, storage, networking, backup schedules, and runbooks.
Update monitoring and alerting for the new platform.
Secure an operational envelope after go-live — ILS Networks provides 24/7 support for the environments it manages.

SOURCES

Official sources for the key facts

These vendor sources document the licensing changes, subscription model, migration capabilities, and backup support referenced in this article.

What this looks like in practice

VMware to Proxmox migration service Case study: Ariston

ABOUT THE AUTHORS

ILS Networks

ILS Networks has been building enterprise IT infrastructure in Israel since 2009 — virtualization, networking, information security, and backup — with 24/7 support.

Published: July 26, 2026 · Updated: July 26, 2026