Four-week migration with a six-hour cutover
A retailer runs 80 VMware VMs and a 2 TB MySQL 8.0 database in an IDC. The target is NCP. A 200 Mbps VPN is available now; a dedicated line can be installed in eight weeks, but the business wants migration in four. The cutover window is six hours on Sunday. The database grows 20 GB/day. The application has 300 batch jobs, including a 90-minute nightly settlement. File shares total 12 TB. The current backup is weekly full plus daily incremental. The DBA requires a tested rollback. The CTO wants a cost estimate and monitoring plan. The network team can raise the VPN to 400 Mbps only after the cutover. The IDC has 1 Gbps internet, but all traffic must use private connectivity. The database must stay online during migration except during cutover.
1. Choose connectivity and transfer methods for the 12 TB of file shares and the 2 TB database seed. Show the arithmetic and explain why the dedicated line is not on the critical path.
Read the worked answer
- File shares: 12 TB is 96 Tb. At 200 Mbps the theoretical time is 96,000 Gb divided by 0.2 Gbps, or 480,000 seconds, about 5.6 days. At 60% efficiency it is about 9 days, before competing with VM replication or database traffic. Use a bulk transfer appliance for the initial 12 TB, then synchronize deltas over the VPN.
- Database seed: 2 TB is 16 Tb. At 200 Mbps the theoretical time is 80,000 seconds, about 22 hours; at 60% efficiency, more than 36 hours. That cannot fit in a six-hour cutover. Seed from a backup or bulk transfer days before, restore to Cloud DB for MySQL, and start replication.
- Ongoing replication: 20 GB/day is about 1.9 Mbps average. The VPN can carry that alongside normal delta traffic. The 2 TB seed, not the daily growth, is the problem.
- The dedicated line arrives in eight weeks, after the four-week deadline. It is useful for post-cutover stability, but it cannot be the plan of record for cutover. Design for the 200 Mbps VPN plus bulk transfer, and treat the dedicated line as a later improvement.
- All traffic stays on private connectivity; do not use the 1 Gbps internet path as a shortcut.
2. Build the six-hour cutover runbook and rollback plan. What are the go/no-go checks?
Read the worked answer
- Before cutover: lower DNS TTL to 60 seconds, complete the bulk file transfer and checksum, restore the 2 TB seed, confirm replication lag is under five seconds, and run a full application smoke test against a staging copy.
- T-0: freeze writes at the IDC application, stop the 300 batch jobs, and record the binlog position. Apply the final binlog to Cloud DB for MySQL. Validate row counts and checksums on critical tables.
- T+1h: start the cloud application, run smoke tests for login, checkout, and the settlement job in dry-run mode. If checks pass, switch DNS. Keep the IDC read-only and reachable.
- Rollback: if validation fails, point DNS back to the IDC, restart IDC writes, and reverse replication from cloud to IDC if any cloud writes occurred. The reverse path must be tested before cutover; otherwise rollback loses data written in the cloud.
- Go/no-go checks: replication lag under five seconds, checksum match, settlement dry run under 15 minutes, monitoring green, on-call staffed, and at least two hours of the six-hour window remaining. If any check fails, roll back rather than extend into Monday.
3. What must the cost estimate include, and which monitoring and billing controls do you put in place for the first 30 days?
Read the worked answer
- Cost estimate: 80 Server instances right-sized after discovery, Block Storage for OS and data, Cloud DB for MySQL primary and standby plus backup storage, Object Storage for the 12 TB file shares and logs, VPN or dedicated line, bulk transfer appliance, load balancers, and egress. Include the 300 batch jobs if they need separate compute.
- Do not price 80 VMs at current IDC specs without discovery. Many VMware VMs are overprovisioned; measure CPU and memory for two weeks and map to smaller NCP types. Include a contingency for the settlement job's peak memory.
- Monitoring: Cloud Insight dashboards for CPU, memory, disk, network, DB connections, replication lag, and batch job duration. Alarm on settlement job failure and on replication lag above five seconds. Use Cloud Activity Tracer for change audit during cutover.
- Billing controls: tag every resource by environment and owner, set budget alarms at 80% and 100%, and review cost daily for the first two weeks. Stop temporary migration servers and the bulk appliance after verification.
- Report actual versus estimate at day 30, with the largest variances explained. The dedicated line, if ordered later, should be a separate forecast line, not hidden in the migration budget.