ReferenceAdvanced5-7 min reference
Data Migration Testing
Moving data from an old system/schema to a new one is high-risk and usually one-shot — get it wrong in production and you've lost or corrupted real records. QA's job is to prove the migration is complete, correct, and reversible before cutover. This sheet is the verification checklist; for the broader data strategy see Test Data Management (linked below).
What to verify
| Check | Question | How |
|---|---|---|
| Count | Same number of rows? | COUNT(*) source vs target, per table |
| Completeness | Nothing dropped/added? | Reconcile keys; find orphans |
| Correctness | Values transformed right? | Sample + rule-based comparison |
| Integrity | FKs, uniqueness intact? | Constraint + referential checks |
| Formats | Dates, currency, encoding? | Spot-check type/format conversions |
| Dedup/merge | Duplicates handled? | Verify merge rules |
| Nulls/defaults | Missing fields filled? | Check default-value logic |
| Rollback | Can we revert? | Test the rollback path |
Reconciliation tactics
- Row counts per table as the first gate (fast, catches gross loss).
- Checksums / hashes on key columns to compare without full row diff.
- Sampling: deep-verify a representative sample + all high-value records.
- Boundary records: oldest, newest, largest, null-heavy, special characters.
When to use
Pre-cutover sign-off for migrations, re-platforming, or schema changes. Always test against a production-like dataset and volume — bugs hide in scale and real-world messiness.
Common mistakes
- Counting rows but never checking the values transformed correctly.
- Testing on tiny clean data, missing encoding/scale/edge-case failures.
- No rollback plan tested — discovering it doesn't work after cutover.
- Ignoring referential integrity (orphaned child rows).
- Trusting a one-time pass without re-running reconciliation post-cutover.
// Related resources