I like AHV. I have put it in front of customers, I have watched it run production for people who were nervous about it, and the hypervisor itself is genuinely boring in the way a hypervisor should be. None of that is the point of this post.
The point is that “we will move to Nutanix” is usually said as if the unit of migration is the virtual machine. It isn’t. The unit of migration is the operating model, and the VM is the easiest thing in it.
What actually moves easily
Compute and memory. Move a Windows or Linux VM from ESXi to AHV and it boots, the tooling handles the disk format, the drivers get swapped, and you spend more time on the change window than on the technology. Move a few hundred and it is a scheduling exercise.
If someone demos this to you and you come away thinking migration is solved, that is a fair reading of the demo and a bad reading of the project.
What does not
Storage that is not theirs. This is the one that catches people with existing arrays. Nutanix is a hyperconverged platform first; its storage story is its own. External arrays are supported in a deliberately narrow way, tied to specific validated combinations and specific software versions. If your plan involves “we keep the array we bought three years ago and just change hypervisor”, check the validated list before you build the business case, not after. That single line has rewritten more designs in front of me than any performance question.
Networking. If you run NSX, you are not migrating a network, you are rebuilding one. Distributed firewall rules, in particular, do not have a tidy equivalent that you can export and import. Someone has to sit down with the rule set and decide what it was supposed to mean. Budget for that person. They will be your most senior network engineer and they will hate it.
Backup. Every backup product supports AHV now. “Supports” covers a wide range of enthusiasm. Check changed-block tracking, check application-aware processing for your specific database, check instant recovery, check whether your existing repositories and retention policies survive. Then check the restore, on a real VM, before you migrate anything that matters.
The management layer nobody mentions. Custom vCenter roles. Alarms wired into the ticketing system. That PowerCLI script from 2018 that somebody’s predecessor wrote which reports on snapshots and quietly prevents a monthly disaster. Orchestration tools calling vCenter APIs. This is where the long tail lives, and it is genuinely long.
The month-four problem
Migrations fail visibly in month one and invisibly in month four. Month one failures are technical and get fixed. Month four is when the team has moved half the estate, is running two platforms in parallel, has two sets of runbooks, two monitoring integrations, two skill requirements, and the project has drifted past the point where going back is cheap but not yet reached the point where the old platform can be switched off.
That is the expensive phase, and its length is determined almost entirely by how honestly you scoped the non-VM work at the start.
How I try to scope it
I ask for four lists, and I ask for them before anyone talks about node counts.
- Every integration that authenticates to vCenter. Read-only counts.
- Every vSphere feature in active use, with the name of the person who would notice if it disappeared.
- Every storage dependency: arrays, protocols, replication relationships, anything with a support matrix.
- Every application whose vendor certifies against a hypervisor. Some still do. Some are the ones you cannot afford to have unsupported.
The lists are boring to build and they are the whole assessment. Node sizing is the easy part; you can redo sizing in an afternoon. You cannot redo the discovery of a dependency you found in production.
So should you move
Sometimes, clearly yes. The economics have changed enough that a platform you would not have considered in 2022 is now the reasonable default for a lot of estates, and AHV is a real product with real customers who are not sorry.
But move for the right reason and with the right scope. The reason is rarely “the hypervisor is better”. It is “our licensing position changed and this platform’s total cost over five years, including the migration work we have honestly estimated, is lower”. If the honest estimate makes the case collapse, that is useful information, not a failure. Better to find it in the spreadsheet than in month four.