Module 10: Migration Path (The Customer-Running Playbook)

The Promise

By the end of this module you will:

1. Run a 12-18 month customer migration engagement end to end. Discovery, dependency mapping, platform build, pilot wave, production waves, cutover, decommissioning. The shape is consistent across customers; the specifics vary. You should be able to walk into a customer kickoff and lead the conversation.
2. Use Move (the Nutanix migration tool) confidently. What it migrates, what it doesn't, what to plan for, what tends to require manual cleanup.
3. Sequence migrations by risk, not by convenience. Pilot first (low-risk, internal), then low-tier production, then Tier-1, then mission-critical. Many customer projects fail because they invert this sequence; BlueAlly SAs lead customers to the right order.
4. Design the hybrid steady-state honestly. Some workloads will stay on VMware for legitimate reasons (NSX-T routing complexity, NetApp ONTAP-specific workflows, SRM-orchestrated complex DR, third-party-vendor dependencies). The right answer for many customers is hybrid permanently. Position this as a successful outcome, not a failure.
5. Communicate with executives, IT teams, and end users at the right level for each. Migration is as much a communication exercise as a technical one. The cadence and framing differ for each audience; you should know all three.
6. Maintain a working risk register and act on it. Migrations have predictable risks (dependency surprises, application performance regressions, network reconfiguration issues, team capacity constraints). The risk register is how you stay ahead of them.
7. Know what year-2 stable state looks like and have the conversation about BlueAlly's continuing role: managed services, upgrades, expansion, periodic optimization. Migrations end; relationships continue.

This is the final module. After this, the curriculum hands you the appendices. The technical and commercial depth is in your hands. What remains is the engagement skill, which this module gives you a framework for.

Foundation: What You Already Know

You have done migrations. Maybe vCenter version upgrades. Maybe storage-array swaps with Storage vMotion. Maybe a datacenter consolidation with cross-site moves. Possibly a hypervisor migration (Hyper-V to ESXi, or vice versa). You know the patterns:

• Discovery is more time than you budget for. Customers don't have current inventories. Dependency surprises are the rule, not the exception.
• Pilot waves expose the real problems. Theory dies in contact with the customer's actual environment.
• Mission-critical workloads come last. Practice on dev/test, build confidence, then move toward Tier-1.
• Communication failures cause more pain than technical failures. End users blindsided by an outage will not forgive you for being technically right.
• The team gets tired. Migrations are marathons. Plan for fatigue.
• Cutover is the moment, not the project. The 18 months around cutover are the project. The cutover itself is brief if everything else is right.

You also know what the VMware-to-Nutanix migration is not:

• It is not Storage vMotion. That works between VMFS datastores; it does not cross hypervisor boundaries.
• It is not vMotion. vMotion crosses ESXi hosts within a vSphere cluster, not between vSphere and AHV.
• It is not a backup-and-restore operation. Backup-and-restore is a fallback path, not the primary tool.
• It is not a single weekend's work. Realistic migrations take 6-18 months for typical enterprise environments.

The migration tool is Move. The framework is the phased-wave approach. The discipline is sequencing by risk. The communication is to multiple audiences with different framings. Hold all of those in mind.

Core Content

Move: The Migration Tool

Move is Nutanix's cross-platform VM migration tool. It supports several source-to-target paths:

• VMware ESXi to AHV. The primary use case for customers consolidating from VMware. Move connects to vCenter, accesses source VMs, migrates them to a target Nutanix AHV cluster.
• Hyper-V to AHV. Less common but supported. Useful for customers consolidating mixed VMware + Hyper-V environments.
• AWS EC2 to NC2 (or to on-prem AHV). For customers moving cloud workloads.
• AWS EC2 to AHV on-prem. Cloud repatriation.
• Azure to NC2.
• AHV to AHV across clusters (utility for cross-cluster migrations).

The architecture:

• A Move appliance (a VM, deployed on the target Nutanix cluster typically) coordinates the migration.
• An agent (often agentless on ESXi) connects to the source environment.
• The Move appliance reads source VM data (disks, configuration, network attachments).
• During migration, Move performs initial replication of VM data to the target cluster, then incremental sync of changes, and finally a brief cutover (the source VM is shut down, final delta is replicated, target VM starts).
• Cutover downtime is typically 5-30 minutes per VM, depending on size and final delta. For most workloads, this fits within scheduled maintenance windows.

What Move handles automatically:

