Sequencing is the difference between a controlled delivery program and a multi-year migration that never finishes. The point is simple: reduce risk and protect business continuity, without moving so slowly that everyone loses momentum.

Most migrations don’t fail because the tech is impossible. They fail because the order is wrong. Teams start with the biggest, most tangled thing, discover hidden dependencies, and end up running “old + new” for years.

The sequencing model (how to design waves)

When you’re choosing what goes first, use three inputs.

1. Business criticality (what hurts most if it breaks)
2. Dependency graph (what depends on what)
3. Change surface area (how many teams and systems must coordinate)

A good wave is small enough to control, but big enough to prove a repeatable pattern.

A practical wave design checklist

1) Define the wave

Be specific. Ambiguous scope is how you accidentally create a big-bang migration.

• What is the scope (domains, products, pipelines, consumers)?
• What is explicitly out of scope?
• What is the “definition of done” (including decommissioning or at least a decommission plan)?

2) Protect continuity

Pick one continuity strategy and commit to it.

• Decide the continuity strategy:
  • Parallel run (old and new in parallel)
  • Shadow mode (new runs but is not used for decisions)
  • Canary consumers (a small set of consumers switch first)
• Define rollback criteria and who can trigger rollback.

3) Prove correctness

Don’t leave “it looks right” as your validation plan.