VMware to Nutanix Migration Services

Section 01

The "Broadcom Tax" Problem

Broadcom's acquisition of VMware changed the virtualization market. The forced transition from perpetual licenses to bundled subscriptions (VMware Cloud Foundation) has resulted in sharply higher renewal quotes for many enterprises; compare your own quote with your prior terms.

Beyond the price increase, the change is structural: you now pay for a full stack (vSAN, NSX, Aria) even if you only need a hypervisor. For many CIOs, this "Broadcom Tax" has made staying on VMware hard to justify.

Nutanix is one of the main alternatives. It has a mature AHV hypervisor, a comparable enterprise feature set, and migration tools that automate the exit.

---

Section 02

Go / No-Go Assessment

Is migrating to Nutanix right for your organization? Use this scorecard to decide.

---

Section 03

When NOT to Migrate to Nutanix

Nutanix is not always the right answer. Pause or choose a different path in these scenarios:

1. You Just Signed a 3-Year VMware ELA

If you're locked into a multi-year Enterprise License Agreement with Broadcom, the financial penalty for early exit may exceed the savings from Nutanix.

Better Move: Wait until renewal, then plan a strategic exit. Use this time to architect your Nutanix environment and train your team.

2. Your Plan is Full Public Cloud in 12 Months

If your strategy is to exit the data center entirely (100% AWS/Azure), migrating to Nutanix is an expensive detour.

Better Move: Go directly to VMware to Native Cloud. Nutanix is for organizations committed to on-prem or hybrid for 3+ years.

3. You Have Deep NSX-T Automation

If you've built complex NSX-T micro-segmentation with thousands of security groups and automated workflows, rebuilding this in Nutanix Flow is a 6-12 month project.

Better Move: Evaluate if the Broadcom price hike justifies the rebuild cost. For some heavily automated environments, staying on VMware (even at 2x cost) may be cheaper than re-platforming.

4. You Lack In-House Networking Expertise

Nutanix HCI is heavily network-dependent. If your team doesn't understand Leaf-Spine fabrics, Jumbo Frames (MTU 9000), and LACP bonding, you will have outages.

Better Move: Hire a strong network architect before migrating, or choose a managed service partner who handles the infrastructure layer.

5. Your Workloads Are Highly vSphere API-Dependent

If you have custom automation that talks directly to vCenter's proprietary APIs (e.g., vMotion orchestration, DRS automation), those scripts will break on Nutanix.

Better Move: Audit your automation. If the rebuild cost exceeds the licensing savings, staying on VMware might be justified.

---

Section 04

Top 3 Failure Modes

Migrations commonly face major delays. Click to see why.

1. The "Big Bang" Network Cutover

Failure: Trying to migrate hundreds of VMs and switch routing/firewall rules simultaneously. Consequence: Massive outages, inability to rollback, and weeks of troubleshooting connectivity issues. Prevention: Use a stretched L2 network to migrate subnet-by-subnet. Validate application connectivity in the new environment before cutting over the gateway.

2. Ignoring IOPS Requirements

Failure: Assuming HCI storage performance equals SAN performance 1:1 without sizing. Consequence: "Noisy neighbor" issues where one heavy database chokes the entire cluster. Prevention: Run a full performance assessment (e.g., RVTools + Nutanix Sizer) to ensure the target cluster has enough flash/NVMe capacity to handle peak IOPS.

3. Driver Mismatch (BSODs)

Failure: Forgetting to inject Nutanix VirtIO drivers into the guest OS before migration. Consequence: VMs fail to boot on AHV (Inaccessible Boot Device) or crash immediately. Prevention: Use Nutanix Move, which automatically handles driver injection and IP retention for supported OS versions.

---

Section 05

5 Technical Traps

1. NSX Lock-in: If you heavily use NSX-T for micro-segmentation, you cannot simply "migrate" policies. They must be re-architected in Nutanix Flow.
   • Risk: Security gaps or connectivity blocks post-migration.
   • Mitigation: Audit firewall rules and map them to Flow categories before moving a single VM.
2. Proprietary APIs: Applications that talk directly to vCenter APIs (e.g., automation scripts, monitoring tools) will break.
   • Risk: Loss of observability or automation failure.
   • Mitigation: Inventory all tools connecting to vCenter. Replace with Prism APIs or cross-platform tools (Terraform, Ansible).
3. Raw Device Mappings (RDMs): AHV supports Volume Groups, but the migration of RDMs requires specific handling.
   • Risk: Data loss or corruption if treated as standard vDisks.
   • Mitigation: Convert RDMs to vDisks where possible, or use Nutanix Volume Groups for clustering requirements.
