Nutanix

Broadcom’s licensing changes have put a lot of VxRail owners in an uncomfortable position. Renewal quotes have climbed, subscription terms have tightened, and platforms that were budgeted as a predictable line item now require a real financial conversation every cycle. Nutanix has become the most common alternative on the evaluation list, largely because AHV is included rather than licensed separately.

Moving from VxRail to Nutanix is achievable, and the tooling is mature. It is not, however, a simple swap. VxRail is a jointly engineered Dell and VMware appliance, which means this migration involves new hardware, a parallel running period, and a rebuild of everything in your environment that assumes vSphere underneath it.

For defense contractors and other regulated organizations, it also touches your documented security boundary. That deserves planning attention well before the first VM moves.

Here is how to approach it.

Start With the Hardware Reality

The most common misconception is that Nutanix can be installed onto existing VxRail nodes. It cannot, at least not in any supported fashion. VxRail is a closed appliance with its own lifecycle manager, and Nutanix does not qualify VxRail hardware as a supported platform. Attempts to rebrand nodes back to standard PowerEdge and run Foundation against them tend to fail during CVM installation, and even where they succeed, you have built an unsupported production platform.

Plan for net-new nodes. Nutanix runs on its own NX appliances, on Dell XC Core, and on qualified hardware from several other vendors. If you want to stay with Dell, XC Core on PowerEdge is the closest analog to what you already own.

This has practical consequences for the project:

• You need rack space, power, cooling, and switch ports for both clusters at the same time.
• You will pay for both platforms during the overlap. Time your cutover against your VMware renewal date rather than discovering the overlap after the fact.
• Your old nodes become a disposal question, which for CUI environments means a documented sanitization process, not a pallet in the hallway.

Phase 1: Assessment and Dependency Mapping

Inventory is the easy half. Every migration plan lists VMs, vCPU, memory, and storage. The half that derails projects is dependency mapping.

Before you scope anything, document:

• Application communication paths. Which systems talk to which, on what ports. If you are also planning microsegmentation on the new platform, this work does double duty.
• Guest operating systems and versions. Verify each against the Nutanix compatibility matrix. Older or unusual guests are where surprises live.
• Workloads Nutanix Move cannot handle cleanly. Raw device mappings, shared VMDKs, and clustered applications such as SQL Server failover cluster instances or Oracle RAC generally need a manual approach, typically application-level migration rather than VM-level replication.
• Virtual appliances tied to VMware. Anything delivered as an ESXi-specific OVA may need a vendor-supplied AHV image instead of a migration.
• Your backup and DR stack. This is the most frequently missed item. Confirm your backup vendor supports AHV at the feature level you currently rely on, and confirm your replication and DR runbooks still work. Changing hypervisors often means rebuilding backup jobs from scratch.
• Monitoring and endpoint agents. Agents that hook into VMware Tools or vSphere APIs will need replacements or reconfiguration.

For regulated environments, add one more line: identify every system in your CUI boundary and note where it sits today. You will need that mapping again when you update your documentation.

Phase 2: Build and Validate the Target

Rack and cable the Nutanix nodes, then use Foundation to image and configure the cluster. Deploy Prism Central for centralized management.

Before you migrate anything real, get the platform to a defensible baseline:

• Apply your hardening standard to AHV and Prism, not just to the guests.
• Configure authentication against your directory, with role-based access aligned to your existing separation of duties.
• Enable FIPS validated cryptographic modules if your compliance posture requires them. Doing this after workloads land is considerably more painful.
• Stand up logging and forwarding to your SIEM. You want the new platform generating audit evidence from day one, not from the day someone remembers.
• Configure and test backups on the new cluster with a non-production workload.

Phase 3: Deploy Nutanix Move and Plan the Waves

Nutanix Move is the purpose-built migration tool for ESXi to AHV. Deploy the appliance and connect it to both the source vCenter and the target Nutanix cluster.

A few operational details worth knowing before you build plans:

• Move automates guest preparation, including installing the VirtIO drivers that let a VM boot and run on AHV once the hypervisor changes underneath it.
• It pre-seeds data and then performs delta syncs, so the actual cutover window is short relative to the data volume.
• Move supports test migrations that spin up copies on an isolated network, letting you verify that a VM powers on, drivers loaded correctly, and application services start before you commit.
• Nutanix qualifies migration plans of up to 100 VMs for ESXi migrations. Build your waves accordingly rather than pointing Move at the whole environment.
• VMs with multiple network interfaces may not retain all IP addresses, and disconnected NICs on Windows guests will not retain addressing. Plan to assign those manually.
• Linux VMs with disks split across PVSCSI and LSI adapters can come up with different device names. If you have anything mounting by device path rather than UUID, fix that before migration, not after.

Group waves by application, not by convenience. Migrating half of a three-tier application and leaving the rest on VxRail creates traffic patterns and failure modes nobody planned for.

Phase 4: Migrate, Cut Over, and Validate

For each wave, the sequence is consistent:

1. Back up the source VMs and verify the backups are restorable.
2. Run pre-migration validation and resolve every warning rather than acknowledging it.
3. Let Move seed the data while the source VMs stay in production.
4. Run a test migration on the isolated network and confirm the application actually works, not just that the VM boots.
5. Schedule the cutover, shut down the source VMs, allow the final delta sync, and power on in AHV.
6. Validate application functionality, performance, monitoring, and backups before you call the wave complete.

Do not delete the source VMs. Leave them powered off and intact through your rollback window.

The Step Most Plans Omit: Rollback

Every migration plan should answer one question in writing before the first cutover: if this wave fails at 2 a.m., what happens next.

That means defining your rollback trigger, confirming the source VMs remain bootable in place, keeping the necessary VMware licensing active through the rollback window, and deciding who has authority to make the call. A rollback plan you have not tested is a hope, not a plan.

Compliance Steps for Regulated Environments

If you handle CUI, a hypervisor migration changes your documented environment in ways an assessor will notice.

• Update your System Security Plan. Your SSP describes a VMware environment. After migration it describes a Nutanix one, including different management interfaces, different logging sources, and different administrative access paths.
• Redraw your network and data flow diagrams. These are among the first artifacts requested in an assessment.
• Update your asset inventory. New nodes in, old nodes out, with the transition period documented.
• Revalidate your control implementations. Access control, audit and accountability, and system and communications protection all had platform-specific implementation statements. Those statements need to reflect the new platform.
• Document the dual-stack period. Running two platforms in parallel temporarily expands your boundary. Note it, scope it, and close it out when decommissioning completes.
• Sanitize decommissioned media. VxRail drives that held CUI require sanitization to your documented standard, with records retained.
• Verify FIPS validated cryptography on the new platform where your controls require it.

If you have an assessment scheduled, talk to your assessor about timing. Being mid-migration during an assessment window is a solvable problem when it is planned and a painful one when it is discovered.

Final Thoughts

A VxRail to Nutanix migration is a reasonable response to a licensing environment that has become hard to budget around. The tooling works, the cutover mechanics are well trodden, and organizations complete these projects successfully every week.

What separates the smooth projects from the difficult ones is rarely the migration tool. It is the dependency mapping, the backup and DR rebuild, the rollback plan, and for regulated organizations, the documentation work that makes the new environment defensible rather than merely functional.

Planning a Platform Migration? Let’s Talk

Elysian Technology helps defense contractors and regulated organizations across New England plan and execute infrastructure migrations without losing their compliance footing along the way. We can help you assess your current environment, scope the target platform, sequence the migration, and update the documentation your next assessment will depend on.

Start the conversation at elystech.com, email [email protected]