# 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.

By Cobnex editorial. Published 2026-09-10. Updated 2026-09-11.

## 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.

## Sources

- [AWS: performing cutover tasks](https://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-migration-playbook/task-three-cutover-tasks.html)