Nutanix Move VM Migration Playbook: From VMware ESXi to AHV in Production

Nutanix Move is a free migration tool from Nutanix that replicates virtual machines from one hypervisor or cloud platform to another with minimal downtime. The most common use case in 2024 is migration of VMware ESXi VMs to Nutanix AHV as part of a VMware exit, but Move also supports Hyper-V to AHV, AWS EC2 to AHV, Azure VMs to AHV, and several variations including Azure VMware Solution to NC2 on Azure.

Move is a virtual appliance. It deploys as a Linux-based VM on the target Nutanix cluster (or on the source environment depending on configuration) and uses agent-based or agentless approaches to read source VM disks, replicate the data to the target storage, prepare the guest operating system for the new hypervisor, and orchestrate cutover. From the operator's perspective, Move is a web UI on the appliance plus a REST API for automation.

The core operational characteristic of Move is that source VMs continue running during replication. Move performs initial seeding of the VM's disks to the target, then runs incremental replication of changed blocks. When the operator initiates cutover, Move pauses the source VM briefly, performs a final delta sync, brings the VM up on the target, and validates that the new VM has booted successfully. The downtime per VM is typically minutes rather than hours.

Move 5.x as of 2024 supports the following source-target combinations.

Source: VMware ESXi 6.0 through 8.0. Specific ESXi version support varies by Move release. ESXi 6.0 and 6.5 are supported but no longer receive VMware feature updates and may require specific Move configuration. ESXi 7.0 and 8.0 are the most common production sources and have the most thoroughly tested Move workflows. Source ESXi requires a vCenter Server for Move to enumerate inventory and orchestrate replication.

Source: Microsoft Hyper-V on Windows Server 2012 through Windows Server 2022. Hyper-V migration requires the Hyper-V host to be reachable from the Move appliance and requires specific Windows credentials for Move to enumerate VMs.

Source: AWS EC2. Move supports replication of EC2 instances to AHV on-premises. The common use case is repatriation from AWS to on-premises Nutanix. Network connectivity between AWS and the Nutanix cluster must be in place.

Target: AOS 6.5 through current. As of 2024, current AOS is 6.8.x with active maintenance. AOS 6.5 is also supported with active maintenance. The Move release notes specify the supported AOS target range for each Move version.

Understanding how Move works internally clarifies why specific migration steps exist and what failure modes mean.

The Move appliance is a Linux-based VM that runs on the target Nutanix cluster. It deploys from an OVA file and configures through a web UI on first boot. The appliance has a small footprint, typically 4 vCPU and 8 GB of memory, but the resource requirements scale based on the number of concurrent migrations.

The Move appliance establishes connections to two endpoints: the source environment (vCenter Server for ESXi, Hyper-V host for Hyper-V, etc.) and the target Nutanix cluster. The source connection allows Move to enumerate VMs, read VM configuration, and read VM disk content. The target connection allows Move to create destination VMs, write replicated disk content, and orchestrate cutover.

For ESXi source migrations, Move uses the VMware Virtual Disk Development Kit (VDDK) to read VM disks. VDDK is VMware's library for programmatic disk access. Move uploads the VDDK files during initial configuration. Move uses VDDK to perform Change Block Tracking (CBT) reads, which means it can read only the blocks that have changed since the last replication pass rather than the entire disk.

Migration plans are the unit of organization in Move. A plan defines the source environment, the target cluster, the set of VMs to migrate, the target network mappings, the schedule and preparation mode, and the cutover behavior. The migration plan lifecycle has distinct phases: Preparation phase (Move analyzes VMs and validates compatibility), Seeding phase (Move replicates full disk content), Incremental phase (Move continuously syncs changed blocks), Cutover phase (Move pauses source VM, performs final sync, brings VM up on target), and Validation phase (Move confirms the migrated VM is operational).

Before Move can begin migrating VMs, the source and target environments must be in a specific state. This section is the readiness checklist.

