The ticket
OS on pay-api is still supportable. Junior wants to “use the move to upgrade to Ubuntu, change the hostname, issue a new cert, and point DNS at 10.41.1.40” in one change. That is three migrations wearing a rehost badge. The replica is fine. The plan is not.
Lift = Azure Migrate (agentless or agent-based) or AWS Application Migration Service (MGN) continuous block replication, test instance, then cutover. Rebuild when the OS is out of support, the image is unclean, or the target is PaaS (App Service, ECS/Fargate). On cutover you prove one of IP / DNS / auth at a time, with a written rollback. Do not change IP and DNS and auth in the same night without that rollback.
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
| Path | Tool | pay-api |
|---|---|---|
| Lift / rehost | Azure Migrate or AWS MGN | Wave-1 — same OS, same svc-pay |
| Rebuild | Image + pipeline / App Service / ECS | When OS is rotting or you want PaaS |
| Test instance | Migrate test / MGN launch test | 10.41.1.40 or 10.51.1.40 — isolated name |
| Cutover | Planned failover / MGN cutover | After test. One variable + rollback. |
Test instance uses a test FQDN. Production DNS flips in the cutover lesson.
pay-api
How to choose
| Signal | Lift | Rebuild |
|---|---|---|
| OS in support, app is a black box | Yes — this lab | No |
| 2008 R2 / SMBv1 / no owner of the image | Only as a temporary jail | Yes |
| Target is App Service / ECS | No — that is not a VM lift | Yes — different program |
| You want a new hostname + new IdP tonight | Stop | That is three changes — sequence them |
Runbook
Side A — replicate
Azure Migrate appliance or MGN agent on
10.20.30.40. Wait until lag is boring. Do not “cut over to see.”Side B — test launch
Launch into spoke
10.41.1.40or app10.51.1.40. Test FQDNpay-api-test.techclick-lab.in. Cert SAN = that name. Do not touch the production A record.Side C — one variable
If test IP works and test name works, you have earned a cutover window. You have not earned a domain leave + new cert CN + DNS flip in the same change.
# Azure az migrate show --name pay-api --resource-group rg-migrate # replicationHealth: Healthy # AWS aws mgn describe-source-servers --filters "sourceServerIDs=s-payapi" # dataReplicationInfo.lagDuration: PT0S lifeCycle.state: READY_FOR_TEST curl -sk --resolve pay-api-test.techclick-lab.in:443:10.41.1.40 https://pay-api-test.techclick-lab.in/health # 200 · do not flip pay-api.techclick-lab.in yet
Four failures
1 · Rotting OS lift as a strategy
You just paid to host an incident. Rebuild, or rehost into a jail with a 30-day rebuild date.
2 · Test cutover using production DNS
Half the clients follow the low TTL. You are in production without a window.
3 · IP + DNS + auth same night
Three failures, one rollback story. Change one. Keep the other two stable.
4 · No rollback disk
On-prem VM powered off and deleted “to save license.” You now have a one-way door.
How to prove it
1) Replication healthy. 2) Test instance answers on a test name. 3) Cert SAN matches that name. 4) Production A record is still 10.20.30.40. 5) On-prem VM is still intact.
Traps
| Tool says | You still check |
|---|---|
| Ready for cutover | Did a human hit the test URL? |
| Test VM running | IP, name, cert — which of the three did you prove? |
| Agent healthy | Is the landing zone the target, or a dirty sub? |
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 — services overview.
- AWS Application Migration Service (MGN).
- Azure CAF — Migrate.
- AWS migration strategy — rehost vs replatform vs refactor.
Related: Azure landing zone · AWS Org / OU.