Database Migration Validation: Beyond Row Counts

Introduction

On migration day, the most common sign-off check is also the weakest: the row counts match, so we are good. They are not the same thing. Matching counts only tells you that the same number of rows landed on the other side — it tells you nothing about whether the values inside those rows survived the move intact. A column can be quietly truncated, a decimal can lose precision, an accented character can be re-encoded, a null can become an empty string, and your counts stay perfectly equal the whole time. Real database migration validation has to compare the data itself, not just tally it. This article explains why row counts mislead, sets out a simple hash-based method to prove source and target are identical, and shows how e-Dex (formerly Hash Calculator) turns that comparison into a signed integrity certificate on your own machine.

Why Row Counts Mislead

A row count is a single number, and a single number cannot describe the contents of millions of cells. Migrations routinely break data in ways counts will never notice. Truncation happens when a target column is narrower than the source, silently clipping long names or notes. Precision loss turns a financial figure with four decimals into two. Encoding drift garbles non-ASCII characters when character sets differ between systems. Null handling varies — one platform stores an empty string, another a true null — and the count is identical either way. Date and time-zone shifts move timestamps by hours. Every one of these is a real data defect, and every one of them passes a row-count check. The lesson is blunt: counting rows verifies quantity, never content.

A Hash-Based Validation Approach

A cryptographic hash is a fixed-length fingerprint computed over a file's exact bytes — change one byte and the fingerprint changes completely. That property gives you a precise, content-level comparison. The method is straightforward. First, export each source table (or the whole source dump) to a file using a fixed column order and a deterministic sort. Then export the matching target table the same way, with the identical query and ordering, so the two files are directly comparable. Next, hash both export files with e-Dex using a modern algorithm such as SHA-256 or SHA-512. Finally, compare the hashes table by table. If the source and target hashes are equal, the exports are bit-for-bit identical and that table migrated cleanly; if they differ, something inside that table changed and needs investigating. The comparison is exact, fast, and independent of any database platform.

Spotting Changed or Missing Data Before Go-Live

The real value of hashing shows up in the window before cut-over, when problems are still cheap to fix. Because a mismatch points at a specific table, you can narrow down to exactly where the data drifted instead of trawling the whole schema. A MISMATCH on a customer table sends you to look for a truncated address; a MISMATCH on a ledger sends you to check decimal precision. Hashing the exports turns a vague "something feels off" into a short, ranked list of tables that demonstrably changed. Catching a clipped column or a re-encoded field before go-live is the difference between a five-minute export tweak and a post-migration data-correction project with the business already live on the new system.

Producing a Database-Migration Integrity Certificate

Once the comparison is clean, you want something durable to show for it. e-Dex generates a database-migration integrity certificate: a one-page, readable document that records the source and target hashes for each table and prints an explicit MATCH or MISMATCH verdict, with an overall result across the whole set above the per-table rows. It converts a verbal assurance into auditable sign-off evidence — proof that the migrated data is identical to the source, attached to your go-live approval, your audit file or your regulatory record. This is the same integrity logic described in our guide to the database integrity certificate, applied specifically to the source-versus-target comparison a migration demands. For the wider before-and-after workflow, see our data migration verification certificate guide.

Caveats and Practical Tips

A hash comparison is only as good as the exports feeding it, so a few disciplines matter. Use a deterministic export ordering: always add an explicit ORDER BY on a stable key so the rows come out in the same sequence on both sides — without it, the same data in a different order produces a different hash and a false mismatch. Keep the column order identical across source and target queries. Handle generated, auto-increment and audit columns that are expected to differ by excluding them from the export or comparing them separately, so a legitimately different surrogate key does not flag the whole table. Watch for encoding and line-ending differences in the export tooling, and export both sides with the same character set. Get the export right, and the hash does the rest with zero ambiguity. To read more on the broader topic, see the data migration verification overview.

Frequently Asked Questions

Why is matching row counts not enough to validate a database migration?
Row counts only confirm that the same number of rows arrived; they say nothing about the contents of those rows. A migration can keep every count identical while silently truncating long text, dropping decimal places, mangling character encoding, swapping nulls for empty strings or shifting time zones on dates. Counting rows misses all of it. To prove the data itself is unchanged you have to compare the actual values, which a hash-based comparison does directly.

How do hashes prove that source and target data are identical?
A cryptographic hash is a fixed-length fingerprint computed over a file's bytes. If you export a source table and the matching target table to files using the same deterministic ordering and then hash both files, an identical hash means every byte is identical, so the data is the same. If a single value was truncated, re-encoded or dropped, the hashes differ and you get a MISMATCH that points you straight at the affected table.

What is a database-migration integrity certificate?
It is a one-page, readable document that records the cryptographic hashes of the source and target exports for each table and prints an explicit MATCH or MISMATCH verdict, plus an overall result across the set. It turns a vague "the migration looks fine" into auditable sign-off evidence that the migrated data is bit-for-bit identical to the source, which is useful for go-live approvals, audits and regulatory records.

Does e-Dex need an internet connection to validate a migration?
No. e-Dex runs fully offline on your own Windows machine. Hashing the export files, comparing source against target and generating the migration integrity certificate all happen locally, so your data exports never leave your computer. An internet connection is only needed if you choose to apply an RFC-3161 trusted timestamp to the certificate.

What can cause false mismatches when hashing database exports?
A mismatch only means anything in the bytes differs, which can include harmless differences if the two exports were not produced identically. The common causes are non-deterministic row ordering (no fixed ORDER BY), differing column order, generated or auto-increment columns that legitimately differ, timestamp or audit columns, and differences in encoding or line endings. Fix these by exporting both sides with the same query, the same column order, an explicit sort, and by excluding columns that are expected to differ.

Conclusion

Row counts answer the wrong question. They tell you how many rows moved, not whether the data inside them survived — and migrations break data in ways no count will ever catch. A hash-based comparison answers the right question precisely: export source and target the same way, hash both, and a plain MATCH or MISMATCH verdict tells you exactly which tables are clean and which need attention before go-live. You can run the whole comparison and produce a signed data-migration integrity certificate offline, on a single Windows machine, with e-Dex — the Digital Evidence Integrity Suite. Download it free and prove your migration moved the data, not just the row count.