Cloud migration cutovers
A cloud cutover needs one clear writer
Moving traffic is only part of a migration. Decide where new business changes are accepted and how that authority moves without creating conflicting histories.
In this article
Routing and ownership are different decisions
A new cloud application can receive most web traffic while an old scheduler still writes to the original database. If both environments accept independent changes, the migration now has two histories to reconcile.
Start with every source of writes. Include queues, partner callbacks, batch imports, administrator tools and scheduled tasks. A maintenance page protects the browser path but does not stop those other actors.
For each business dataset, identify the authoritative writer before, during and after the switch. A phased migration can have different owners for different domains, but that boundary must be explicit.
Decide how the final changes arrive
A bulk copy provides a starting dataset. Ongoing change capture can reduce the remaining gap, but it is not an instantaneous guarantee. AWS DMS, for example, documents that CDC latency varies with workload and system conditions.
Plan how to stop or fence old writes, establish a final source checkpoint and prove the target has applied the required changes. A dashboard showing low average lag does not by itself establish that every required transaction reached the destination.
- Source owns writesCopy history while recording subsequent changes
- Fence and drainStop old writers and identify final committed work
- Verify targetApply the checkpoint and reconcile business records
- Target owns writesEnable new work and monitor the complete workflow
Define the point where rollback changes
Before the target accepts new writes, reverting routing may be relatively simple if the source remains intact. After the target accepts changes, returning users to the old source can lose or contradict those changes.
Choose the recovery approach in advance. Options may include a tested reverse data path, reconciliation under a write pause or fixing the target while it remains authoritative. The suitable choice depends on the data and the acceptable interruption.
Do not label a DNS change as a complete rollback plan. It moves requests, not the business history created at the destination.
Keep phased migration boundaries coherent
Moving one capability at a time can reduce scope when requests and data ownership can be separated. A routing facade may help direct operations during that transition.
However, a transaction that spans old and new domains needs an explicit consistency model. Splitting its endpoints without addressing the shared write decision can make the migration harder to reason about.
Prove a business workflow before reopening
Validate authentication, reads, writes, file access and an important integration from the real user path. Check the resulting records and downstream effects.
Set a time-bound decision checkpoint with a named owner and measurable conditions. The cutover is ready when the team can explain which system owns the next write and what happens if the next check fails. Green infrastructure status is useful evidence, but it is not the same as a working business service.
Primary sources
AWS DMS: ongoing replicationMicrosoft: Strangler Fig patternReferences checked 11 September 2026.