The VMware Alternative Operating-Gap Checklist

The question that decides whether a VMware replacement succeeds

Most VMware replacement conversations begin with the wrong question: which hypervisor replaces ESXi? Conversion tooling is mature, and moving a virtual machine from one hypervisor to another is now the most solved part of the entire project. The question that decides whether a VMware replacement succeeds is different: what else was vSphere quietly doing for you, and what takes over each of those jobs on day one?

For most estates, the hypervisor was the visible tenth of the platform. Around it sat capacity management, storage health, HA behavior your applications silently depend on, backup integration, DR runbooks written against VMware APIs, VDI, monitoring integrations, and a decade of operational habit. A migration plan that lists VMs but not these functions is a plan for a successful conversion and a failed operation.

This guide is written to be worked through, not skimmed: print it, fill in the discovery fields, and take every unanswered checklist line into your assessment as an open risk.

The operating-gap checklist

For each area, the question is the same: who or what does this job on the target platform, from day one, at 2 a.m.?

• Centralized management: who sees capacity, health, and change across every cluster and site after the migration, and in which console?
• Cluster lifecycle and patching: how are hypervisor updates staged, tested, and rolled across clusters without an outage, and who owns the schedule?
• Storage and failure domains: what replaces the storage integration you rely on today, who watches its health signals, and what is the real failure domain of the new design (node, replica set, site)?
• HA and maintenance behavior: which workloads silently depend on automated restart and migration behavior, and what provides it on the target platform?
• Network operations: how are paths, VLANs, and upstream causes visible around the new hosts, and what replaces any distributed-switch or overlay features in use?
• Backup and restore testing: does your backup platform support the target hypervisor at the same depth, and what changes about restore testing cadence and evidence?
• Service-level disaster recovery: every runbook step that names a VMware API or console needs a rewritten, retested equivalent before cutover, and recovery must be planned per service, in dependency order.
• VDI and application delivery: if Horizon or similar is in the estate, desktops are their own migration with their own timeline, profiles, and GPU questions.
• GPU workloads: passthrough and vGPU behave differently across hypervisors; test the exact card, driver, and workload combination before committing a wave.
• Identity, roles, approval, and audit: who can do what on the new platform, which actions require approval, and where is the audit record?
• Multi-site and edge: how do small sites without local expertise get managed, patched, protected, and recovered on the new platform?
• Monitoring, PSA, ITSM, RMM, and documentation integration: every alert route and CMDB sync that points at vCenter needs a target-platform equivalent.
• Operational skills and support: name the people who will run the target platform at 2 a.m., and the support contract behind them.
• Coexistence: the estate will run on two platforms during the transition; decide how both stay visible in one place for that whole period.
• Rollback: define, per wave, what rollback means and how long it stays possible.

How to sequence the work

Treat the replacement as waves, not an event. Inventory and dependency-map first. Move the workloads with the fewest dependencies and the least restrictive recovery objectives, prove the full operational loop on them, including backup, restore test, monitoring, and an on-call incident, and only then schedule the systems the business would notice.

The estates that struggle are almost never the ones with the hardest workloads. They are the ones that migrated faster than their operating model, and discovered the gaps in production.

Where Ixvara fits

Ixvara VM manages open virtualization with the fleet operations, storage context, guarded lifecycle actions, and cross-stack visibility this checklist demands, and keeps VMware and Hyper-V visible during coexistence where supported. The VMware Alternative Assessment works through this checklist against your actual estate.