Leaving Nutanix is a planned project, not an emergency — and done well it produces a virtualization platform you own instead of one you rent under a renewal that keeps climbing. Ænix migrates Nutanix AOS/AHV estates to a Kubernetes-native platform where VMs and containers share one cluster, storage is replicated with LINSTOR, and there is no per-node hypervisor license. The destination is Cozystack, built and operated by the same engineers who run your migration.
Pairs with: the Ænix platform that matches your estate — Private Cloud Platform for regulated organisations running cloud for themselves, Public Cloud Platform if you sell cloud to customers. Decide the destination on the Nutanix alternative comparison, then model the numbers with the ROI & TCO calculator.
Why are organizations leaving Nutanix?
The triggers cluster into three, and they compound.
- Renewal and licensing pressure. Portfolio consolidation and subscription repricing have pushed a lot of Nutanix customers to re-examine the total cost of staying, particularly where per-node licensing scales with a growing cluster.
- Hyperconverged lock-in. HCI ties the storage fabric, the hypervisor, and the management plane to one vendor’s stack. That is convenient until you want to change one layer, add a workload type the platform does not favour, or run on hardware the vendor does not bless.
- One platform for VMs and containers. Many teams already run Kubernetes next to their Nutanix VMs. Consolidating both onto a single Kubernetes-native platform removes a parallel stack, a parallel operations model, and a parallel bill.
If two or more of these apply, a structured migration usually compounds in your favour. If your renewal is comfortable and nothing else pushes, “stay and tune” is the honest recommendation — we will tell you so, and it is the recommendation more often here than on the VMware side. Nutanix has the best day-2 operational experience of any platform we migrate away from: one-click LCM upgrades, storage efficiency you never tune, one vendor accountable for the whole stack. You give that up. The Nutanix alternative page sets out both sides before you commit.
What you migrate to
The destination is a single Kubernetes-native platform assembled from open, CNCF-aligned components rather than a second proprietary HCI stack.
- VMs on KubeVirt. KubeVirt runs full virtual machines on Kubernetes using the same KVM technology underneath AHV, so guest operating systems, including Windows, carry over. VMs and containers schedule on the same cluster.
- LINSTOR replicated storage. LINSTOR/DRBD provides replicated block storage in place of the AOS distributed storage fabric, with encrypted, replicated volumes across nodes and — where the topology calls for it — across data centres.
- Cilium networking. An eBPF-based CNI replaces the HCI network plane, with network policy, load balancing, and multi-tenant isolation as first-class Kubernetes primitives.
- No per-node hypervisor tax. Cozystack is Apache 2.0 open source; the platform you migrate to has no per-node hypervisor license, so cluster growth does not compound a licensing bill.
For the platform-level comparison — feature by feature, Cozystack versus Nutanix HCI — read the Nutanix alternative page. This hub assumes you have chosen the destination and focuses on the move.
How an AHV migration actually runs
Migration is cohort-based, not big-bang. A single-weekend “move it all” rarely survives contact with an enterprise estate.
- Inventory and classification. Full AOS/AHV inventory — VM count, OS mix, storage dependencies, network integrations, multi-site topology — then classify each workload as migrate-now, migrate-later, stay, or re-platform to containers.
- Destination architecture. Size and design the Cozystack target on your hardware: capacity model, storage classes, networking, tenancy, and operations design.
- Cohort cutover. AHV VMs are exported and converted with the KubeVirt Containerized Data Importer (CDI); each cohort runs in parallel with Nutanix until validated, and cutover sequencing is aligned to your renewal expirations so you never pay twice for capacity you have already moved.
- Decommission. Nutanix nodes are retired as cohorts complete and hardware is repurposed where it fits, so the final renewal is simply avoided.
This is the same disciplined sequencing we use for VMware migration — the mechanics differ, but the cohort-and-parallel-run pattern is what keeps a migration from becoming next year’s emergency.
What carries over, and what genuinely changes
Being honest about the delta is what keeps a migration on schedule. Some things port with little friction; others are a deliberate redesign, and pretending otherwise is how projects stall.
- Carries over. Guest operating systems and their disks (KubeVirt runs the same KVM technology as AHV), VM-centric operating habits, and most application architectures — a VM that ran on Nutanix runs as a VM on KubeVirt.
- Redesigned on purpose. Storage moves from the AOS fabric to LINSTOR storage classes; networking moves from the HCI plane to Cilium policy; and tenancy, quotas, and self-service are modelled as Kubernetes-native constructs rather than Prism categories. Skipping this redesign is the single most common cause of post-migration fragility.
- A new capability, not just a swap. Because containers are first-class on the same cluster, the migration is also the moment teams can start consolidating a separate Kubernetes estate — turning a like-for-like VM move into a platform consolidation.
The assessment names each of these explicitly for your estate, so the plan reflects real effort rather than an optimistic like-for-like assumption.
Model the cost before you commit
Migration economics look attractive in theory and turn on the details in practice: hardware refresh, platform-team capacity, and the operational learning curve all belong in the model. Before committing to hardware or a timeline, run your estate size and current Nutanix renewal through the ROI & TCO calculator to see the annual delta, the multi-year net after migration, and the payback period. An honest TCO up front is what separates a migration that pays back from one that stalls.
How Ænix engages on Nutanix migration
The engagement mirrors our Platform Readiness Assessment with Nutanix emphasis: AOS/AHV inventory, destination architecture, workload classification, cutover sequencing against renewal dates, and a Phase 2 roadmap — delivered in 14-28 days. Phase 2 is implementation, with Ænix engineers integrated into your team for the migration cohorts and knowledge transfer throughout; an optional Phase 3 covers managed Cozystack operations after the estate has moved. Because we build the destination platform, the effort estimates are calibrated against work we have shipped, not guessed.
Ænix is the team behind Cozystack — a CNCF project (Sandbox today; Incubating expected late summer 2026), Apache 2.0. Ænix commercializes it as Ænix Platform, as three platforms on one engine — Public Cloud, Private Cloud and AI — that combine rather than exclude each other. We run Nutanix and VMware migrations for enterprises, hosting providers, and public-sector operators across the EU and DACH.