Migration Cutover for a 40 TB File Server
A logistics company is migrating 120 AHV VMs, including a 40 TB Windows file server, from an on-premises cluster to a six-node NC2 cluster in Azure West Europe. The sites are connected by a 1 Gbps ExpressRoute with 18 ms latency. The business allows a six-hour cutover window per application, with an RPO of 15 minutes and an RTO of four hours. The team plans to use Nutanix Move. During the pilot, initial replication of the file server ran for 30 hours and still had not completed; smaller VMs replicated in under two hours. The network team can temporarily raise ExpressRoute bandwidth but cannot exceed 2 Gbps. The company wants to avoid a second full copy and must prove rollback before cutting over.
1. Recommend a migration approach for the 120 VMs and the 40 TB file server. Should they use Move replication, offline seeding, or a phased approach? Explain.
Read the worked answer
Treat the 120 VMs as batches and the 40 TB file server as a special case. At 1 Gbps, 40 TB is roughly 89 hours of theoretical transfer; at 2 Gbps it is still about 44 hours, so a six-hour window cannot include the initial copy. Use Move for the smaller VMs in waves, with final sync and cutover per wave. For the file server, perform a pre-seed outside the window using a temporary 2 Gbps ExpressRoute, an offline transfer, or a supported seed method, then use Move or a delta sync for final changes. Do not start a second full copy. Keep the source running and unchanged until the final delta is captured, and maintain a rollback path with DNS and share configuration ready. Schedule the file server last, after the migration process is proven.
2. Design the cutover runbook for the file server, including validation and rollback.
Read the worked answer
Before the window, confirm target capacity, network, DNS, ACLs, and a tested backup. Freeze writes on the source file server; record share and ACL state; run the final delta sync; verify delta size and error count. Stop the source service or disable shares, run one last sync, then power on the target and validate SMB shares, NTFS permissions, DFS namespaces, and client access from each subnet. Update DNS/DFS to the target, monitor for 60 minutes, and keep the source intact but offline for rollback. Rollback criteria: failed ACL validation, missing data, or authentication errors that cannot be fixed within the window. Rollback means reverting DNS/DFS and re-enabling the source, then reconciling any writes made on the target. Document RPO/RTO evidence.
3. After migration, what DR pattern should they use between on-premises and Azure, and how would they test it?
Read the worked answer
After migration, use Nutanix native replication from the on-premises cluster to NC2 or between NC2 clusters, with protection domains and schedules that meet a 15-minute RPO for tier-1 workloads. Do not replicate all 40 TB at the same frequency; tier the file server with a longer RPO if the business agrees. For a four-hour RTO, pre-stage network, DNS, and recovery runbooks, and keep a warm standby for critical VMs. Test quarterly in an isolated VNet or with a recovery cluster that does not conflict with production IPs. Validate actual RPO by checking snapshot times and replication lag, and validate RTO by timing power-on, DNS cutover, and application checks. Document dependencies and rollback.