4. USB Passthrough: Hardware dongles (license keys) are notoriously difficult to pass through in HCI environments.
   • Risk: Legacy apps failing to run due to missing license keys.
   • Mitigation: Switch to network-based licensing or use network-attached USB hubs (AnywhereUSB).
5. Jumbo Frames: MTU mismatches between the physical switch, CVM, and Guest VM are a classic headache.
   • Risk: Intermittent network drops and poor throughput.
   • Mitigation: Ensure end-to-end Jumbo Frame (MTU 9000) configuration on the physical leaf-spine network.

---

Section 06

Migration Roadmap

Phase Details

• Phase 1: Discovery (Weeks 1-4): Use tools like RVTools and Nutanix Collector to get a precise inventory. Map application dependencies to avoid breaking multi-tier apps.
• Phase 2: Design (Weeks 5-8): Size the Nutanix cluster correctly. Design the network fabric (Leaf-Spine is recommended) and define security policies in Flow.
• Phase 3: Pilot (Weeks 9-10): Migrate low-risk, non-critical workloads (Dev/Test) to validate the process, drivers, and performance.
• Phase 4: Waves (Weeks 11-20): Execute migration in pre-defined waves (e.g., by application group). Use Nutanix Move for automation.
• Phase 5: Decom (Week 21+): Verify performance, update documentation, and finally, decommission the old VMware hardware and terminate licenses.

---

Section 07

Data Migration Specifics: How VMs Actually Move

The mechanics of VM migration determine your cutover windows and your risk.

The Nutanix Move Process (Recommended)

Nutanix Move is the official migration tool. It automates the heavy lifting and is free for Nutanix customers.

How It Works:

1. Seed Copy (Days 1-7): Move creates an initial snapshot of the VM's disks and copies the data to the Nutanix cluster while the VM is still running on VMware. This can run in the background for days/weeks for large VMs.
2. Incremental Sync (Ongoing): Move continuously syncs changed blocks from the source VM to the target. This keeps the migration "warm" and minimizes cutover downtime.
3. Cutover Window (5-30 minutes): When you're ready, you trigger the cutover. Move does a final sync, shuts down the source VM, injects Nutanix VirtIO drivers, and boots the VM on AHV. The VM gets the same IP address (if using the same VLAN).

Expected Downtime per VM:

• Small VMs (<100GB): 1-5 minutes
• Medium VMs (100GB-1TB): 5-15 minutes
• Large VMs (1TB-5TB): 15-30 minutes
• Massive VMs (5TB+): 30-60 minutes (plan these carefully)

Volume Capacity:

• Move can handle 50,000 VMs in a single migration project.
• Typical throughput: 10-20 VMs per hour (depending on network bandwidth and VM size).

---

Rollback Strategy: The Safety Net

Critical Rule: Do NOT delete the source VM until the migrated VM has been validated in production for 48-72 hours.

3-Phase Rollback Plan:

Phase 1: Pre-Cutover (Low Risk)

If something goes wrong during seed copy or testing:

• Simply delete the target VM on Nutanix.
• The source VM on VMware is still running.
• Rollback Time: Instant (nothing changed on production).

Phase 2: Post-Cutover (First 48 Hours)

If the VM boots but has issues (performance, connectivity, driver problems):

• Power off the VM on Nutanix.
• Power on the original VM on VMware.
• Update DNS/load balancers to point back to the old VM.
• Rollback Time: 15-30 minutes (depending on DNS TTL).

Phase 3: After Source Deletion (High Risk)

If you deleted the source VM and now need to go back:

• Restore the source VM from VMware backups (Veeam/Commvault).
• This is why you keep backups of the source for 7-14 days post-migration.
• Rollback Time: 2-8 hours (restore + validation).

Best Practice: Use a "Wave Migration" approach. Migrate 10-20 VMs, validate for a week, then proceed. Don't migrate everything at once.

---

Testing & Validation Checklist

Before declaring a VM migration "successful," validate:

Boot Test:

• ✅ VM powers on without errors
• ✅ Operating system loads (no BSOD/kernel panic)
• ✅ VirtIO drivers are installed and active

Network Test:

• ✅ VM has correct IP address
• ✅ Can ping gateway and DNS servers
• ✅ Application ports are accessible (test with telnet or nc)

Application Test:

• ✅ Application service starts (web server, database, etc.)
• ✅ End-to-end connectivity (can users access the app?)
• ✅ Performance is acceptable (response time, query latency)

Data Integrity:

• ✅ Database integrity checks (e.g., DBCC CHECKDB for SQL Server)
• ✅ File system verification (no corrupted files)

Backup Test:

• ✅ Veeam/backup solution can see the VM
• ✅ Test backup completes successfully
• ✅ Test restore to verify recoverability

---

Section 08

Total Cost of Ownership: VMware vs. Nutanix

