Most VMware exit plans treat backup as a line item near the end. That is the wrong order. Your backup product is tied to the hypervisor far more tightly than your workloads are, and discovering the incompatibility after the migration is how organisations end up running production with no tested recovery path.

Why backup is hypervisor-specific

Modern virtual machine backup does not work like file backup. It hooks into the hypervisor’s own APIs to snapshot a running machine, track which blocks changed since last time, and restore without a full copy. Those hooks are proprietary.

VMware’s equivalent has been the reference implementation for a decade, and most backup vendors built against it first. When you change hypervisor, you are not just changing where machines run. You are changing the mechanism your backup product depends on.

What to establish before you migrate

  1. Does your current backup vendor support the target hypervisor? Ask for the specific supported version, not general support. Support often lags releases.
  2. Is changed-block tracking supported, or only full backups? This is the difference between a two-hour incremental and an eight-hour full run every night.
  3. Is application-aware backup supported? A crash-consistent snapshot of a database server is not a database backup.
  4. Can you restore across hypervisors? Genuinely important during migration, when you may need to recover a VMware backup onto the new platform.
  5. What happens to your existing backup chain? Old backups usually stay readable only by the old product. Plan retention accordingly.
Good to know: point five catches people. If you must retain backups for seven years for compliance, and those backups can only be read by a product tied to a hypervisor you are decommissioning, you need either a long-lived read-only environment or an export strategy. Decide before you switch, not after.

Vendor support: how to check properly

Vendor support for alternative hypervisors has improved considerably, and it changes often enough that any list published today will be wrong within months. Rather than trusting a comparison article, check three things directly:

Ask the vendor in writing. A sales answer and a support-matrix answer are sometimes different.

The recovery test nobody runs

Migration plans routinely include a backup cutover and routinely omit a restore test. That is the wrong way round, because the backup succeeding tells you almost nothing. What matters is whether a restore works, how long it takes, and whether the restored machine actually starts and serves.

Three tests, before you consider the migration complete:

  1. A single file restore. The most common real-world request.
  2. A full machine restore, timed. This gives you your actual recovery time objective rather than a hoped-for one.
  3. An application-level restore. Restore a database server and confirm the database mounts and is consistent.
Key takeaways
  • Backup is tied to the hypervisor more tightly than your workloads are. Check it first, not last.
  • Confirm changed-block tracking and application awareness, not just platform support.
  • Old backups usually stay readable only by the old product. Plan retention before switching.
  • Time a full restore. That number is your real recovery objective.

Where this sits in a wider exit

Backup is one workstream in a VMware migration, alongside licensing, networking, storage and the workloads themselves. Our life after VMware guide covers the whole picture and VMware migration and alternatives covers how we deliver it.

If your environment includes operational technology — plant systems, SCADA, industrial controls — the constraints are different and tighter. See SCADA and OT security, and treat any convergence of IT and OT virtualisation as a separate design decision rather than a migration detail.

A note on doing nothing

Staying on VMware is a legitimate option, and for some organisations it is the right one. The cost increase is real, but so is the risk and expense of a migration done under time pressure with an untested recovery path. If your renewal is more than a year out, use the time to test the alternative properly rather than committing early.

Frequently asked questions

Which backup vendors support Proxmox?

Support has improved considerably and changes frequently, so check the vendor's current support matrix for your exact hypervisor version rather than relying on a published comparison. Confirm which features are supported, not just whether the platform is listed, and whether support is generally available or still in preview.

Why does changing hypervisor affect backup?

Virtual machine backup hooks into the hypervisor's own APIs to snapshot running machines, track changed blocks and restore efficiently. Those hooks are proprietary. Changing hypervisor changes the mechanism your backup product depends on, which is why it should be verified before migration rather than after.

What happens to our old VMware backups after we migrate?

They usually remain readable only by the product that created them, tied to the platform you are decommissioning. If you have multi-year retention obligations, you need either a long-lived read-only environment or an export strategy, decided before the switch.

What should we test before calling a hypervisor migration complete?

Three restores: a single file, a full machine restore that you time to establish your real recovery objective, and an application-level restore where you confirm a database mounts and is consistent. A backup job succeeding tells you very little on its own.

Keep exploring

Ready for a clear path forward?

Start with a Navigate Clarity Conversation. A free 30 minute review of where you stand and what to do first.

Start with a Clarity Conversation