VMware Migration and 15-Minute RPO on a Fixed Cutover Window
Harbor Freight Systems plans to migrate 150 VMware VMs and 25 TB to a six-node NC2 cluster on AWS. The on-premises site uses 10.10.0.0/16 and has a 200 Mbps Direct Connect with 60 ms round-trip latency; the target VPC is 10.70.0.0/16. The business allows a six-hour cutover window and requires 15-minute RPO for 40 order-processing VMs. The team proposes using Nutanix Move for all VMs, starting the initial copy at the beginning of the cutover window, then enabling Async DR after migration. They have no prior NC2 migration experience and want to avoid a second full copy. DNS TTLs are 300 seconds; some applications use hard-coded IPs. The migration must be reversible for 72 hours, and a failover test must be completed before the production cutover.
1. Evaluate the proposed migration timeline and recommend a practical Move-based approach.
Read the worked answer
The proposal cannot work. At 200 Mbps, 25 TB is about 25,000,000 MB; at 25 MB/s that is roughly 1,000,000 seconds, or about 11.6 days of pure transfer, before TCP overhead and the 60 ms round-trip latency reduce effective throughput. Starting the initial copy inside a six-hour window would move only a small fraction of the data. Start Move weeks ahead so it performs the initial copy and then incremental synchronization while the source VMs remain running. Use multiple Move appliances or parallel migration groups to use the available bandwidth, and monitor the change rate to confirm the final delta can complete inside six hours. The final cutover should be a controlled shutdown, last synchronization, and validation, not the first copy. For the 40 critical VMs, begin replication separately so the RPO target is met even before the bulk migration finishes.
2. Design the DR posture for the 40 order-processing VMs to meet a 15-minute RPO.
Read the worked answer
Async DR with an hourly schedule is not sufficient for a 15-minute RPO. Use a Nutanix replication capability that supports a 15-minute or lower RPO, such as NearSync where the AOS and Prism Central versions support it, or a protection-domain schedule that can actually run at 15-minute intervals. Create a protection domain containing the 40 VMs, replicate to the NC2 cluster over the Direct Connect, and monitor the replication lag continuously. Size the bandwidth for the change rate, not just the initial copy, and make sure the migration traffic does not starve replication. Run a failover test before the production cutover, measure actual RPO and RTO, and document the reverse replication path. Keep local snapshots for operational recovery, but do not confuse them with the cross-site DR copy.
3. What cutover, DNS, IP, and rollback checks are needed to make the migration reversible for 72 hours?
Read the worked answer
Build a per-application runbook that lists source and target IPs, DNS records, dependencies, and validation steps. The VPC CIDR does not overlap on-premises, but the target subnets are different, so hard-coded IP applications need remediation before cutover or a planned re-IP with configuration changes. Lower DNS TTLs ahead of time; 300 seconds is workable but still requires patience during rollback. At cutover, freeze changes, take a final source snapshot, stop the source VMs, run the last Move synchronization, power on targets, update DNS, and validate transactions. Keep the source VMs intact and powered off for 72 hours. For rollback, revert DNS, power the source VMs back on, and reconcile any data written on the target. Test the entire sequence in a non-production failover before the real cutover, including the DNS reversal and the application owner sign-off.