Validation

Ask review

Verify data integrity, functional parity, and performance

Hats
2
Review
Ask
Unit Types
Validation
Inputs
Migrate

Dependencies

Migratemigration-artifacts

Hat Sequence

1

Regression Tester

Focus: Confirm that downstream consumers and application logic produce identical results when reading from the migrated target instead of the original source. Run existing test suites, replay production queries, and compare outputs. Surface any behavioral difference, no matter how small.

Produces: Regression test results with before/after comparisons for downstream consumers and critical query paths.

Reads: Validation report from the validator, downstream consumer contracts, existing test suites.

Anti-patterns:

  • Only testing the data layer without exercising application logic on top of it
  • Ignoring performance regressions (correct but 10x slower is still a regression)
  • Assuming that passing unit tests means the integration is correct
  • Not replaying real query patterns from production logs
  • Treating "no errors in logs" as equivalent to "functionally correct"
2

Validator

Focus: Perform quantitative verification that the migrated data matches the source. Reconcile row counts, compute checksums, and run spot-check comparisons on randomly sampled records. Verify that constraints, indexes, and referential integrity hold in the target. The goal is proof, not confidence.

Produces: Validation report with reconciliation results, sample diffs, constraint verification, and discrepancy analysis.

Reads: Migration artifacts, source data for comparison, mapping specification for expected transformations.

Anti-patterns:

  • Declaring validation complete after checking only row counts
  • Sampling records non-randomly (e.g., only the first 100 rows)
  • Ignoring records that were intentionally dropped or transformed — they still need accounting
  • Treating zero errors as proof of correctness without verifying test coverage
  • Validating against the mapping spec but not against actual source data

Validation

Criteria Guidance

Good criteria examples:

  • "Row-count reconciliation shows zero discrepancy between source and target for every entity"
  • "Spot-check validation compares at least 100 randomly sampled records per entity with field-level diff"
  • "Performance benchmarks show target query latency within 10% of source for critical paths"

Bad criteria examples:

  • "Data looks correct"
  • "Validation is complete"
  • "Performance is acceptable"

Completion Signal

Validation report exists with quantitative reconciliation results (row counts, checksum comparisons, sample diffs). Functional parity tests confirm that downstream consumers produce identical results against the migrated data. Performance benchmarks are within defined thresholds.