Database Migration Validation: Check More Than Row Counts

Compare the Same Snapshot

Choose a source snapshot and record when it was taken. If people continue editing while you compare, decide how those changes will be handled. A difference caused by a later legitimate edit should not be mixed with an importer error. Use a separate rehearsal destination and synthetic or otherwise authorized data.

Define acceptance before inspecting results. The sample worksheet below uses zero unresolved identity and relationship exceptions as a proposed release gate. That is an editorial policy for this hypothetical workflow, not an industry standard or a measured product guarantee.

Reconcile the Identifier Sets

Compare the set of source IDs with the preserved source-ID field in the destination. Classify a source-only ID as missing, a destination-only ID as unexpected and a repeated ID as a duplicate requiring investigation. Do not rely on row order or newly assigned internal IDs.

A count of 100 on each side can hide one missing record and one accidental duplicate. The identifier reconciliation exposes that problem. Once identities agree, compare selected business fields after applying the conversion rules in your field map.

Documentation: PostgreSQL: constraints and relational integrity

Check Relationships and Calculations Separately

For each relationship, confirm that the linked record resolves to the intended source identity. A link to a customer with a similar display name is not sufficient. Then test any behavior reconstructed during migration, such as formulas, rollups, permissions and automation triggers.

Baserow’s importer documentation recommends reviewing its import report and checking records after transfer. Use that vendor report as one input, not as a replacement for acceptance checks tailored to your business. A report can explain a known limitation while the workflow still needs a manual repair.

Documentation: Baserow: Airtable import and compatibility

Keep an Exception Ledger

Log the record ID, field, source value, converted value, suspected cause and decision for every exception. Keep sensitive values out of public support requests. When a repair changes the conversion rule, rerun the affected checks for the full relevant dataset rather than fixing only the first example you noticed.

Sample testing is valuable for interface behavior, but label its scope. Five files opening correctly does not prove that all attachments transferred. A complete attachment inventory or a stronger full check is needed when every file must be retained.

1. Reconcile table and record identities.
2. Compare field values using the written conversion rules.
3. Check every essential relationship for an unresolved target.
4. Recompute important calculations and compare agreed outputs.
5. Exercise each required role and a representative end-to-end workflow.
6. Resolve or explicitly accept each exception before deciding on cutover.

Separate Import Success From Release Acceptance

The import finishes when the tool completes its task. The release is accepted when the workflow owner has evidence that the destination meets the contract. Keep these as separate events in your notes.

If a required relationship or permission fails, hold cutover and retain the original. If the only remaining differences are approved formatting changes, record that decision and its owner. The goal is a defensible transition, not a report with no visible warnings.

An Illustrative Reconciliation Ledger

This is an illustrative worksheet to adapt to your own evaluation. It is not a measured product test or a claim about results in your installation.

Use a completed exception ledger and workflow checks to make the cutover decision. The destination should meet the agreed contract, not merely contain the expected number of rows.