Migration Cutover, Validation, and Post-Migration Operations
What this domain tests
The execution discipline after planning: runbooks, freeze windows, rehearsal, validation criteria, rollback triggers, and the operational setup that keeps migrated workloads healthy and cost-controlled.
Core rules and concepts
- A runbook lists each step with an owner, duration, expected result, and a rollback action. Untested runbooks fail in the window.
- Pre-cutover: lower DNS TTLs (for example 300s to 60s) at least two TTL periods ahead, freeze changes, refresh backups, confirm the rollback image or snapshot exists, and rehearse end to end.
- Validation has four layers: functional smoke tests, data reconciliation (row counts, checksums, SCN), performance comparison against baseline, and security posture (Cloud Guard findings, no public buckets).
- Define rollback triggers numerically before the window, such as error rate above 2% for 15 minutes.
- Post-migration: right-size from Monitoring metrics, enable Logging, APM, and Operations Insights, patch via OS Management, configure backups and Full Stack Disaster Recovery, then decommission the source only after the agreed retention period.
Worked example
Cutover for 20 app VMs and one database. At T-48h lower TTL and freeze changes. At T-0 stop the application, perform the ZDM switchover to Exadata Database Service, start the app tier, run 30 smoke tests, compare row counts per critical table, switch DNS, and watch error rate and latency for two hours. If error rate exceeds 2% for 15 minutes, revert DNS and restart the source - a decision made before the window, not during it.
Traps that cost marks
- Cutting over with a high DNS TTL and waiting hours for propagation.
- No numeric rollback criteria, so the team debates while users are down.
- Decommissioning the source immediately and losing the fallback.
- Declaring success without data reconciliation.
- Leaving oversize shapes running after go-live and blowing the budget.