Cloud migration cutovers
Prove the workflow after the traffic switch
Healthy instances and low error rates do not show that customers can finish their work. Define cutover checks around complete business outcomes.
In this article
Choose a small set of essential journeys
Select workflows that exercise the service's important dependencies. For a field-service application, this might include signing in, opening a job, saving a change, uploading a photo and making that update available to the office team.
Use synthetic records that can be identified and cleaned up safely. Avoid tests that send real customer messages or create financial obligations unless they are part of a separately controlled process.
Record the expected result at each destination. A successful upload response is incomplete evidence if the office user cannot retrieve the file.
Compare against a known baseline
Measure the same journeys before the cutover so the team can distinguish an existing issue from a migration regression.
Track completion time, failed steps and correctness of stored results. Infrastructure metrics remain useful for diagnosis, but the acceptance condition should reflect the user's task.
Include identity, permissions and integration callbacks. These often depend on configuration outside the migrated application code.
Reconcile data at the boundary
Define the source checkpoint and the target evidence used to confirm it. Supplement replication metrics with business checks suited to the dataset.
Counts can identify missing groups, while selected record comparisons can reveal incorrect transformations. Totals may help where quantities should be preserved. None of these alone proves every property, so choose a combination that covers the migration's specific risks.
Keep unresolved discrepancies explicit. A small percentage can still contain the one active order a team needs immediately.
Make the decision actionable
Set conditions for proceeding, pausing and entering recovery before the window begins. Include the remaining time needed for the chosen recovery path.
A decision that is postponed until the window has nearly ended may remove the practical option to recover safely. Show the latest decision time alongside current evidence.
Continue checks through the agreed observation period, including scheduled work that does not run immediately. The cutover is accepted when the target supports the required workflows and data ownership is clear, not when a traffic graph first shows requests arriving at the new address.
Primary sources
AWS: performing cutover tasksReferences checked 11 September 2026.