ERP Migration Sign-Off: Prove Migrated Data Matches the Legacy Source

Introduction: Sign-Off Needs Proof, Not Hope

Every ERP migration sign-off comes down to one uncomfortable moment: someone has to put their name to a statement that the data in the new system is the same data that lived in the old one. Before you go live on a new ERP or business system, you are not just moving records — you are betting the organisation's invoices, stock balances, ledgers and customer history on a load process that ran once, often overnight, frequently under time pressure. The question that decides go-live is blunt: does the migrated data actually match the legacy source? This article lays out a verification workflow built on cryptographic hashing that lets project managers and IT teams answer that question with evidence, and produce a defensible sign-off certificate with e-Dex (formerly Hash Calculator), offline, on your own machine.

Why Row Counts and Spot-Checks Aren't Enough

The two most common ways teams "verify" a migration are counting rows and eyeballing a few records. Both feel reassuring and both miss the failures that matter. A row count confirms how many records arrived, not whether their contents survived the journey. A migration can move exactly the right number of rows while silently truncating a long text field, rounding a currency amount, dropping the time from a timestamp, flipping a date format, or corrupting non-ASCII characters in a name. The count still tallies; the data is wrong. Spot-checks are worse: opening twenty records out of two million tells you those twenty look fine and nothing about the rest. Neither method scales, and neither produces anything you could hand an auditor. You need a method that examines every record's actual content and gives a yes-or-no answer.

The Pre/Post Hashing Workflow

Hashing solves this cleanly. A cryptographic hash is a fixed-length fingerprint computed from a file's contents — change a single byte and the fingerprint changes completely. The workflow has three steps. First, hash the source: before go-live, export each in-scope dataset from the legacy system to files (CSV, fixed-width, whatever shape is stable) and hash them with e-Dex. Second, hash the target: after the load completes, export the same scope from the new system in the same shape and hash those files. Third, reconcile: compare the two sets so every record falls into one of three buckets — matched (hashes identical, content verified unchanged), changed (hashes differ, content was altered in transit), or missing/extra (a record present on one side but not the other). The comparison is objective, repeatable and covers one hundred percent of the data, not a sample.

The discipline that makes this trustworthy is shaping both exports identically — same column order, same date and number formatting, same encoding, same sort. Differences you don't care about (like trailing whitespace) should be normalised on both sides before hashing, so that a MISMATCH always means a real content change, never a formatting artefact. Our companion guide on the data migration verification certificate walks through this normalisation in more detail.

Spotting Silent Loss Before Sign-Off

The whole point of pre/post hashing is to surface the failures that hide behind a green dashboard. Silent loss is the migration team's nightmare: data that vanishes or degrades without throwing an error. A few thousand historical line items that fell out of a join. Customer codes that lost leading zeros when they passed through a numeric field. Tax amounts that rounded to two decimals when the source kept four. None of these stop the load; none of them appear in a row count. They surface months later as a reconciliation gap, an angry customer, or a regulator's question — at which point the legacy system may already be decommissioned and the truth unrecoverable. Reconciling hashes before you flip the switch turns those silent failures into a visible, itemised list of changed and missing records while you can still fix them. That is the moment the verification pays for itself.

Producing a Migration Sign-Off Certificate as Go-Live Evidence

A reconciliation that lives only in someone's spreadsheet is not evidence. The output of the workflow should be a migration sign-off certificate: a one-page record that states the data scope compared, the hash algorithms used (e-Dex computes MD5, SHA-1, SHA-256, SHA-512 and BLAKE3 side by side), the per-set results, and an explicit overall MATCH / MISMATCH verdict. This certificate becomes the artefact attached to the cut-over decision — the document that demonstrates the go-live was approved on the basis of a verifiable check rather than an assurance. Where the data carries audit or compliance weight, you can apply a PAdES digital signature with a Digital Signature Certificate on a USB token, binding the signer's identity so any later edit is detectable, and an RFC-3161 trusted timestamp that seals exactly when the certificate was produced. Everything except the timestamp runs fully offline, so business-critical data never leaves your environment.

Who Signs Off

Sign-off is rarely one signature. The data owner or business process owner confirms the scope is right and the records mean what they should. The IT or migration lead confirms the technical reconciliation and stands behind the hash results. The project manager records the overall go-live decision and owns the timeline consequences. Where the data has regulatory or financial significance, an auditor may countersign. The value of the integrity certificate is that it gives every one of these people the same objective basis to sign against — not a verbal "looks fine", but a stated verdict across the full dataset that each of them can re-verify independently if they ever need to.

Frequently Asked Questions

Why aren't matching row counts enough to sign off an ERP migration?
Row counts only tell you how many records arrived, not whether their contents are correct. A migration can move the right number of rows while truncating a field, rounding an amount, dropping decimals, mangling a date format or swapping an encoding. Counts will still tally. Pre/post hashing compares the actual content of each exported record, so a single changed byte produces a MISMATCH that a count would never reveal.

How does pre and post migration hashing actually work?
Before go-live you export the relevant data from the legacy system to files and hash them with e-Dex. After loading the new system, you export the same scope in the same shape and hash those files too. You then reconcile the two sets: records whose hashes match are verified unchanged, records whose hashes differ are flagged as changed, and records present on one side only are flagged as missing or extra. The result is an objective, record-level comparison rather than a visual spot-check.

What is a migration sign-off certificate and who relies on it?
A migration sign-off certificate is a one-page record that states which data scope was compared, which hash algorithms were used, and the overall MATCH or MISMATCH verdict across the reconciled set. It becomes the go-live evidence attached to the cut-over decision. Project managers, IT leads, data owners and auditors rely on it to show that the decision to go live was backed by a verifiable integrity check, not just an assurance.

Does verifying migrated data with e-Dex require an internet connection?
No. e-Dex runs fully offline on your own Windows machine. Hashing the legacy exports, hashing the target exports, reconciling them and producing the migration sign-off certificate all happen locally, so sensitive business data never leaves your environment. An internet connection is only needed if you choose to apply an RFC-3161 trusted timestamp to the certificate.

Who should sign off on an ERP data migration?
Sign-off is usually shared. The data owner or business process owner confirms the scope and the meaning of the records. The IT or migration lead confirms the technical reconciliation and the hash results. The project manager records the overall go-live decision. Where the data has audit or compliance weight, an auditor may countersign. The integrity certificate gives all of them the same objective basis to sign against.

Conclusion

An ERP migration sign-off should rest on proof, not optimism. Row counts and spot-checks cannot see the silent loss that hashing catches, and a verbal assurance is not something you can hand an auditor a year later. Pre/post hashing reconciles legacy and new data record by record, exposes every changed or missing item before go-live, and condenses the result into a one-page certificate that everyone can sign against with confidence. See how the workflow comes together in our data migration verification overview, then produce your own go-live evidence in minutes, offline, with e-Dex — the Digital Evidence Integrity Suite. Download it free and migrate with certainty.