# Migration Parity Eval

Proving the new system produces equivalent results to the old one before you cut over — not after.

## Why the CCAR-P exam tests this

The exam checks whether you validate equivalence before cutover, since post-cutover is too late to discover the new path is wrong.

## Definition

A **migration parity eval** runs the old and new systems side by side and proves they produce **equivalent outcomes** on the same inputs — same results, same edge-case handling, same compliance behavior — before any traffic is moved. The non-negotiable is timing: **parity eval before cutover**.

Running the eval *after* cutover inverts the point. Once the old path is gone, a parity gap becomes a live incident with a high **reversal cost** instead of a quiet finding you can fix. Parity is what makes a **blue-green** flip or a **canary** ramp safe: the flip is only reversible-in-theory if green was proven equal to blue first.

A credible parity eval names its comparison set, its tolerance for acceptable difference, and its **measurement owner** — otherwise it risks the **"measured the wrong thing"** failure, declaring parity on a metric that was never the one that mattered.

## Exam trap

Any plan that cuts over first and validates parity afterward is the trap; equivalence must be proven while the old system is still available to compare against.

## Commonly confused with

- **canary-vs-blue-green** — Those are how you release; parity eval is the gate that must pass before either release is safe.
- **outcome-document** — Parity eval proves equivalence pre-cutover; the outcome document records verified results afterward.

## Related

- canary-vs-blue-green
- reversal-cost
- outcome-document
- poc-vs-pilot-vs-production

---

Source: Claude Cert Prep — an independent, unofficial CCAR-P study resource (domain P6). Not affiliated with Anthropic.