Cloud migration cutovers
Rehearse rollback after the target accepts a write
The difficult recovery case begins when the new environment contains data the old one does not. Test that boundary explicitly.
In this article
Create a distinguishable transaction
In a safe rehearsal environment, complete the migration switch and create a synthetic business record through the target application. Give it an identity that can be traced across every relevant store and integration.
Confirm that the transaction really committed. A request returning success is insufficient if background processing still determines the final state.
Then introduce the failure that triggers the planned rollback or recovery path. Use a controlled fault rather than changing unrelated components at random.
Follow the documented recovery choice
If the plan returns authority to the source, show how the target-only change reaches that source without duplication or loss. Include related records and external effects, not only the main row.
If the plan keeps the target authoritative and repairs forward, verify how users are protected while the fault is resolved. The interruption and communication model should match that choice.
A procedure that simply routes requests back and leaves the synthetic transaction behind has failed the exercise, even if the old application loads normally.
Add an ambiguous operation
Repeat with a request whose response is lost after commit. The operator must determine whether it completed before deciding to retry or move data.
Also include queued work accepted before the switch but executed afterwards. Confirm which environment owns it and how its operation identity survives the transition.
These cases reveal whether the recovery process follows business operations or only infrastructure resources. A restored server cannot explain an untracked payment or duplicated dispatch.
Reconcile through the user workflow
After recovery, find the synthetic record through the normal application and complete its next step. Compare totals and related state with the expected result.
Record elapsed time for fencing, data recovery, verification and reopening. A single rollback duration can hide the phase that exceeds the available window.
Update the cutover decision point using the measured result. If recovery after new writes is too slow or uncertain, change the release strategy before production. The rehearsal should produce a usable boundary for the operator, not a ceremonial successful rollback label.
Primary sources
AWS: pre-cutover planningReferences checked 11 September 2026.