Target Nutanix cluster readiness. The target AOS version must be in the supported range for the Move version being used. AHV must be running and healthy. Storage containers must be created for the migrated VMs. Network configurations must be in place, including virtual networks (VLANs) that map to the source network configurations. The target cluster must have sufficient capacity for the migrated workload, including headroom for the migration process itself.

Source vCenter readiness for ESXi migrations. vCenter Server must be reachable from the Move appliance. A service account with adequate privileges must be created. Move requires permissions including Datastore Browse, Virtual Machine power management, VM snapshot management, and the Cryptographic Operations Direct Access permission for newer ESXi versions.

Source VM readiness. VMs must be in a Move-compatible state. This includes recent VMware Tools installation (to allow proper shutdown coordination), guest OS in a supported version, no active snapshots (existing snapshots should be consolidated before migration), and no dependencies on physical-only resources like pass-through devices that the target cannot provide.

Every production migration project should begin with a pilot phase. The pilot validates the migration tooling, the target environment, the operational procedures, and the application behavior post-migration before any business-critical workload is exposed to the migration.

Pilot scope. Five to ten VMs is the typical pilot size. The VMs should be representative of the broader environment, covering different operating systems (Windows Server, Linux distributions), different VM sizes (small to large), different network configurations (different VLANs, different security zones), and different application types (general-purpose, database, application server).

VM selection criteria. Pilot VMs should be lower-risk workloads that are still production. Development and test VMs are sometimes used for pilot but tell less than production VMs because development environments often have different load profiles, different backup configurations, and different operational scrutiny than production.

Pilot migration execution. The pilot migration follows the same process that production migrations will follow. Set up the migration plan in Move, validate the plan against the readiness checklist, execute the seeding phase, allow incremental replication to stabilize, schedule the cutover during a planned window, perform the cutover, and validate the migrated VMs operationally.

Production migration after the pilot follows a wave-based pattern. Waves are groups of VMs that migrate together as a coordinated batch.

Wave composition. Each wave typically includes 20 to 100 VMs, scoped by application grouping, by business unit, by criticality, or by maintenance window availability. The waves are designed so that the VMs within a wave can be migrated and validated together, and so that the business impact of a wave's migration is bounded.

Wave sequencing. Waves are sequenced from lower-risk and lower-dependency to higher-risk and higher-dependency. Early waves are typically infrastructure VMs and general-purpose application VMs that have minimal external dependencies. Middle waves are business applications that have known dependencies and validated migration procedures. Late waves are the most business-critical workloads, the database tier, and any VMs with specific compliance or audit requirements that need extra care.

Wave timing. The interval between waves depends on the validation discipline. A typical cadence is one wave per week or one wave per two weeks. The interval allows each wave to be validated through normal business cycles before the next wave starts.

Cutover happens during a planned maintenance window. The window is sized for the wave count and the expected cutover time per VM. A wave of 50 VMs at 10 minutes per VM in parallel groups of 5 takes roughly 100 minutes of cutover time. The maintenance window is typically scheduled at low-business-activity times.

The cutover window is the brief downtime during which each VM transitions from running on the source to running on the target. The operational discipline during cutover determines whether the migration succeeds cleanly or requires emergency intervention.

Cutover preparation. Before cutover begins, confirm that incremental replication is current (the delta queue should be small), confirm the target cluster is in a healthy state, confirm the network configuration on the target supports the VMs being migrated, and confirm the rollback path is in place.

Cutover initiation. Move initiates cutover for the VMs in the migration plan. The source VMs are paused (cleanly shut down or suspended depending on configuration). The final delta sync runs to capture any pending changes. The target VMs are created with the replicated disks attached. Network configurations are applied to the target VMs.

Cutover validation per VM. Immediately after cutover, validate each VM. Confirm boot completed successfully. Confirm network connectivity from the VM to its expected destinations. Confirm Nutanix Guest Tools is running. Confirm the application has started and is responding.

NSX-T is the single most common dependency that complicates VMware to AHV migrations. The handling of NSX-T determines the migration timeline and the architectural sequencing for a significant fraction of environments.

