Migrate Off VMware Without Stopping Production 

VMware to Nutanix: A Migration Runbook That Never Touches Your Running Workloads 

The fear is always the same: that somewhere in the migration, production stops. It is the single reason VMware estates sit on renewals their owners would rather leave. Yet the outages in migration war stories seldom come from the migration itself. They come from skipping the runbook, trying to move everything in one window to hit a date. Done properly, a VMware-to-Nutanix migration copies your workloads while they keep running and cuts over in minutes, one controlled wave at a time, with a way back at every step. This is that runbook. 

Why Migrate From VMware to Nutanix? 

Because the economics changed and the timeline is fixed. Since Broadcom moved VMware to subscription-only bundles, many renewals have risen sharply, and VMware vSphere 8 reaches the end of general support on 11 October 2027, after which the only supported path is the subscription-based vSphere 9. Nutanix is widely regarded as the closest like-for-like replacement for large vSphere estates, with mature migration tooling and a hyperconverged platform that folds compute, storage and virtualisation into one stack. This guide assumes you have made that decision and need to execute it safely. 

The Principle: No Big-Bang Cutover 

Everything in this runbook follows one rule: production keeps running until the moment you choose to cut over, and you can reverse that choice. Migration tooling replicates each virtual machine to the Nutanix cluster while the original keeps serving users, syncing changes continuously. Only the final cutover, a brief switch from the old VM to the new one, needs a short window, measured in minutes per workload, not hours of estate-wide downtime. You migrate in dependency-ordered waves, validate each before the next, and hold a rollback option at every gate. Risk is contained to one small wave at a time. 

The Migration at a Glance

Phase 1: Assess and Discover 

You cannot migrate safely what you do not understand. Inventory every virtual machine, its resources, operating system and role, then map the dependencies between them, which applications talk to which, what relies on shared storage, and where third-party tools are integrated with vSphere. This is where you find the things that bite later: an application with a hard dependency on a specific vSphere feature, a backup integration that needs reconfiguring, a licence tied to a host identifier. Capturing these now turns surprises into planned tasks. The output is a complete map and a list of any workloads that need special handling. 

Phase 2: Design the Target 

With the estate understood, you design the Nutanix environment to receive it. Size the cluster to the workloads, with headroom for the migration itself and for growth, and design the AHV hypervisor, AOS storage and networking to match or improve on what the workloads have today. Map each source VM to its target placement, and plan how networking and storage will translate, IP addressing, VLANs, and datastores becoming Nutanix storage containers. Crucially, the target is stood up and validated before a single production workload moves, so the destination is never in doubt during a migration. 

Phase 3: Pilot 

You prove the runbook on a small, representative slice before trusting it with anything critical. Choose a handful of low-risk workloads that still exercise the real patterns, a mix of operating systems, an application with a dependency or two, and migrate them with the migration tool. Validate everything: performance, connectivity, application behaviour, backups, monitoring. The pilot is where you refine timings, confirm the cutover steps, and surface anything the assessment missed. If the pilot does not meet its success criteria, you stop, fix the cause, and retry. Nothing further proceeds until the pilot is clean. 

Phase 4: Plan the Waves 

You group the estate into migration waves, sequenced by dependency and risk. Tightly coupled workloads move together, so an application and its database are never split across platforms mid-cutover. Lower-risk waves go first to build confidence; the most critical systems go later, once the process is proven on your own estate. Each wave gets explicit success criteria, a maintenance window for its brief cutover, a communication plan, and a defined rollback trigger. A wave plan that names the go and no-go conditions in advance is what keeps the migration calm under pressure. 

Phase 5: Migrate in Waves 

Now you execute, one wave at a time. For each workload, the tool performs an initial replication to the Nutanix cluster while the source keeps running, then syncs changes continuously so the copy stays current. Users are unaffected throughout this stage. When the wave's window arrives, you perform a final delta sync, power down the source VM, power up the migrated VM on Nutanix, and validate. If validation passes, the wave is done. If a workload fails its checks, you revert to the still-intact source VM, which has not been deleted, and the business continues on VMware while you investigate. Risk never extends beyond the wave in front of you. 

Phase 6: Cutover and Validate 

Cutover is deliberately undramatic because the replication did the heavy lifting in advance. The final sync moves only the recent changes, the workload starts on Nutanix, and networking, DNS and any integrations are confirmed. You run the agreed acceptance tests, performance, application function, backups, monitoring, and obtain sign-off. Because the source VM is retained until acceptance, a serious problem at this stage means failing back to VMware, not a crisis. Only once a workload is accepted on Nutanix does its old VM become a candidate for retirement. 

Phase 7: Optimise and Decommission 

After the workloads are running on Nutanix, you tune and tidy. Right-size any VMs that were over-provisioned on the old platform, confirm that backups, disaster recovery and monitoring are fully cut over, and validate that the new environment is performing as designed. Then you decommission the VMware estate in a controlled way, reclaiming licences and freeing the hardware, and capture the savings and simplifications the move was meant to deliver. The migration is not finished when workloads run on Nutanix; it is finished when the old estate is cleanly retired and the new one is optimised. 

The Rollback Gates That Make It Safe 

The reason this runbook can promise that production keeps running is the rollback gate at every stage. The target is validated before any move. The pilot must pass before waves begin. Each wave has named success criteria, and a failure reverts to the untouched source VM rather than pressing on. Source workloads are retained until formal acceptance, so even a late cutover problem means a fail-back, not an outage. Migrations go wrong when there is no defined way back; this one is built around having one at every step. 

Running the Runbook With a Partner 

The runbook is the easy part to read and the hard part to execute across a real estate of hundreds or thousands of workloads, each with its own dependencies and risk. The value of an experienced partner is the assessment that finds the landmines, the wave planning that sequences them safely, and the steady hands on the cutovers. 

Proactive Data Systems plans and runs VMware-to-Nutanix migrations for Indian enterprises, end to end. We are a Cisco Preferred Cloud and AI Partner, Dell Platinum Partner and NetApp Preferred Partner, with 35 years in enterprise IT, more than 1,500 organisations served, and a 24/7 service desk in India. We assess the estate, design and build the Nutanix target, pilot, migrate in waves with rollback gates, and optimise the result, so production keeps running throughout. To scope yours, you can ask Proactive for a VMware migration assessment. 

Disclaimer: This runbook is general guidance, not a substitute for a scoped migration plan, and not legal, financial or procurement advice. Tools, licensing and platform details change and vary by environment. Validate the approach against your estate before executing. VMware, Broadcom, Nutanix, ESXi and AHV are trademarks of their respective owners; this is independent guidance, not endorsed by or affiliated with any of them, and should be reviewed by your own technical and legal teams before use.