Cutover is where migrations succeed or fail. The goal is simple: switch consumers to the new world without outages, broken numbers, or weeks of confusion.

Cutover gets underestimated because it looks like “just flipping a switch.” In practice it’s reliability work: you need a clear migration path, checks you trust, and a rollback plan that is easy to execute.

Cutover patterns (choose one per wave)

1) Parallel run (old and new both serve)

Use this when business criticality is high and you need confidence before you switch.

• Run both pipelines.
• Compare outputs continuously.
• Switch consumers only after confidence is proven.

2) Shadow mode (new runs, but nobody uses it yet)

Use this when you want realistic load and validation without user impact.

• Run the new stack end-to-end.
• Validate correctness and performance.
• Promote to parallel or canary when stable.

3) Canary consumers (a small set switches first)

Use this when you need real user validation but want to limit blast radius.

• Choose friendly consumers.
• Monitor carefully.
• Scale adoption only when stable.

Testing strategy (what to test for migrations)

1) Data correctness (does it match?)