← Lessons

quiz vs the machine

Gold1420

Databases

Data Validation Post Migration

Proving the new database matches the old one before trusting it.

5 min read · core · beat Gold to climb

Trust But Verify

After moving data, you must prove the target actually matches the source before depending on it. Post migration validation compares the two systems to catch dropped rows, mangled values, or type conversion errors.

Layers Of Checks

  • Row counts per table: a fast sanity check that nothing was lost wholesale.
  • Checksums or hashes over rows: detect subtle value differences that counts miss.
  • Spot comparisons of sampled records side by side for human inspection.
  • Aggregate checks like sums of key numeric columns to catch type or rounding errors.

Counts alone are weak because a row could be present but corrupted, so checksums add the value level assurance.

Handling A Moving Source

If the source is still live during validation, it keeps changing. Validate as of a consistent point, using a snapshot or a quiet window, so you compare the same logical state on both sides rather than chasing a moving target.

Key idea

Post migration validation layers row counts, checksums, sampled spot checks, and aggregates against a consistent snapshot, proving the target matches the source before you trust it.

Check yourself

Answer to earn rating on the learn ladder.

1. Why are row counts alone insufficient validation?

2. How do you validate against a still changing source?