Set the conditions — QA pass rate, p95 latency and whether the final delta sync succeeded are the inputs the Saturday 09:30 go/no-go gate evaluates.
🚀 Trigger Migration Weekend — POST api/cutover. The backend walks the 11-step runbook: each step is marked done, failed, no-go or skipped. If gates pass, 250 servers move replicating → cutover → validated in the fleet state. If not, a rollback is recorded and no fleet state changes.
Force go overrides a red QA gate — the backend marks it forced-go ⚠️ and lets you see the consequence.
Traffic animation moves the user packets from the legacy data centre to the cloud only on SUCCESS; on ROLLBACK it bounces back.
Role tabs highlight only that role's steps in the runbook.
Gate rule: QA ≥ 98%, p95 ≤ 300 ms, delta sync OK.
All rolesPMApp OwnersDevelopersOpsQANetwork OpsBusiness
Outcome appears here.
Traffic & runbook
Userswww
➜
DNS GTMCNAME switch
➜
Legacy DCold VIP
➜
Cloud LBnew target
➜
Cloud DBdelta synced
Click a node to learn what it does.
Deep dive
How
Developers: pipelines target cloud; connection strings swap physical IPs for DNS names (db.prod.cloud.internal).
Ops: terraform apply landing zone; confirm final MGN/Azure Migrate delta.
Sequencing prevents the classic failure: DNS flipped before data is consistent.
Named gates make rollback a planned decision owned by one person.
When
Low-traffic window agreed with the business (here Fri 20:00 → Sun 12:00).
After a dress rehearsal at T-1 week.
Pitfalls
Long DNS TTLs (hours) make rollback slow — lower them a week before.
Hard-coded IPs hidden in config files, cron jobs and firewall rules.
Skipping the load test: it works for one user and dies at 9 AM Monday.
Key ideas
Rollback is a decision point, not a failure
The runbook has two gates: Friday 18:00 (CAB approval and rollback owners named) and Saturday 09:30 (QA sign-off). Either can stop the weekend cheaply.
Business sign-off
Technical green is not enough. Sunday 12:00 a business owner confirms orders, reports and payments work — that is when hypercare begins.