Migrate a Workload to Another Cloud Region Safely
Relocate a workload and its data to a second cloud region with a parallel stack, replicated data, weighted DNS cutover and a rollback that keeps the old region warm.
Objective
Move a production service and its data to a new cloud region with validated latency, controlled traffic shifting and a tested way back to the original region.
Environment
- Infrastructure as code that can create the full stack in the target region
- Cross-region data replication or log shipping with monitored lag
- DNS with weighted records and a TTL of 60 seconds lowered at least one day ahead
- Baseline latency, error rate and cost metrics for the current region
- Data residency and contractual approval for the target region
Steps
1. Confirm the migration pattern
Decide between pilot light, warm standby and active-active, then map every data store and third-party dependency that must exist in the target region.
Expected state: A dependency map names each component, its target-region equivalent and its data movement method.
2. Build the parallel stack
Apply the infrastructure as code in the target region with production-sized instances and confirm health checks, secrets and network policies match the source.
Expected state: The new stack passes the same smoke tests as production and serves traffic from a synthetic check.
3. Replicate and validate data
Start continuous replication to the target, compare row counts and checksums, and record replication lag during a peak-traffic test.
Expected state: Lag stays within the recovery objective and sampled checksums match on both sides.
4. Shift traffic gradually
Route one percent, then ten percent, then one hundred percent of traffic through weighted DNS while watching latency, errors and saturation in both regions.
Expected state: The target region holds production traffic within the baseline latency and error budget.
5. Retire the source region
Keep the source stack running but scaled down for fourteen days, then delete it after a written confirmation and a final backup export.
Expected state: No traffic or replication remains in the source region and the target region owns all data.
Decision points
Should the migration use pilot light or active-active?
- Pilot light with a single writable region
- Active-active across both regions
Choose pilot light unless the availability target requires sub-minute regional failover; active-active adds conflict resolution and doubles the operational surface.
Should cutover be driven by DNS weights or a global load balancer?
- Weighted DNS records with a short TTL
- Global load balancer with health checks
Use a global load balancer when one is already in place; otherwise weighted DNS with a 60-second TTL is sufficient and reversible.
When is the source region safe to delete?
- Immediately after DNS reaches one hundred percent
- After a fourteen-day observation window
Wait fourteen days; cached DNS answers, batch jobs and forgotten integrations commonly surface after the first week.
Expected outcome
The workload serves production traffic from the target region with validated data, acceptable latency and a documented rollback window.
Verification
Query the public endpoint from several locations, confirm responses come from the new region, compare error and latency dashboards, and verify row counts against the replication report.
Cleanup
Scale down and later delete the source stack, remove temporary replication credentials and DNS weights, and archive the migration report.
Choose the pattern before moving anything
A region migration is a data movement problem with a traffic switch attached. Pilot light keeps one writable region and a warm copy elsewhere, which is enough for most services and keeps consistency simple. Active-active removes the failover window but requires conflict-free writes, global session handling and a much larger test matrix. Write the decision down before provisioning anything, because the pattern determines the replication topology.
Safety checks
Lower the DNS TTL at least 24 hours before cutover so cached answers expire quickly. Confirm the target region has quota for the production instance sizes, that secrets and certificates exist there, and that data residency rules allow the copy. Run a restore of the replicated data into a throwaway database in the target region; replication succeeding is not the same as the data being usable.
Shift traffic with weights
Route a small share first and compare latency and error budgets against the baseline. The change batch below moves ten percent of traffic to the new region; increase the weight only after a full observation period at each step.
{
"Comment": "shift 10 percent of api traffic to eu-west-1",
"Changes": [
{
"Action": "UPSERT",
"ResourceRecordSet": {
"Name": "api.example.com",
"Type": "A",
"SetIdentifier": "eu-west-1",
"Weight": 10,
"AliasTarget": {
"HostedZoneId": "ZEUWEST1",
"DNSName": "api-eu.example.com",
"EvaluateTargetHealth": true
}
}
}
]
}Rollback
Before the target accepts writes, rollback is a DNS weight change back to the source and is fully reversible. Once writes land only in the target region, rolling back requires reverse replication first, or those writes are lost. Freeze writes during the final switch, or run dual writes with conflict handling, and keep the source stack warm for fourteen days. Deleting the source stack and its backups is the irreversible step; require a named approver before it happens.