Migration Parity Needs Evidence, Not Stakeholder Memory

The pricing rule was either a migration defect or a legacy bug, depending on who was speaking. The room had senior stakeholders, strong opinions, and no reproducible input pack.

An automotive modernization program rebuilt dealer pricing. A franchise manager rejected cutover because incentives differed for a regional promotion. Engineering claimed the new service matched the documented rule. The legacy system had a buried exception for one dealer group. A parity pack resolved the dispute: same input vehicles, same dealer context, same promotion dates, old output, new output, side effects, and explanation. The diff showed one true migration gap and one legacy bug the business chose not to preserve.

Teams assume UAT will settle parity. Users click through migrated screens, approve enough paths, and the cutover proceeds. That breaks when legacy behavior was never fully documented and different stakeholders remember different exceptions.

A parity pack should include representative inputs, expected outputs, side effects, report impact, tolerances, owner sign-off, and known differences. It should be versioned and rerunnable. Frontend parity is not enough; APIs, batch jobs, exports, and downstream reports need comparison too. For high-risk domains, run shadow comparisons before traffic moves and track drift by business segment.

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.

Meeting parity:
Stakeholder memory --> debate --> executive preference

Evidence parity:
Input pack --> legacy run
           --> modern run
           --> diff report --> domain sign-off --> cutover decision

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.

Full parity is not always desirable because legacy may encode bad behavior. The alternative is explicit non-parity: list behavior that will change, who approved it, and what customer or operational communication is required. For low-risk UI refreshes, sampled parity may be enough. For pricing, balances, claims, or inventory, parity evidence should be much stronger.

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.

Parity packs should include the ugly tail, not only happy-path transactions. Sample manually corrected orders, inactive product codes, regional exceptions, and records created before the current schema existed. Stakeholders remember recent demos; parity evidence should survive those memories. When old and new outputs differ, the packet should say whether the difference is tolerated, fixed, or a release blocker.

Sign-off should require the parity packet, not the loudest stakeholder in the room.

Parity evidence should show tolerated differences explicitly so rollback decisions do not reopen old arguments under pressure. Keep the packet beside the wave plan, not in a slide appendix.

Parity is not nostalgia. It is a controlled decision about what must match, what may change, and what evidence lets the old path retire.