The following comparison shows where a 3-year TCO difference for a 500-VM environment can come from. It is directional, not measured; replace it with your own quotes.

---

Section 09

Architecture: The Shift to HCI

Migrating to Nutanix means moving from a traditional 3-tier architecture (Servers + SAN Switch + Storage Array) to Hyperconverged Infrastructure (HCI).

Key Transformation:

• Before (VMware 3-Tier): Compute and Storage are physically separate. Scaling requires buying big "bricks" of storage (SAN). Management is siloed (vCenter + SAN GUI + NSX).
• After (Nutanix HCI): Compute and Storage are converged into a single node. Storage is software-defined (Distributed Storage Fabric). Scaling is linear - just add a node. Single management pane (Prism).

The Mindset Shift:

• Old World: You managed LUNs, RAID Groups, and FC Zoning.
• New World: You manage Storage Containers and Resiliency Factors (RF2 = 2 copies, RF3 = 3 copies).

This architectural simplification is a key driver of the operational savings, but it requires your team to unlearn SAN habits.

---

Section 10

When to Hire VMware to Nutanix Migration Services

You don't need a partner for every migration. But here are scenarios where professional services pay for themselves:

1. The Broadcom Renewal Shock (Most Common)

Your VMware renewal quote just arrived. It's a multiple of what you paid last year. The CFO is demanding alternatives.

Trigger: "We got a $2M renewal quote for licenses that were $300K last year."

Why Hire: You need a detailed TCO analysis comparing Broadcom's new pricing vs. Nutanix NCI. Partners can model the 3-year cost including hardware, migration services, and training - giving you a defensible business case.

---

2. Hardware Refresh Alignment

Your VMware servers are 5+ years old. You're facing a $3M capital expenditure (CapEx) to refresh the hardware.

Trigger: "Do we refresh the SAN, or is this the moment to rethink our architecture?"

Why Hire: This is a natural migration window. Partners can help you size a Nutanix cluster that runs on commodity hardware (Dell, HPE, Lenovo), eliminating the SAN refresh entirely. The hardware savings often fund the migration project.

---

3. VDI/EUC Modernization

You're running Citrix or VMware Horizon on vSphere. User experience is degraded (slow login times, desktop lag). VDI licensing costs are out of control.

Trigger: "Our VDI users are complaining, and our VMware + Citrix licensing is $1M/year."

Why Hire: VDI on Nutanix is a proven pattern. Partners like XenTegra specialize in migrating VDI workloads to Nutanix with Frame or native Citrix integration, which can reduce licensing cost; ask for a quote against your current spend.

---

4. Complex NSX-T Environment

You use NSX-T for micro-segmentation across hundreds of applications. You need to migrate these security policies to Nutanix Flow without creating gaps.

Trigger: "We have 5,000 NSX firewall rules. How do we move this to Nutanix without breaking everything?"

Why Hire: This is not a DIY project. Partners have automation tools to map NSX policies to Flow categories. Attempting this manually will result in security incidents or connectivity outages.

---

5. Multi-Site Global Deployment

You have VMware deployments in 10+ data centers across regions (EMEA, APAC, Americas). You need a consistent migration approach.

Trigger: "We need to migrate 5,000 VMs across 12 sites in 6 countries."

Why Hire: Global deployments require project management rigor, standardized runbooks, and 24/7 support. Partners like Persistent Systems or Nutanix Services have the delivery scale to execute this.

---

6. Lack of Internal HCI Expertise

Your team knows VMware well but has never worked with Nutanix, and has no time to learn while keeping production running.

Trigger: "We need to migrate in 6 months, but our team has zero Nutanix experience."

Why Hire: Partners provide residency (embedding experts on-site for 3-6 months) to train your team while executing the migration. By the time they leave, your team owns the platform.

---

Section 11

How to Choose a Migration Partner

Migrating a data center carries real operational risk. You need a partner who knows both VMware and Nutanix well.

If you are a Global Enterprise: Choose Nutanix Services or Persistent Systems. You need the scale, the project management rigor, and the ability to handle thousands of VMs across regions.

If you are a Mid-Market Company (UK/EU): Virtually Cloud is a strong choice. They offer the personalized attention and agility that large GSIs often lack.

If you are heavily VDI (Citrix/Horizon): XenTegra is the specialist here. VDI migrations have unique performance sensitivities that generalist partners often miss.

Red flags when evaluating partners:

• "We'll script it all manually": Run away. Modern migrations should use Nutanix Move or similar automation tools. Manual rebuilds are error-prone and slow.
• No Network Expertise: If they don't ask about your physical switch config (Leaf-Spine, MTU, LACP) in the first meeting, they aren't qualified. HCI relies entirely on the network.
• Ignoring the Application: If they treat every VM as a black box without asking what runs inside, they will break your complex multi-tier applications.

