VMware to Nutanix Migration: The 2026 Playbook
An end-to-end playbook for migrating from VMware Cloud Foundation to Nutanix AHV in 2026 — workload classification, the Nutanix Move tooling, ecosystem migration, the cutover sequencing that consistently produces successful outcomes, and the patterns that consistently produce failed ones.
The decision to migrate from VMware to Nutanix is the largest infrastructure decision most enterprise customers will make in this decade. The decision is consequential commercially, operationally, and strategically. Getting the migration project right is therefore a different exercise from any standard platform refresh — the cost of error is higher, the political stakes are larger, and the operational disruption is more visible.
This piece is the consolidated playbook from end-to-end engagements over the post-Broadcom period. It describes the phased project structure that consistently produces successful outcomes, the workload classification work that determines migration sequencing, the tooling reality, the ecosystem migration considerations, and the common patterns that produce failed or stalled projects.
The five-phase project structure
The pattern that consistently produces successful VMware-to-Nutanix migrations across the engagement data follows a five-phase structure. The phases overlap somewhat in practice but each has distinct success criteria.
Phase 1: Evaluation and decision (2-4 months)
The evaluation phase confirms that Nutanix is the right target platform and produces the costed migration plan that justifies the project. Activities include a workload inventory and classification, a proof-of-concept Nutanix deployment with one or more representative workloads, ecosystem-tooling validation (backup, monitoring, security), a negotiated Nutanix proposal, and a costed end-to-end migration plan.
The deliverable from this phase is a board-quality business case: the migration cost, the steady-state cost difference, the migration timeline, the risk register, and the recommended go / no-go decision. Customers who try to skip this phase — or run it as a brief informal exercise — typically discover problems mid-migration that should have been identified before the project started.
Phase 2: Platform construction and pilot (3-5 months)
The platform construction phase builds the production Nutanix environment to which workloads will eventually migrate. Activities include hardware delivery and installation, network connectivity (typically a parallel deployment alongside the existing VMware environment), cluster setup, integration with identity systems (Active Directory or LDAP), the integration of management and monitoring tools, and the migration of a pilot set of non-critical workloads to validate the end-to-end migration process.
The pilot is critical. The first ten to fifty workloads migrated should be selected specifically to exercise the migration tooling, the ecosystem integration, the operations runbooks, and the recovery procedures. The pilot phase is where the migration runbook is refined from theoretical to operational. Skipping the pilot is the most common cause of migration projects that go badly in subsequent phases.
Phase 3: Scaled migration (6-18 months)
The scaled migration phase moves the bulk of standard workloads from VMware to Nutanix. Migrations are organised into waves, typically of 50-200 workloads each, with explicit success criteria and a defined wave-completion cadence. Wave structure typically follows business-unit, application-stack, or environment (dev/test/prod) boundaries to allow application teams to coordinate the migration of their own workloads.
The scaled phase is where the migration capacity of the project team — measured in workloads per week — drives the overall timeline. Realistic capacity for a well-tooled migration team is 50-100 standard workloads per week; complex workloads slow this substantially. Capacity-planning the migration team is as important as planning the workloads.
Phase 4: Complex and stragglers (3-6 months)
The complex-workloads phase handles workloads identified during the evaluation as either technically complex (deep VMware integration, specialised configurations) or politically complex (critical applications with low downtime tolerance, applications owned by teams that resisted earlier waves). These workloads typically require bespoke migration planning rather than standardised wave-based execution.
This phase is often where the migration project's reputation is built or lost. Successful execution on complex workloads — particularly visible production applications — builds confidence in the new platform; failed execution on these workloads can lead to long-tail political issues even when the bulk of the migration was successful.
Phase 5: Decommissioning (3-6 months)
The decommissioning phase retires the legacy VMware environment in stages. Activities include hardware decommissioning, the termination of remaining VMware support contracts (carefully aligned with subscription end dates to avoid early-termination penalties), the rebalancing of the operations team to the steady-state Nutanix footprint, and the final documentation of the new operational model.
Decommissioning typically runs longer than customers initially plan for. Hardware lease terminations, contractual end-dates, residual production workloads, and the political reluctance to fully retire familiar infrastructure all combine to extend the phase. Realistic decommissioning plans build in three to six months even for migrations that look "done" much earlier.
Workload classification: the foundation
The single most important analytical work in a VMware-to-Nutanix migration is workload classification. The classification determines which workloads migrate when, which workloads need bespoke planning, and which workloads may not migrate at all.
Classification dimensions
A practical classification scheme uses four dimensions. Technical complexity — does the workload use standard VMs, vSphere features, vSAN, NSX, or specialised configurations (PCI passthrough, GPU acceleration, custom networking)? Business criticality — what is the downtime tolerance, the change-management overhead, the political profile? Application stack — what applications run on the workload, what are their support requirements, what licensing implications does the migration trigger? Ecosystem integration — what backup, monitoring, security, and orchestration tools touch the workload?
The classification produces a workload portfolio with each VM tagged across the four dimensions. The portfolio then drives wave planning, complexity-handling, and exclusions from migration.
Common classification outcomes
Across enterprise engagements, the typical classification outcome shows 70-85% of workloads as "standard" — straightforward VMs that migrate cleanly with Nutanix Move and minimal application revalidation. A further 10-20% are "complex" — requiring bespoke migration planning but ultimately migratable. A small percentage (typically under 5%) are "exclusions" — workloads that should remain on VMware, retire entirely, or rehome to public cloud rather than migrating to Nutanix.
The exclusion category is worth attention. Customers who try to migrate every workload typically encounter the workloads with the highest cost-per-migrated-VM late in the project, when timeline pressure forces poor decisions. Identifying exclusions early — and planning their alternative dispositions — is more efficient than discovering them mid-migration.
Customers who complete classification before approaching their VMware renewal consistently land better terms. Knowing exactly which workloads can move (and which cannot) makes the renewal negotiation concrete, which Broadcom's commercial team respects.
Nutanix Move: the migration tooling
Nutanix Move is the primary migration tool from VMware to AHV. The current generation of Move (post-2024) handles workload conversion, network and disk reconfiguration, IP-address management, and cutover with minimal application downtime for standard workloads.
How Move works in practice
Move runs as a virtual appliance with connectivity to both the source VMware environment and the target Nutanix cluster. The migration is initiated for one or more VMs; Move performs the disk conversion (VMDK to AHV-compatible format), preserves the network configuration with appropriate translation, and orchestrates the cutover. The total cutover downtime for a typical VM is in the minutes range rather than hours, with the bulk of the migration work happening online before cutover.
Move handles batching, scheduling, and monitoring of migrations at scale. A well-configured Move appliance can migrate dozens of workloads in parallel, with the total throughput typically limited by network bandwidth between the VMware source and the Nutanix target rather than by the Move appliance itself.
Where Move requires assistance
Some workloads require manual preparation before Move can handle them cleanly. Workloads with PCI passthrough or GPU acceleration require post-migration reconfiguration. Workloads with non-standard network configurations may need network-pre-staging on the Nutanix target. Workloads with specific cluster-level dependencies (Windows clustering, Oracle RAC) require coordinated migration of all cluster members.
The Move documentation and Nutanix's professional-services capability cover most of these cases well; the project plan should explicitly allocate time for the workloads that fall outside the standardised migration path.
Ecosystem migration
The hypervisor migration is one piece. The full migration also covers a substantial set of ecosystem tools that integrate with the virtualisation layer.
Backup and recovery
The major backup vendors — Veeam, Commvault, Cohesity, Rubrik, HYCU — all support Nutanix AHV at production-grade maturity. Migration typically involves either (a) adding Nutanix support to the existing backup deployment and migrating backup policies workload-by-workload, or (b) deploying a parallel Nutanix-targeted backup infrastructure during the migration and retiring the VMware-targeted backup at the end. The choice depends on the existing backup vendor's licensing model and the customer's preference for parallel vs in-place migration.
Monitoring and observability
Most monitoring tools (Datadog, Dynatrace, Splunk, the major SIEM products, and the open-source ecosystem around Prometheus and Grafana) support Nutanix natively or through standard agents. The migration involves reconfiguring data sources, updating dashboards, and revalidating alert thresholds against the new platform's baseline metrics.
Security and compliance tooling
Endpoint security agents typically work without modification — they are guest-OS components rather than hypervisor-level components. Hypervisor-level security tools (NSX micro-segmentation, vRealize Log Insight) require replacement with Nutanix-platform equivalents (Flow for micro-segmentation, the standard logging integrations for log management). Customers using deep VMware-specific security capabilities should plan replacement carefully.
Automation and orchestration
vRealize Automation, Ansible-with-vSphere-modules, Terraform-with-vSphere-provider, and similar tools all have AHV/Prism Central equivalents. The migration involves rewriting or reconfiguring automation against the new platform's APIs. The work is typically substantial for customers with mature automation; planning the automation migration as a separate workstream from the workload migration is usually appropriate.
Cost and timeline ranges
Realistic enterprise migrations land in defined ranges across the engagement data.
Cost ranges
Technical migration cost (Nutanix Move execution, ecosystem revalidation, application testing) typically runs $400-$1,500 per virtual machine. Ecosystem migration cost (backup, monitoring, security, automation) adds 30-50% to the technical migration cost. Skills development and operational readiness add a further 10-20%. Hardware refresh — often coordinated with the migration to capture the platform-refresh investment — varies independently.
For a customer running two thousand VMs, total project cost typically lands $1.5-$4 million, plus hardware investment. The cost is one-time; the run-rate cost differential against continued VMware operation is recurring and typically substantial.
Timeline ranges
End-to-end timelines typically run twelve to twenty-four months for environments of one thousand to five thousand virtual machines, eighteen to thirty-six months for larger environments, and nine to fifteen months for smaller environments. The variability primarily reflects environment complexity and the parallelism the customer is willing to fund.
Common pitfalls
Several patterns produce failed or unsatisfactory migrations across the engagement data.
Underestimating the ecosystem. Treating the migration as a hypervisor exercise rather than an ecosystem exercise. Customers who plan only the workload migration without planning the corresponding backup, monitoring, security, and automation migrations typically discover the missing work mid-project and run out of budget.
Compressing the timeline for VMware renewal alignment. Attempting to complete a full migration before a VMware renewal expires typically produces poor decisions late in the project. The right answer is usually to plan the migration on the timeline the migration requires and to negotiate the VMware renewal accordingly — including a bridging renewal at meaningful pricing rather than a forced fast migration.
Insufficient operational readiness. Migrating workloads onto a platform the operations team cannot yet operate at steady state produces post-migration fragility. Skills development should run in parallel with the migration, not after, and the operational handover should be deliberate.
Skipping the pilot phase. Customers who try to move directly from evaluation to scaled migration consistently discover problems in early waves that the pilot would have caught. The pilot is the cheapest way to refine the runbook; skipping it makes the scaled phase more expensive than necessary.
Inadequate stakeholder management. Migrations are visible. Application owners, business stakeholders, and operational teams all have legitimate concerns that need to be managed. Migrations run as pure technical projects without proportional stakeholder engagement typically face political resistance that derails the schedule.
Renewal-timing considerations
The interaction between the migration project and the VMware renewal cycle is delicate. Three patterns work well.
The bridging renewal. Negotiate a one-or-two-year VMware renewal at acceptable pricing specifically to bridge the migration timeline. The renewal terms should be structured to allow ramp-down — typically a co-termed reduction in committed core counts as workloads migrate — rather than a flat commitment for the full term.
The parallel-investment renewal. For larger customers with strategic Broadcom relationships, the renewal can be structured as a parallel investment — Broadcom continues to receive subscription revenue during the migration, but at meaningfully reduced commitment and with explicit provisions reflecting the migration trajectory.
The cliff renewal. For customers with very short migration timelines, the cliff approach simply runs the existing entitlement to expiry and absorbs whatever short-term cost emerges for residual workloads. The approach works only for migrations that can credibly complete on the cliff date.
Related reading
For the underlying comparison, see Nutanix versus VMware after Broadcom. For broader alternative options, see VMware alternatives 2026. For VMware-side renewal planning, see VMware licensing after Broadcom, negotiating Broadcom VMware pricing, and migration risk assessment.