Perpetual licences are gone, the product line was rebundled, and per-CPU core minimums mean a small cluster now gets priced like a large one. We move ESXi environments onto Proxmox VE - on your schedule, with a rollback that stays available until you say otherwise.
Since the Broadcom acquisition, the parts of VMware that made it easy to budget for have been removed one by one. Perpetual licences were retired in favour of subscription. Dozens of SKUs collapsed into a small number of bundles, so the feature you wanted now arrives attached to several you did not ask for. Licensing moved to a per-core model with a minimum core count per CPU, which means a modest two-socket host is billed as though it were far larger than it is.
Then the channel changed too. Long-standing resellers lost their authorisation, and a lot of shops found out at renewal time that the partner they had worked with for a decade could no longer quote them.
The result is familiar: the same three hosts, running the same VMs, doing the same work - and a renewal that arrives at a multiple of last year's.
The honest comparison. Proxmox is not a toy, and it is not a like-for-like clone either - there are places where vSphere is still ahead. Here is where the differences actually land for a small or mid-sized environment.
| VMware vSphere today | Proxmox VE, co-managed by us | |
|---|---|---|
| Licensing model | Subscription only. Perpetual licences retired. | Open source. An optional support subscription per socket - no licence keys gating features. |
| What drives cost | Core counts, with per-CPU minimums and bundle tiers. | Your support level. The hypervisor itself does not meter your hardware. |
| Feature gating | Features sit in tiers. The one you need is usually one tier up. | Clustering, HA, live migration, replication and backup are all in the base product. |
| Clustering & HA | Mature, well understood, and licensed. | Built in. Quorum-based, with automatic restart of guests on a failed node. |
| Live migration | vMotion. | Live migration of running guests between nodes, including between dissimilar hardware in most cases. |
| Storage | VMFS, vSAN, or your existing SAN. | Your existing iSCSI / NFS / Fibre Channel SAN, or local ZFS with scheduled replication between nodes. |
| Backup | Third-party product, licensed per socket, per VM, or per agent. | Integrated, incremental, deduplicating backup with verified restores - included in what we run for you. |
| Upgrades | Tied to your entitlement and support status. | Ordinary maintenance. We do them for you, in a window, node by node. |
| Support | Vendor queue, contingent on an active subscription. | Us, by name - with a vendor subscription underneath where you want one. |
| If you stop paying | Entitlement to updates and support ends. | The platform keeps running. You lose our involvement, not your infrastructure. |
Where vSphere still wins: very large estates, deep NSX or vSAN investment, VDI built on Horizon, and third-party appliances that only ship an OVA with VMware-specific tooling. We will say so if that is you - see the straight answers below.
The order matters more than the tooling. Nothing in production changes until a pilot has already proven the process on your hardware, with your VMs.
Every VM, its resources, its storage, and - the part that gets missed - what talks to what. Licence-bound applications, hardware dongles, static IPs, and anything with an appliance-style vendor agreement get flagged now rather than at 2am on cutover night.
The new cluster is built and burned in while vSphere keeps running untouched. If you have hardware headroom we use it; if you do not, we usually start by freeing one host from the existing cluster.
A test VM, then a low-risk production one. This is where we confirm import speed, driver behaviour, performance, and how long a given VM is actually offline - so the cutover plan is based on measurement, not estimate.
VirtIO drivers staged into Windows guests ahead of time, boot mode confirmed, agents installed. Most of this happens while the VM is still running on VMware.
Grouped by dependency, not alphabetically. Each wave is verified - service up, application tested, backups running - before the next one starts. Most VMs are offline only for the final delta sync and boot.
We migrate by copy, never by move. Your source VMs stay on VMware, shut down but complete, until you have lived with the new platform long enough to sign off. Rolling back a wave means powering the old VM back on - not a restore, not a rebuild.
The environment is documented as we go - what runs where, how it is configured, how to recover it. Only when you release it do we reclaim the old hosts and help you close out the VMware subscription.
Yes. Windows Server and Windows desktop guests run well with VirtIO drivers, which we stage before the move. Your Windows licensing is a separate matter from your hypervisor and does not become invalid because the host changed - though if you license Windows per physical host, we will work that into the host sizing rather than let you find out later.
Usually yes - iSCSI, NFS and Fibre Channel all work. Keeping the array you already bought is often the cheapest path. If your storage is itself end-of-life, local ZFS with scheduled replication between nodes is frequently a better answer than buying another SAN, and we will show you the trade-off rather than just quoting one.
These are the genuinely hard cases. vSAN has a reasonable path. NSX and Horizon do not migrate - they get replaced by a different design, which is a bigger project and needs to be scoped as one. If you are deep into those, we will tell you honestly whether the move is worth it rather than sell you a migration that ends badly.
Common, and usually survivable - most OVAs import and run fine. The real question is support posture: some vendors will decline to help while it runs elsewhere. We identify those in the inventory step and you decide, up front, whether that appliance stays on a small VMware footprint or moves with everything else.
We do. That is the point of the co-managed model - your team keeps the users and the applications, and the platform underneath becomes our problem. A Proxmox support subscription can sit underneath that where you want vendor backing as well.
For a typical small cluster - three hosts, twenty to forty VMs - assessment and build is a couple of weeks, and cutover happens over two or three maintenance windows. Bigger or more entangled environments take longer. We will give you a schedule after the inventory, not before it.
Then do the assessment anyway. Knowing what the migration would cost and how long it would take is the only thing that gives you a real position at renewal time. Plenty of people use it as leverage and stay another year - that is a legitimate outcome.
Hypervisor licensing. Firewall subscriptions. Backup seat counts. Per-endpoint tooling. Individually they are line items - together they are a business you do not control, renewing on somebody else's schedule at somebody else's price.
A technical conversation, not a discovery call.
Tell us what you are running - hosts, sockets, VM count, when the renewal lands. We will tell you what the move looks like, roughly what it costs, and whether it is the right call for you at all.
We do not share your details, and we will not add you to a drip campaign.