Migration Wave Boundaries Matter More Than Cutover Weekends

At 2 a.m., the team knew traffic had to stop. What they did not know was who had authority to stop it, which jobs had already run, and whether rollback would corrupt the records already written by the new path.

A manufacturing migration moved a plant scheduling module. The official wave included the scheduler UI and API. It omitted a supplier EDI job, a label printer dependency, and a spreadsheet macro used by planners during exceptions. During cutover, the new scheduler worked but labels drifted. Rollback would have restored UI traffic while leaving new reservation writes in place. The next wave required a boundary diagram, bridge RACI, stop conditions, and a rollback rehearsal on a subset of lines.

Teams treat cutover weekend as the main event. They prepare bridge calls, dashboards, and a rollback slide. The real risk was created weeks earlier when wave scope hid shadow integrations, batch jobs, support tools, and unclear decision authority.

A wave boundary should define included entities, excluded entities, writer ownership, integration touchpoints, batch jobs, support workflows, data migration windows, monitoring, stop conditions, and rollback behavior. Rehearsal should use production-shaped data and timing. The bridge should have named authority: who can pause traffic, who can accept known drift, who can declare rollback, and who communicates to operations.

For migration wave evidence, the release review should inspect evidence, not optimism. Every wave needs a boundary diagram, writer table, integration list, rollback authority, parity pack, and retirement condition. If a hidden batch job, support screen, vendor feed, or manual SQL path can still mutate the wave entity, the boundary is not honest.

Parity evidence should be reproducible and readable by domain owners. Compare business outcomes, not only API responses. In automotive, that may mean pricing, allocations, incentives, and dealer exceptions. In healthcare, it may mean authorization status, audit history, and eligibility. In manufacturing, it may mean lot traceability, lead time, and reservation behavior.

The dangerous milestone is traffic shifted without authority transferred. A wave is not done because a route moved. It is done when the old writer is disabled, drift is monitored, and the old path has a retirement date tied to evidence.

Fictional wave:
UI + API listed
Hidden: batch job, label printer, support macro, vendor feed

Real wave boundary:
Entities + writers + jobs + integrations + cohorts + rollback authority + evidence

The honest tradeoff is migration momentum versus coexistence clarity. Larger waves look efficient until rollback, ownership, or parity becomes unclear. Smaller boundaries create more coordination work, but they also make it possible to prove which facts moved, which facts stayed, and which old paths must stop writing.

Failure tests should include stale reads after cutover, replayed events, rollback after ownership moves, hidden batch writers, manual overrides, duplicate messages, CDC lag, tombstones, schema drift, and cohort routing mistakes. The ugly tail matters: old product codes, inactive customers, manually corrected orders, regional exceptions, and records created before current rules existed.

A useful modernization artifact should show the wave boundary, writer ownership, read paths, excluded integrations, parity cases, tolerated differences, rollback owner, and retirement condition. The point is not to document progress. The point is to make coexistence visible enough that a cutover decision can be challenged before the weekend starts.

Small cohort cutovers reduce blast radius but create support complexity. Big-bang cutovers reduce coexistence time but concentrate failure. Parallel run can build confidence but may hide writer ambiguity. The right answer depends on whether the team can explain and rehearse the boundary under failure.

A weak review asks whether the new service is built. A useful review asks whether ownership, parity, and rollback can survive coexistence. The reviewer should inspect the mutation graph, not only the service diagram. Commands, field groups, lifecycle states, cohorts, and append-only records may have different ownership rules. A single entity-level writer table is a starting point, not the final model.

Reliable event publishing also matters. If the wave uses events, ask for the outbox or inbox pattern, idempotency keys, duplicate delivery handling, replay windows, and dead-letter ownership. Exactly-once delivery should be treated with skepticism. Most real systems need at-least-once delivery plus idempotent consumers and clear reconciliation.

Cutover mechanics should be rehearsed. Shadow reads, shadow writes, dark launches, cohort routing, freeze windows, and rollback ownership each carry different risk. The review should ask what happens if CDC lags, tombstones are missed, schema mappings drift, or a backfill replays old events after traffic moves. That level of detail is what separates a migration plan from a cutover wish.

Leadership should watch coexistence signals: parity diffs, hidden writer discoveries, rollback rehearsal outcomes, CDC lag, exception queue age, and retirement tickets closed. Those signals show whether migration risk is shrinking or merely moving from code into operations.

The useful artifact is a migration evidence pack. It should include the wave boundary, write ownership, included integrations, excluded integrations, golden transactions, legacy output, modern output, tolerated differences, rollback owner, and sign-off history. A status slide is not evidence.

The evidence pack should separate legacy bugs from migration gaps. Otherwise every parity dispute becomes political, and the program preserves bad behavior because nobody can prove what changed.

Use this decision threshold: if rollback, writer ownership, and parity evidence cannot be explained from the same packet, the wave is not ready for cutover.

Write this note before cutover: what traffic moves, what writer changes, what data freezes, who can stop the bridge, and which comparison proves the new path did not merely look correct.

A practical review should include one golden transaction from the wave. Show legacy input, modern input, legacy output, modern output, tolerated differences, write owner, read consumers, rollback owner, and the old path that must be disabled. Without that example, parity remains a meeting opinion.

The useful review example is one business fact moving through old and new paths at the same time. Follow who can write it, who can read it, what happens when sync pauses, and how rollback behaves after ownership moves. That single fact often exposes hidden jobs, admin screens, vendor feeds, and reports that the migration plan forgot.

Wave boundaries should be small enough that rollback, writer ownership, and parity evidence fit in one review packet. Large waves hide hidden writers such as batch jobs, admin SQL, vendor feeds, and support screens. The boundary diagram should show not only services but every path that can mutate entities in scope, including jobs that run twice a year.

Cutover weekend success depends on wave scope chosen months earlier.

A wave that cannot be explained in one evidence packet is too large to cut over safely. Smaller waves cost coordination; oversized waves cost rollback.

Cutover weekend should execute decisions already proven. If the bridge is discovering wave boundaries live, the program is gambling with operations.