• VM disk migration (the bulk of the data).
• VM configuration translation (CPU, RAM, NICs in best-effort).
• Power state preservation (VM running on target after migration).
• Some network mapping (Move asks you to map source port groups to target virtual networks).
• VMware Tools removal and NGT (Nutanix Guest Tools) installation in some scenarios.

What requires manual handling:

• Complex networking. Distributed switches with advanced port-group policies often require manual reconfiguration.
• Application-specific configurations. SQL Server cluster configurations, Oracle ASM disk layouts, anything that depends on storage paths or hypervisor-specific features.
• NSX-T microsegmentation. Requires re-implementing on Flow (or coexistence with NSX-T).
• Custom guest OS modifications. Customizations that depend on VMware Tools or VMware-specific drivers may need attention.
• Snapshots and backups. Old snapshot chains in VMware do not migrate cleanly; consolidate or accept that historical snapshots do not transfer.
• Storage policies. vSAN-specific storage policies (FTT, stripe count) don't have direct equivalents in DSF. The DSF replacement (RF, EC, compression, dedup) is configured at the Storage Container level.

Diagram: Move Tool Architecture

The 7-Phase Migration Framework

Successful migrations follow a phased structure. Each phase has clear entry and exit criteria.

Phase 0: Discovery and Dependency Mapping (4-8 weeks)

Inventory everything. Map dependencies. Classify workloads by risk and tier. Identify integration points (AD, network, monitoring, backup, DNS, load balancers, ITSM).

Deliverables:

• VM inventory with: name, OS, vCPU/RAM, storage, network attachments, dependencies, owning team, business tier, RPO/RTO requirements, compliance flags
• Application affinity groups (which VMs talk to which other VMs)
• Network dependency map (firewalls, load balancers, external services)
• Storage classification (block / file / object usage)
• Customer's existing tooling inventory (backup, monitoring, ITSM)