---

Section 12

Post-Migration: The First 90 Days

The first 90 days after the last VM boots on Nutanix cover stabilization, optimization, and team enablement.

Month 1: Stabilization & Monitoring

Week 1-2: Hypervigilance

• Daily Health Checks: Review Prism Central alerts every morning. Look for disk failures, CVM issues, or network anomalies.
• Performance Baseline: Capture baseline metrics (VM CPU/RAM usage, storage IOPS, cluster latency). Use these to detect regressions.
• Support Hotline: Keep your migration partner on retainer for "break-fix" support. Expect 5-10 minor issues in the first two weeks (driver updates, MTU mismatches, etc.).

Week 3-4: Fine-Tuning

• Rightsizing: Review VM resource allocation. Many VMs were over-provisioned on VMware. Downsize RAM/CPU to reduce cluster load.
• Storage Optimization: Enable deduplication and compression (Nutanix does this automatically, but verify it's active).
• Backup Validation: Run a full backup cycle and test a restore. Verify Veeam/Commvault integration is working correctly.

Key Metrics to Track:

• Cluster CPU Usage: Should be <70% under normal load.
• Storage Latency: Should be <1ms for flash-based storage.
• CVM Memory: Each CVM should have enough RAM (minimum 32GB for production clusters).

---

Month 2: Optimization & Training

Team Enablement:

• Prism Training: Send 2-3 admins to official Nutanix training (or bring an instructor on-site). Nutanix offers free online courses (Nutanix University).
• Runbook Updates: Document the new operational procedures (how to add a node, how to handle a disk failure, how to resize a VM).
• Automation: Start building automation with Prism APIs or Terraform. Don't manage Nutanix through the GUI forever.

Cost Optimization:

• Decommission VMware Licenses: Now that migration is complete, cancel your VMware VCF/vSphere subscriptions. This is where the ROI hits.
• Hardware Decommission: If you have old SAN arrays or VMware servers, work with your data center to retire them (reclaim rack space, reduce power/cooling costs).

Advanced Features Exploration:

• Nutanix Flow: Start migrating your NSX firewall policies to Flow. This is often deferred during migration but should be tackled now.
• Data Protection: Explore Nutanix native replication for disaster recovery (cheaper than Veeam for some use cases).

---

Month 3: Operational Maturity

Capacity Planning:

• Growth Projections: Model your VM growth for the next 12 months. How many nodes will you need to add? Plan hardware purchases.
• N+1 Validation: Ensure your cluster can survive a node failure. Run a node failure simulation (shutdown a node, verify VMs stay up).

Incident Response:

• Failure Drills: Simulate a disk failure. Verify that Nutanix auto-rebuilds the data across remaining nodes.
• Disaster Recovery Test: If you have a second Nutanix cluster for DR, test a failover. Ensure RPO/RTO targets are met.

Knowledge Transfer Completion:

• Partner Handoff: If you had a migration partner on-site, this is when they transition out. Your team should be self-sufficient by Day 90.
• Documentation Audit: Ensure all runbooks, architecture diagrams, and escalation paths are documented in your wiki/Confluence.

Success Metrics (Day 90 Checklist):

• ✅ Zero critical incidents in the past 30 days
• ✅ Team can add a node without vendor assistance
• ✅ Backup/restore tested successfully
• ✅ VMware licenses fully terminated
• ✅ Cluster has 20-30% free capacity (headroom for growth)

---

Section 13

FAQ

See the FAQ section at the top of the page for common questions about licensing, downtime, and technical compatibility.

---

Evidence note: Earlier versions of this page cited project counts, median costs and timelines, and success and failure rates that could not be reproduced from available records; they have been withdrawn. Cost and timeline ranges are editorial scoping ranges, not supplier quotes. See our methodology.

---

Section 14

Risk Factors

Network Dependency Mapping

Failure to map VLANs and firewall rules from NSX to Flow can leave migrated VMs isolated.

Storage IOPS Mismatch

Moving from SAN to HCI requires careful sizing; under-provisioned CVMs can choke database performance.

Guest OS Drivers

Forgetting to install Nutanix VirtIO drivers before cutover results in BSOD/kernel panics on boot.

Backup Compatibility

Legacy backup solutions (e.g., older Veeam versions) may not fully support AHV snapshots.

Licensing Overlap

Migrating too slowly can force a double-pay scenario: renewing VMware VCF while paying for Nutanix.

---

Section 15

Feasibility Analysis

Ideal candidates

• Organizations facing >100% VMware renewal hikes
• Hardware refresh cycles aligning with migration
• Teams willing to adopt AHV (learning curve)

Break-even cost: Month 14 Talent risk: Moderate (AHV is simpler than vSphere but requires training)