One-Night Cutover of 120 VMware VMs

Waves, not a single night. With a four-hour downtime cap and a final sync that already takes 40 minutes per moderately busy VM, 120 VMs in one window is not credible. Sequence by risk and dependency:

1. Wave 0 - rehearsal: re-run the pilot with a timed final sync and a rollback rehearsal. Measure actual throughput rather than assuming it.
2. Wave 1 - low-risk stateless: dev/test, web front ends, utility servers. Expect batches sized so the sum of final syncs plus verification fits well inside the downtime allowance; parallel Move appliances help, WAN and storage throughput limit you.
3. Wave 2 - business applications with documented start order and owners available at cutover.
4. Wave 3 - databases and anything with external dependencies, last, once the process is boring.

Oracle RAC: Move cannot migrate physical-mode RDMs or a shared VMDK - they are not VMDK-backed guest disks in a form Move can copy. Options, in order of preference: use Nutanix Database Service (NDB) or a DBA-led logical migration (Data Guard, export/import) to clean builds; or re-present storage through Nutanix Volumes/iSCSI inside the guests if the cluster must stay intact, validated by the DBA first. Do not discover this on cutover night - the RAC nodes are a separate project with a separate window.

Before cutover:

• Move pre-checks clean: no unsupported devices (RDMs, physical mode, passthrough), snapshot policy agreed (Move does not carry vSphere snapshots - remove them), ISO detach.
• Confirm whether the VM keeps its IP. If the AHV VLAN maps to the same subnet, IP preservation works; if the subnet changes, plan DNS and firewall updates in advance.
• Confirm the target network name in Move maps to the correct AHV VLAN on br0 - this is the single most common post-migration failure.

After cutover:

• Install Nutanix Guest Tools. Move may inject VirtIO drivers for Windows, but NGT is what gives you in-guest IP reporting, quiesced snapshots, and self-service restore. Without it, later protection-domain snapshots are crash-consistent only.
• Verify MAC address changes do not break anything license- or bonding-based in the guest.
• Check time sync, monitoring agents, backup client re-registration, and any hardcoded host entries.
• Keep the source VM powered off but intact for an agreed rollback period; deleting it immediately removes your only fallback.

Design around categories, not names. Assign categories to VMs and projects (for example Application, Environment, Tier, BackupPolicy) and have blueprints reference category-based constructs such as network and image selection, rather than literal VM names or fixed IPs. That is what lets the same blueprint deploy to dev and prod without editing.

Structure:

• One blueprint per application, with services and explicit dependencies so start order is deterministic.
• Credentials stored as Calm credentials, never in scripts.
• Variables for anything environment-specific (subnet, sizing, domain join OU).
• Post-create tasks for NGT installation, monitoring agent, and registration in configuration management.
• Version the blueprint and promote it; do not edit the production blueprint in place.

Pitfalls:

• Hardcoded IP addresses and hostnames, which break on the second deployment.
• Assuming Calm handles migration - it deploys, it does not move existing VMs; Move does that.
• Building blueprints before the categories are agreed, which forces a rebuild later.
• No test project: an untested blueprint that half-deploys is worse than a documented manual build, because nobody knows what state it left behind.