A cutover is the moment you turn the old system off and trust the new one. Getting there safely is less about the migration script and more about the proof you gather before you flip the switch. Here's a practical, tool-agnostic checklist for validating a migration with reconciliation — and how to make it a repeatable gate rather than a one-off scramble.
1. Decide what "correct" means before you start
Reconciliation compares two datasets, so first define the two sides and the standard they must meet. Usually that's the legacy source and the newly-migrated target, and the standard is "every value matches after known, intended transformations." Write those transformations down. If you're deliberately changing a currency's precision or normalising a timezone, that's expected — the comparison needs to know so it doesn't flag it as a break.
2. Choose a stable comparison key
Every reconciliation aligns rows on a key. Pick one that survives the migration unchanged — a natural business key is usually safer than a regenerated surrogate ID, which may not map one-to-one across systems. If keys are rebuilt during migration, build and validate the old-to-new key mapping first; a wrong key is the fastest way to get a comparison that's confidently, uselessly wrong.
3. Normalise the differences you expect
Type systems differ across engines, so decide up front how to canonicalise the columns you know will drift: trim and case-fold strings where appropriate, cast numerics to a common precision, and convert all timestamps to a single timezone before comparing. The goal is a comparison that flags only genuine data loss, not cosmetic representation differences. (For the catalogue of what silently drifts, see why row-count checks miss data loss.)
4. Reconcile at full scale, not on a sample
Sampling is fine for a quick confidence check, but a cutover deserves a full comparison. The whole point is to catch the small subset of rows that broke — and a sample is exactly what will miss them. Run the comparison across the entire dataset and expect it to return a concrete worklist: these rows, these columns, these values.
5. Triage the breaks and re-run
A clean first run is rare and slightly suspicious. Expect breaks, and treat them as a to-do list rather than a verdict. Group them by column and pattern — a single mis-mapped column produces thousands of related breaks that all resolve with one fix. Correct the migration logic, re-run, and watch the count fall. The comparison being deterministic is what makes this loop trustworthy: the same fix always produces the same, verifiable improvement.
The exit criterion is simple and strong: a full-scale reconciliation that returns zero unexplained differences. That result is the evidence you show whoever signs off the cutover.
6. Make it a CI/CD gate, not a heroic effort
The teams who cut over calmly are the ones who turned the reconciliation into a repeatable, automated check. Define the comparison as code, run it from a pipeline, and let a non-zero break count fail the build. With DataRecs, the reconciliation is a first-class resource you can manage through the CLI and a Terraform / OpenTofu provider, which means it lives in version control and can run as a required step in your migration pipeline:
- Define connections and the check once, as infrastructure-as-code, and review them like any other change.
- Trigger the reconciliation from your CI job after each migration run so every attempt is measured, not just the final one.
- Fail the pipeline on unexplained breaks, so a regression can't sneak through to cutover.
- Keep every run's report as an audit trail of exactly what was compared and when.
Run that gate on every rehearsal and it stops being a nerve-wracking event. By the time you reach the real cutover, you've proven parity dozens of times, and the switch is a formality backed by evidence.
The short version
Define correctness, pick a stable key, normalise expected drift, reconcile at full scale, triage and re-run to zero, and wire the whole thing into your pipeline. Do that and a cutover becomes what it should be: a decision backed by proof, not a leap of faith. For the underlying philosophy, see reconciliation, not guesswork.