A row count check, sometimes called a record count reconciliation, is a data migration test that compares the number of rows in each table of the source database with the corresponding table in the target database. Matching counts suggest no records were lost or duplicated during the move.
Why it matters: Data migrations are high-risk projects, and lost or duplicated records may not be visible through the application straight away. A row count check is cheap to run across every table and catches large problems fast, such as a failed batch, a filter applied by mistake or a table that was skipped entirely.
In practice: Testers run a count query against each table in the legacy and destination databases, ideally using a copy of production data, and compare the results side by side. Any mismatch is investigated before further testing continues. Because a matching count does not prove the content is correct, teams follow it with deeper data validation that compares the values themselves to confirm data integrity and accuracy between source and destination.
Examples:
- A script lists row counts for every table in the old and new databases and highlights any table where the numbers differ.
- A customer table shows 120 fewer rows after migration, revealing that records with null postcodes were rejected by the target schema.
- A count that is higher in the destination exposes a migration job that ran twice for one table.
Common pitfalls:
- Treating matching row counts as proof of a successful migration, when values inside the rows may still be truncated or wrongly mapped.
- Comparing counts while the source database is still receiving new records, which produces mismatches that are not real defects.
Is a row count check enough to validate a data migration? No. It is a quick first check, but it should be followed by data-level validation that compares values, data types and mappings between source and destination.
Can row count checks be automated? Yes. A simple script or database tool can run the counts for every table and report differences, making it easy to repeat after each migration run.