NSX-T provides network virtualization on top of vSphere. Overlay networks (Geneve encapsulation), distributed firewall rules, microsegmentation policies, and load balancing are common NSX-T capabilities. NSX-T is tightly integrated with ESXi and does not run on AHV. There is no direct migration of NSX-T configurations to AHV.

The analogous capability on AHV is Nutanix Flow Networking. Flow Networking provides microsegmentation and VPC-style network virtualization with a different policy model and a different management surface. Migration of NSX-T configurations to Flow Networking is feasible but is non-trivial work.

For most organizations, the practical approach is to handle NSX-T migration as a separate workstream from the hypervisor migration. The hypervisor migration moves VMs from ESXi to AHV. The network migration moves NSX-T policies to Flow Networking or to other network virtualization approaches. These workstreams can run in parallel if the team has capacity, or sequentially if the team is constrained.

Site Recovery Manager configurations need explicit handling during a VMware to AHV migration.

SRM provides orchestrated DR for vSphere environments. Runbooks define the failover procedure for groups of VMs. SRM coordinates with vSphere Replication or array-based replication to maintain DR copies. The SRM runbooks include network reconfiguration during failover, dependency-aware boot sequencing, and validation steps.

AHV environments use Nutanix Protection Domains for replication and Nutanix Disaster Recovery (formerly Leap) for orchestrated DR. The capability is functionally analogous to SRM but the configuration model differs.

Migration of SRM configurations to Nutanix Disaster Recovery is not automatic. The DR configuration needs to be rebuilt in Nutanix Disaster Recovery using the same architectural intent. RPO and RTO targets, replication topology, network mappings during failover, and recovery validation procedures all need to be re-implemented.

Recent Move releases added specific support for migrating NSX security policies as part of VM migration. This capability is useful for environments with NSX-T deployed primarily for security policy enforcement rather than overlay networking.

Move 5.x supports security policy migration for NSX versions 3.2.x and 4.0.x. The capability reads the security policies applied to source VMs in NSX-T and migrates the policy metadata to Nutanix Flow Networking on the target. The destination policies match the source policies in intent, allowing the security posture to be preserved across migration.

The migration is not perfect. Some NSX-T policy constructs do not have direct equivalents in Flow Networking. The migrated policies should be reviewed for completeness rather than assumed to be exact. The Move user guide documents the specific NSX policy elements that migrate cleanly and the elements that require manual review.

A relatively recent Move capability is In-Place Cluster Conversion. This converts a Nutanix cluster running ESXi as the hypervisor directly to AHV without requiring a separate target cluster.

The architectural pattern that this addresses is the Nutanix-on-ESXi customer. Some organizations purchased Nutanix infrastructure but ran VMware ESXi as the hypervisor on Nutanix hardware. The Nutanix software stack provided the distributed storage, but the hypervisor was VMware.

Historically, this conversion required a swing-kit approach. A separate cluster running AHV would be temporarily deployed. VMs would be migrated from the ESXi-on-Nutanix cluster to the AHV swing cluster. The original cluster would be converted to AHV. VMs would be migrated back. The swing kit was operationally complex and required additional hardware availability.

Move In-Place Cluster Conversion eliminates the swing kit. The conversion runs on the cluster itself, converting the hypervisor on each node one at a time. VMs are paused, migrated to other nodes, the source node is converted from ESXi to AHV, and VMs are returned to the converted node.

Another recent Move capability is migration from VMware ESXi to Nutanix AHV with external Pure Storage as the storage tier. This capability was introduced with AOS 6.5 and enables the disaggregated AHV with external Pure Storage architecture during migration.

The architectural pattern is the FlashStack with Nutanix design. Cisco UCS compute nodes run Nutanix AHV in compute-only configuration. Pure FlashArray provides the storage tier via NVMe over TCP. The VMs run on AHV but their disk content lives on Pure rather than on Nutanix distributed storage.

