The “Lift-and-Shift” Lie: Why “Like-for-Like” Architectures Fail in a Post-Broadcom World

Key Takeaways

• The “Like-for-Like” Trap: Trying to map vSphere constructs 1:1 to Nutanix AHV or Proxmox destroys the ROI of the migration.
• The Hidden “Technical Debt” Tax: Migrating snapshots, mounted ISOs, and “zombie” VMs turns a 2-week cutover into a 6-month nightmare.
• Network Refactoring: Rebuilding complex NSX-T overlays on a new hypervisor is often unnecessary; simpler, native micro-segmentation is the “Day 2” win.
• The Audit Mandate: You cannot migrate what you cannot see. Blindly moving VMs without a readiness audit guarantees failure.

The Board finally approved it. You secured the budget to exit VMware, you selected your destination (Nutanix AHV, maybe Proxmox), and the mandate is clear: “Just move everything over. Keep it exactly the same.”

That sentence—“Keep it exactly the same”—is why 60% of virtualization migrations are currently failing to meet their ROI targets.

I recently audited a Fortune 500 retailer that was six months behind on their VMware exit. They treated Nutanix AHV exactly like vSphere. They mapped every ESXi host to an equivalent AHV node. They tried to recreate every NSX-T security tag manually. They essentially spent millions of dollars to build a “worse vCenter.”

In 2026, we have to stop treating these migrations as a copy-paste exercise. It is a refactoring event. If you lift-and-shift your legacy technical debt onto a modern HCI platform, you aren’t modernizing—you’re just moving your trash to a more expensive house.

The “Density Paradox”: Why 1:1 Compute Mapping Fails

The first mistake architects make is sizing the new environment based on the hardware of the old one, rather than the workload.

The Trap: “We have 50 ESXi hosts with 64 cores each. Therefore, we need 50 AHV nodes with 64 cores each.”

The Reality: Your old ESXi hosts were likely 30% over-provisioned to account for “vSphere bloat” and inefficient schedulers. Modern HCI stacks (like Nutanix) handle I/O data locality differently.

• Optimization: Don’t map cores. Map effective IOPS and RAM working sets.
• The Fix: If you simply replicate your old cluster count, you will overspend on licensing by ~40%.

The “Dirty Data” Problem: Migrating Garbage

The single biggest cause of failed cutovers isn’t the hypervisor compatibility—it’s the state of your VMs.

When you trigger a bulk migration (using Nutanix Move or similar tools), the migration engine expects a clean state. It does not expect:

1. Snapshot Chains: VMs running on a 2-year-old snapshot delta.
2. Mounted ISOs: A Linux VM with a locked install ISO from 2024.
3. Zombie VMs: Powered-off machines that haven’t been touched in 18 months but are still consuming storage credits.

The “War Story”: We had a cutover scheduled for a Sunday night. 400 production VMs. At 2:00 AM, the migration batch failed. Why? Because 15 critical database servers had mounted ISOs from a previous patch cycle, causing the hypervisor lock to reject the snapshot request. We spent the next 4 hours manually unmounting disks while the CIO watched over our shoulders.

The Solution: Audit Before You Move You cannot rely on vCenter’s “Health” badge. It lies. You need a forensic audit of the internal VM state.

We built the HCI Migration Advisor specifically for this “Pre-Flight” check.

• What it does: It ingests your RVTools export and flags every “migration blocker” (snapshots, ISOs, Zombies) that native tools miss.
• The Output: A Migration Pain Score. If your score is above 50, do not schedule the truck roll. You aren’t ready.
• The Win: Run the remediation scripts before you start the migration tool. Clean the environment, then move it.

The Network Trap: NSX-T vs. Native Flow

The second biggest failure point is networking. Broadcom’s NSX-T is a complex, overlay-heavy beast. Trying to rebuild that logic line-by-line in Nutanix Flow or standard VLANs is a fool’s errand.

The Decision:

• Stop Translating: Do not try to replicate every “Security Group.”
• Start Refactoring: Ask, “What is the intent of this rule?”
  • Old: “Allow SG-Web to SG-App over Port 443.”
  • New: “Category: Web talks to Category: App.”

If you are drowning in firewall rules, use the NSX-T to Flow Translator to interpret the intent of your legacy policy and map it to a modern, category-based model. Do not migrate rules that haven’t been hit in 180 days. Leave them behind.

Conclusion: The “Refactoring Cliff”

You are standing at a cliff. You can either build a bridge to a better architecture, or you can try to jump with a backpack full of rocks.

The “Lift-and-Shift” Approach:

• Migrates Zombies.
• Migrates Snapshots.
• Migrates “Any/Any” firewall rules.
• Result: You pay the “Broadcom Tax” and the “Migration Tax.”

The Refactored Approach:

• Audits usage (Deletes Zombies).
• Sanitizes state (Commits Snapshots).
• Simplifies policy (Zero-Trust).
• Result: You arrive on the new platform leaner, faster, and cheaper.

Before you migrate a single VM, audit your debt. Use the HCI Migration Advisor to see the rocks in your backpack before you jump.

Additional Resources:

• HCI Migration Advisor breakdown.
• Migration Best Practices: Nutanix Move User Guide – Reference for prerequisite states (Snapshots/ISOs).
• Technical Debt Analysis: Google Cloud Migration Framework – Validates the “Refactor vs. Rehost” methodology.

About The Architect

R.M.

Senior Solutions Architect with 25+ years of experience in HCI, cloud strategy, and data resilience. As the lead behind Rack2Cloud, I focus on lab-verified guidance for complex enterprise transitions. View Credentials →