VMware-to-Private-Cloud Migration with a 10-Hour Cutover Window
An enterprise is migrating 220 VMs, using 45 TB, from three VMware clusters to a private cloud. The only link is 1 Gbps and is shared with production. The approved cutover window is 10 hours. The estate contains 60 stateless web VMs, 90 application VMs, 40 database VMs including a 4 TB Oracle database, and 30 file/print servers. Shared services include DNS, LDAP, NTP and a certificate authority. A pilot migrated 20 VMs with a warm tool: four failed to boot because the guest lacked the new virtio/NIC driver, and two had duplicate machine UUIDs. The business requires a tested rollback for each wave and cannot accept more than 30 minutes of downtime for the Oracle database. Nightly backups complete in 6 hours, but restores have never been timed.
1. Produce a wave plan and cutover sequence. Explain why the 4 TB Oracle database cannot rely on a single 10-hour window.
Read the worked answer
Wave plan: do discovery and dependency mapping first, then build target shared services rather than migrating them blindly. Deploy redundant DNS, LDAP, NTP and CA in the target and keep the source authoritative until application waves are complete. Wave 1 is non-production pilot plus the 60 stateless web VMs, because they are low-risk and can be shifted with weighted DNS or load-balancer changes. Wave 2 is the 90 application VMs in business-system batches, with each batch stopped, final-synced, started and smoke-tested. Wave 3 is file/print and databases. Do not migrate shared services last; applications need resolvable names and time synchronization at first boot.
Why Oracle cannot use one window: 4 TB is 32,000 Gb. At a theoretical 1 Gbps that is 32,000 seconds, about 8.9 hours; at 70% effective throughput it is about 12.7 hours, before conversion, validation or competing production traffic. A single 10-hour copy is therefore infeasible. Pre-seed with a full RMAN backup shipped or copied ahead of time, then apply incremental backups and archived redo during the window. The final cutover only quiesces the source, applies the last redo, opens the target and validates, keeping downtime inside 30 minutes.
Sequence per wave: freeze automation, snapshot source, final sync, switch DNS/load balancer, run smoke tests, then declare success or roll back.
2. Address the pilot boot and UUID defects, and design a rollback that the business can trust.
Read the worked answer
Boot defects: the warm tool changed the virtual NIC model, but the guest lacked virtio drivers. Install the target hypervisor guest tools and virtio/NIC drivers before migration, or standardize on a NIC model the guest already supports. Test boot each VM in an isolated target network before cutover. Do not treat a successful replication as a successful boot.
Duplicate UUIDs: cloning preserved machine identity. Generalize Windows guests with sysprep and regenerate Linux machine-id and SSH host keys. Ensure hostnames, IP addresses and monitoring identities are unique. Run a duplicate detector across the whole estate, not only the pilot.
Rollback design: keep each source VM intact and powered off or read-only for at least 72 hours after cutover. Lower DNS TTL to 60 seconds before the wave. For the Oracle database, maintain a reverse replication path or a tested restore point; a rollback that takes longer than the outage budget is not a rollback. Define objective rollback triggers: target fails to boot, error rate exceeds 5% for 10 minutes, database integrity check fails, or dependent service cannot authenticate. Time a full restore before approving the plan; a 6-hour backup job says nothing about restore time. Rehearse one application rollback end to end and record the actual elapsed time.
3. What discovery data do you need before approving the migration plan?
Read the worked answer
Approve only after collecting: application-to-VM mapping and inter-VM network flows; boot order and shared-service dependencies; OS versions, kernel modules, boot loaders and driver inventory; disk layout, used capacity and IOPS/latency profiles; database versions, replication mode, archive-log rate and backup/restore timings; IP addresses, DNS records, load-balancer rules, firewall policies and certificates; identities, service accounts and licensing; and per-application RTO/RPO and downtime tolerance. Also measure real throughput over the shared link at the intended cutover hour, not just link speed. Map each VM to a wave and a rollback method. If a dependency has no owner or no tested restore, mark it as a go/no-go blocker rather than assuming it will work.