Common discovery techniques: active discovery tools (Nutanix's discovery utility, Lansweeper, RVTools for VMware), Application Performance Monitoring data, workshops with application owners, network flow analysis. This phase often takes longer than expected. Budget aggressively.

Phase 1: Platform Build and Validation (4-6 weeks)

Deploy the Nutanix cluster. Validate it. Integrate with customer's environment.

Deliverables: Nutanix cluster deployed and validated against POC criteria; AD / SAML / SSO integration; network integration (VLANs, routing, firewalls); backup integration (Veeam / Commvault / Rubrik against Nutanix Objects or vendor-specific); monitoring integration (Prism Central forwarding to customer's SIEM, ITSM); DR site configured if applicable; categories defined (from Module 4, drives policies in subsequent waves).

Phase 2: Pilot Wave (4-8 weeks)

Migrate 5-20 low-risk VMs. Validate the migration tooling, process, and team capacity. This is where theory meets reality.

Pilot VM selection criteria:

• Internal IT-team-owned (so the customer's team is the audience for any issue)
• Low criticality (no customer-facing impact if something goes wrong)
• Representative of common patterns (Linux + Windows mix, typical applications)
• Ideally including one VM from each major tier of complexity

Pilot wave establishes: Move tool installation and operation in the customer's environment; network mapping table (source port group to target virtual network); cutover runbook; communication template; rollback procedures (validated, not theoretical); the customer's team's hands-on familiarity with the new platform.

Phase 3: Production Wave 1 (Low-Tier, 8-16 weeks)

50-200 VMs. Dev/test/UAT environments. General-purpose Tier-3 production. Web tiers behind load balancers (with redundancy that absorbs cutover blips).

This wave is where you scale the team's capacity and validate the operational rhythm. By the end: the customer's team can do migrations without BlueAlly hand-holding; the runbook is mature; common issues are identified and have known mitigations; confidence is built for the next tier.

Phase 4: Production Wave 2 (Tier-1, 12-20 weeks)

200-600 VMs typically. Tier-1 production: customer-facing applications, internal-critical applications, databases (with care), core business workflows.

Tier-1 migrations require: application-owner coordination per migration batch; clear validation criteria per application; rollback plans validated per application; cutover scheduled in maintenance windows; application-aware migration patterns (for SQL Server, use Always On to minimize downtime; for Oracle, planned-failover patterns; for clustered apps, failover to standby, migrate primary, fail back).

Phase 5: Production Wave 3 (Mission-Critical, 8-16 weeks)

The remaining workloads: Tier-0 mission-critical, often with zero-downtime requirements, complex application dependencies, regulated workloads, integration-intensive systems.

Often this wave includes workloads that genuinely require Metro Availability or NearSync (Module 7), mission-critical applications with regulatory compliance constraints, applications with complex external integrations, and workloads that may stay on VMware permanently if business case justifies (the hybrid steady-state question). This wave gets the most engineering scrutiny per workload. Per-VM time investment is highest.

Phase 6: Stabilization, Decommissioning, and Steady-State (4-8 weeks)

Decommission old VMware infrastructure (or formalize the hybrid steady-state). Hand off operational ownership to customer team. Document final state. Conduct retrospective.

Deliverables: decommissioning plan executed (physical removal, contract termination, asset disposal); hybrid steady-state documentation if applicable; final BoM reconciliation; operational runbook handed off; retrospective with all stakeholders; BlueAlly's continuing role defined (managed services, upgrades, future expansion).

Diagram: The 7-Phase Migration Framework

The Cycle, Frame Two: Migration as Phased Risk Management

For a customer's IT operations leader, the durable migration frame is risk management. Each phase has a specific risk being reduced.

Frame each phase as risk reduction. Customers who think in risk-management terms (which is most operations leaders) respond to this framing. The migration is not about VM movement; it's about systematically reducing risk.

The Cycle, Frame Three: Migration as the SA's 12-18 Month Engagement

For BlueAlly, the migration is the engagement. The shape:

• Month 0-2: Discovery + platform build. Heavy SA engagement. BlueAlly visible weekly.
• Month 3-5: Pilot wave. SA is hands-on; the customer's team is learning.
• Month 6-10: Production waves. SA shifts to oversight + coaching; the customer's team is executing.
• Month 11-15: Tier-1 + mission-critical waves. SA is back hands-on for the highest-risk migrations.
• Month 16-18: Stabilization. SA hands off to managed services or to the customer's steady-state team.

The SA's role evolves from technical leader (early) to coach (middle) to specialist consultant (late) to relationship maintainer (after). Recognize the role shift. The customer's team's growing competence is a sign of success, not a threat to your engagement.

The Cycle, Frame Four: Migration as Platform Consolidation

For an executive sponsor (CIO, CTO, sometimes CFO), the durable frame is platform consolidation. The migration is one part of a broader simplification.

Frame the migration as consolidation, not as VM movement. Executive sponsors care about portfolio simplification, not about Move tool mechanics.

Hybrid Steady-State: The Permanent Coexistence

Some workloads will not migrate. Legitimate reasons:

• NSX-T routing complexity. Customers with deep NSX-T deployments (BGP integration, edge services, L2VPN, advanced routing) often keep those workloads on VMware-on-Nutanix or on traditional VMware infrastructure.
• NetApp ONTAP-specific workflows. Customers using FlexClone, FlexCache, or other ONTAP-specific features at high volume may keep file workloads on NetApp.
• SRM-orchestrated complex DR. Customers with mature SRM deployments and complex runbook customization may continue running SRM-on-ESXi-on-Nutanix.
• Vendor-specific certifications. Some applications are vendor-certified only on specific hypervisors. Until the vendor certifies AHV, those workloads stay where they are.
• Regulatory or compliance constraints. Some compliance frameworks audit specific platform configurations; changing introduces audit risk that the customer chooses not to take.
• Application performance characteristics. Some workloads (rare, but real) perform meaningfully better on specific platforms.

Hybrid steady-state is not a project failure. It is often the right architectural answer. The customer migrates the bulk (often 70-90%) to Nutanix, captures most of the consolidation value, and accepts permanent coexistence for the remaining workloads.

The hybrid steady-state has its own design decisions:

• Network connectivity between platforms (typically continuous, since applications often span both).
• Identity integration (single AD / SAML applied to both).
• Backup strategy (often unified through backup vendor; both platforms protected).
• DR strategy (potentially separate per platform, or unified if backup-and-restore-based).
• Operational team structure (Nutanix-team vs VMware-team, or unified-team that operates both).
• License optimization (reduce VMware footprint to actual remaining workload, not legacy quotas).

Diagram: Hybrid Steady-State Architecture

Risk Register: The Predictable Migration Risks

A working risk register tracks identified risks, mitigations, and ownership. Common risks across migrations:

Technical risks:

• Dependency surprises. Discovery missed an application dependency; the migration breaks something downstream. Mitigation: thorough Phase 0 + pilot wave validation + application-owner coordination per batch.
• Application performance regression. A workload runs slower on the new platform than expected. Mitigation: pre-migration baseline metrics + post-migration validation criteria + rollback plan.
• Network reconfiguration issues. Subnets, VLANs, firewall rules don't translate cleanly. Mitigation: detailed network mapping in Phase 0 + dry runs.
• Storage migration delays. Initial replication takes longer than estimated; cutover slips. Mitigation: realistic bandwidth assessment + parallel-running periods that absorb delays.
• Tool failures. Move encounters edge cases; specific VMs don't migrate cleanly. Mitigation: per-VM rollback plans + manual migration alternatives + support escalation paths.

Operational risks:

• Team capacity constraints. Customer's team is too thin to absorb migration work alongside operations. Mitigation: realistic capacity planning + BlueAlly augmentation + phasing that respects team bandwidth.
• Runbook drift. Migration runbook becomes stale as environment changes during migration. Mitigation: regular runbook reviews + version control + dedicated runbook owner.
• Communication failures. Stakeholders blindsided by migrations or outages. Mitigation: communication cadence + named communication owner + structured templates.

Commercial risks:

• Scope creep. Customer adds workloads or requirements mid-engagement. Mitigation: change-control process + scope reviews per phase + clear definitions of "in scope" vs "follow-on engagement."
• Timeline slippage. Phases run long; customer renegotiates contract. Mitigation: realistic phase budgets + early escalation + transparent status reporting.
• License optimization missed. Customer continues paying for VMware footprint that isn't being used. Mitigation: license consumption tracking + decommissioning aligned to migration progress.

Relationship risks:

• Executive sponsor turnover. The CIO who approved the project leaves; the new sponsor questions the rationale. Mitigation: strong written justification + executive briefings throughout + tangible mid-project value demonstration.
• Customer team morale. Migration fatigue sets in around month 9-12. Mitigation: celebrate wins + visible progress milestones + manage workload pacing.

The risk register is reviewed weekly with the customer's project lead and monthly with the executive sponsor. New risks are added as discovered. Closed risks are documented. The register is a living document.

Communication Playbook by Audience

Migrations have multiple audiences, each with different information needs and frequencies.

• Executive sponsor (monthly executive review): 30-minute meeting with a one-page status summary. Progress against milestones, top 3 risks, key decisions needed, financial update. Tone: business outcomes, not technical detail.
• Project steering committee (weekly): 60-minute working session with detailed status. Phase progress, wave-by-wave status, risk register review, change requests, resource needs. Tone: project management, action-oriented.
• Application owners (per migration batch): pre-migration coordination, day-of-cutover communication, post-migration validation. Tone: respectful of their expertise, clear about responsibilities.
• End users (per migration with user impact): notification email + status page + helpdesk readiness. Tone: minimize concern, clear instructions.
• IT operations team (continuous): shared documentation, daily standup during active migration windows, real-time chat. Tone: collaborative, hands-on.

Year-2 Stable State and the Continuing Relationship

Migrations end. The customer's environment stabilizes. What does year 2 look like and what is BlueAlly's continuing role?

Customer's year-2 reality: the Nutanix cluster is the operational platform; the customer's team is competent at routine operations; periodic upgrades (LCM-driven) happen on a quarterly or semi-annual cadence; capacity planning is part of routine work; hybrid steady-state (if applicable) is being managed; the original BoM and TCO assumptions are tracking (or they aren't, and there are conversations about why).

BlueAlly's continuing role options:

• Managed services. BlueAlly operates the platform on the customer's behalf (or co-managed with the customer's team). Common for customers with thin internal teams.
• Quarterly health checks and optimization reviews. BlueAlly reviews the environment quarterly, identifies optimization opportunities, recommends adjustments.
• Upgrade support. BlueAlly leads major version upgrades; the customer team handles minor.
• Expansion projects. Adding clusters, additional sites, NC2 cloud presence, NKE Kubernetes deployments, additional Nutanix products.
• Training and certification programs. BlueAlly delivers ongoing training as the customer's team grows or rotates.
• Strategic advisory. BlueAlly's SA participates in the customer's annual infrastructure planning.

The continuing relationship matters commercially (recurring revenue) and reputationally (reference customers, peer referrals). Plan for it from the beginning of the engagement.

Lab Exercise: Build a Migration Plan for a Realistic Customer

The scenario:

• 16 ESXi hosts (Dell PowerEdge R750) running ~600 VMs
• Mix of workloads: ~50 mission-critical (Tier-0), ~150 Tier-1 (databases, customer-facing apps), ~250 Tier-2 (general-purpose), ~100 Tier-3 (dev/test), ~50 ROBO sites
• NetApp filer (200 TB), Pure FlashArray for iSCSI to bare-metal Oracle (50 TB), Data Domain for Veeam (100 TB)
• VCF subscription, NSX-T (30 VMs use deep microsegmentation)
• SRM with 200 VMs orchestrated
• 4 datacenters (2 production, 1 DR, 1 ROBO consolidation site)
• Customer has 8-person infrastructure team
• Decision to consolidate to Nutanix on Dell XC hardware made; refresh window is 12 months out
• BlueAlly engaged to lead the migration

Build the following deliverables:

1. Phase plan with timeline (months 0-18) showing each of the 7 phases, their duration, and key deliverables.
2. Discovery checklist for Phase 0: what you need to inventory, who you talk to, what tools you use.
3. Pilot wave VM selection: propose 15 specific VMs (by category) that would be in the pilot wave. Justify each selection.
4. Wave 1 plan: which 100-200 VMs go in Wave 1 (low-tier production). What's the cutover strategy? What are the validation criteria?
5. Wave 2 plan: Tier-1 production. Which 200-300 VMs? What application-specific patterns are needed (e.g., SQL Always On, Oracle planned-failover)?
6. Wave 3 plan: Mission-critical. Which 50 VMs? What special handling do they need?
7. Hybrid steady-state assessment: which workloads (if any) might stay on VMware permanently? Why? What's the design implication?
8. Risk register: top 10 risks for this engagement, with mitigations and ownership.
9. Communication plan: cadence and format for executive sponsor, steering committee, application owners, end users, IT team.
10. Success criteria: how does the customer know the migration succeeded? Define quantitative and qualitative criteria.
11. BlueAlly engagement model: what's the resource plan from BlueAlly side? Lead SA, supporting engineers, project manager. Hours per phase.
12. Year-2 stable state proposal: what does steady state look like? What's BlueAlly's continuing role?

What this teaches you:

• The shape of a real migration plan.
• The interconnection between technical sequencing, communication, risk management, and commercial structure.
• The discipline to produce complete artifacts before kickoff.
• The mental model of a 12-18 month engagement.

Customer-demo angle: Plans 1-3 above are what you walk into a customer kickoff with. Practice presenting them. The customer's project lead and executive sponsor are the audience. Time it: a 60-minute kickoff covers items 1-12 at appropriate depth.

What You Now Have

You can run a 12-18 month customer migration engagement end to end. Discovery, platform build, pilot, three production waves, stabilization, decommissioning. The shape is consistent; the specifics adapt to each customer.

You know Move's mechanics: cross-platform migration with brief cutover, what it handles automatically, what requires manual planning (NSX-T policies, complex application configurations, vSAN-specific storage policies, snapshot chains).

You know the 7-phase framework with clear entry and exit criteria per phase. You can produce a phased plan in your sleep and adapt it to the customer's environment.

You know the four mental frames for migration: phased risk management, the SA's 12-18 month engagement, platform consolidation, and what customers actually pay for and want.

You can position hybrid steady-state honestly. 70-90% migration with the rest remaining on VMware is often the right architectural answer. You frame it as a successful outcome, not a failure.

You can communicate at the right level for each audience: executive sponsor (monthly, business outcomes), steering committee (weekly, project management), application owners (per batch, technical and respectful), end users (notifications, minimize concern), IT team (continuous, collaborative).

You maintain a working risk register and act on it. Technical, operational, commercial, relationship risks. Weekly review with project lead, monthly with executive sponsor.

You know what year-2 stable state looks like and the continuing relationship: managed services, quarterly health checks, upgrade support, expansion projects, training, strategic advisory. Migrations end; relationships continue.

Curriculum Capstone: What You Have After Ten Modules

Ten modules. The complete picture:

• Technical depth (Modules 1-8): HCI category, platform architecture, AHV hypervisor, management plane, DSF storage, networking and microsegmentation, data protection and DR, unified storage.
• Commercial depth (Module 9): NCI and NCM tiers, hardware sourcing, the Broadcom math, complete BoMs, 5-year TCO with sensitivity analysis, capex vs opex, multi-year subscription mechanics.
• Engagement depth (Module 10): Move tool, 7-phase framework, pilot through mission-critical waves, hybrid steady-state, communication playbook, risk register discipline, year-2 stable state.
• Cert preparation embedded throughout: NCA, NCP-MCI, NCM-MCI, NCP-NS, NCP-US, NCP-MCA, NCX-MCI oral defense via the 20+ NCX-style design questions.
• SA-chair vocabulary embedded throughout: objections handled honestly, discovery questions positioned, customer-demo flows for the highest-impact features, honest gaps named alongside honest strengths, coexistence patterns named for every incumbent comparison.

Appendices A through K complete the reference toolkit (built next).

You are now ready for real customer engagements. The curriculum's job is done. Yours begins.