The ticket
They cut over at 02:00. Azure portal showed the VM running. Health probe 200. Finance’s batch posted to the on-prem name that still had a cached A record in one resolver, and to the new IP in another. Two writers. On-prem was already deleted “to prevent split-brain.” There is no rollback.
Cutover is a window: freeze writes, confirm Azure Migrate / MGN replica lag is zero, planned failover / cutover, flip DNS (or the route), soak with a real transaction, then release the freeze. On-prem stays read-only (or powered off but disks kept) until soak ends. Rollback = point pay-api.techclick-lab.in back to 10.20.30.40 and thaw on-prem. Success is the business POST, not the compute blade.
On-prem DC dc01 10.20.30.10 · FortiGate fgt-hq 203.0.113.10 · same Azure landing as the Azure series and same AWS landing as the AWS series. Wave-1 app pay-api today on VM 10.20.30.40.
Mental model
| Step | What moves | This lab |
|---|---|---|
| Freeze | Writes stop on on-prem | App maintenance flag / DB read-only |
| Replica | Final sync | Migrate / MGN lag PT0S |
| Flip | Name or route | A record 10.20.30.40 → 10.41.1.40 or 10.51.1.40 |
| Soak | Real traffic, one writer | POST /v1/pay from a known client |
| Rollback | Name or route back | A record back, thaw on-prem, cloud NIC isolated |
Delete on-prem only after soak, not as a step in the flip.
Planned failover
How to choose
Flip DNS when clients already use pay-api.techclick-lab.in (this lab). Flip a route only if you kept the same IP — we did not. Do not do both. Lower TTL at least a day before the window. If the app is IP-literal in a config, that is a pre-req, not a surprise at 02:00.
Runbook
Side A — freeze + final sync
Maintenance page / DB read-only on on-prem. Azure Migrate planned failover or MGN cutover. Confirm no writers. Snapshot on-prem disks.
Side B — flip one thing
Change the A record on
dc01(and Private DNS / Route 53 if they also answer). Flush a known resolver. Do not also change the cert CN or leave the domain in this window.Side C — soak then decide
Known client runs POST /v1/pay. Sentinel / Security Hub shows the hit on the cloud IP. Watch for leftover hits on
10.20.30.40— that is a resolver you missed. Only then lift read-only. If soak fails: A record back, thaw on-prem, isolate the cloud NIC.
# before
nslookup pay-api.techclick-lab.in 10.20.30.10
# 10.20.30.40
# after flip
nslookup pay-api.techclick-lab.in 10.20.30.10
# 10.41.1.40
curl -sk -X POST https://pay-api.techclick-lab.in/v1/pay -d '{"ref":"lab-soak-1"}'
# 200 · id=… ← this is success, not `az vm get-instance-view`
# leftover writer?
# FAZ / Sentinel still seeing 10.20.30.40:443 POSTs → you missed a cache / a literal IPFour failures
1 · VM running = done
Compute health is not a payment. Close on the transaction.
2 · Two writers
DNS split-brain or on-prem still accepting posts. Corruption. Freeze first.
3 · Delete on-prem in the flip
You removed the rollback. Read-only until soak ends — hours to days, not five minutes of /health.
4 · Flip plus rebuild
New OS, new cert, new IdP, new IP. You cannot tell which change failed. That was lesson 5.
How to prove it
1) One writer. 2) POST /v1/pay succeeds against the name. 3) Logs show the cloud IP. 4) On-prem still exists and is read-only. 5) Rollback command is tested (or written so a tired human can run it).
Traps
| Looks green | Still broken |
|---|---|
| /health 200 | POST /v1/pay still talks to on-prem SQL the wrong way — or not at all |
| Your laptop resolves new | Batch server TTL is 86400 |
| Cloud VM running | On-prem still writable |
Knowledge check
Judgment items. One best answer. Reasons send you back to the matching section.
On-prem to cloud migration class series: 6 Rs · Landing zone first · Identity first · VPN / ER / DX · Lift vs rebuild · Map controls · Cutover + rollback · Hybrid interview
Sources
- Azure Migrate — test migration and planned failover.
- AWS MGN — test and cutover lifecycle.
- Azure CAF Migrate — cutover practices.
- AWS migration strategy.
Related: Azure landing zone · AWS Org / OU.