Migrating to this architecture has specific requirements that Move handles. The migration plan needs to specify Pure storage as the target storage rather than a Nutanix storage container. Move replicates the VM disk content to Pure rather than to Nutanix DSF. The migrated VMs run on AHV with their virtual disks served from Pure.

Move 5.x supports several cross-cloud migration paths that are particularly relevant for organizations rationalizing their cloud-based VMware footprint.

Azure VMware Solution (AVS) to NC2 on Azure. Organizations running VMware in AVS can migrate workloads to Nutanix Cloud Clusters on Azure. The migration is Move-based replication between the AVS environment and the NC2 environment within Azure. The benefit is that the workloads stay in Azure (preserving cloud platform investment, network configurations, and data gravity) while exiting VMware licensing.

Azure VMware Solution to AHV on-premises. Workloads in AVS can also be migrated back to on-premises AHV environments. The use case is repatriation from AVS to on-premises Nutanix.

VMware ESXi and AHV on-premises to NC2 on GCP. Organizations exploring multi-cloud strategy or considering GCP can migrate workloads from on-premises to NC2 on GCP.

Move migrations succeed in the substantial majority of cases. When they do not succeed, the failures fall into predictable categories.

Source VM preparation failures. The most common pre-migration failure is a source VM that is not in a Move-compatible state. Recent VMware Tools not installed, active snapshots not consolidated, guest OS not in a supported version, pass-through device dependencies. These failures appear during the readiness check phase and prevent the VM from progressing to seeding.

VDDK upload failures. Move requires VDDK files for ESXi source disk access. VDDK upload failures (corrupted upload, wrong version, missing entitlement) prevent any ESXi migration from progressing. Resolution is to validate the VDDK files and re-upload through the Move appliance.

vCenter permission failures. Move's service account on vCenter requires specific permissions. Permission failures appear as inability to enumerate VMs, inability to read VM disks, or inability to power-cycle VMs at cutover.

Network bandwidth saturation. If the migration is being throttled by network bandwidth, replication is slow and incremental sync may fall behind source changes. Resolution is either to add bandwidth, to reduce concurrent migration count, or to schedule migration during low source-activity periods.

Rollback planning is part of every migration project. The fact that rollback is rarely needed does not change the requirement that the path exists.

Source VM retention policy. After cutover, the source VMs should be retained for a defined period before decommissioning. A typical retention period is two to four weeks. The retention period gives the operations team time to identify and respond to any post-migration issues that may surface gradually rather than immediately.

Source VM state during retention. The source VMs should be in a state that supports rollback if needed. Typically this means the source VMs are powered off but their disks are preserved. Some organizations preserve a snapshot of the source VM in addition to the powered-off state to capture a specific point-in-time pre-migration state.

Rollback procedure. If rollback is required, the operational steps include powering off the migrated VM on AHV, powering on the source VM on ESXi, validating the source VM has come back cleanly, redirecting application traffic to the source VM (typically through DNS or network configuration changes), and notifying stakeholders that the rollback has occurred.

Validation does not end at cutover. The post-cutover validation period is when the migration is actually confirmed successful.

Day-of validation. Immediately after cutover, the operational team validates that each migrated VM has booted cleanly, that the network is functional, that the application is responding, and that monitoring is capturing the VM correctly. This is the immediate validation that the cutover succeeded technically.

Day-one validation. Within 24 hours of cutover, the application owners validate their applications under normal business load. Patterns that may not have surfaced during the cutover window often surface during the first business day of operation. Performance under load, integration with external systems, batch jobs that run on a daily schedule, monitoring alerts that fire on day-one cycles.

First-week validation. The first week of operation on AHV exposes the workload to the full operational cycle of the environment. Backup jobs run and complete. Monitoring captures a full week of baseline metrics. Patch cycles execute. The migration is confirmed against a full week of normal operation.

First-month validation. The first month of operation on AHV exposes the workload to the broader operational rhythm including any monthly batch operations, longer-duration patterns, and operational events that did not happen in the first week. By the first month, the migration is considered fully validated and the workload is in steady-state operation.