Cloud Data Migration: Build a Reconciliation Evidence Pack

How do you prove a cloud data migration is correct?

A migration job finishing successfully proves that the job completed, not that every downstream report or application still behaves correctly. A reconciliation evidence pack makes the distinction explicit. It collects the comparisons, exceptions and approvals needed to decide whether the migrated data is fit for use.

Build this pack before the production move. Doing so helps reveal which source tables, business definitions and relationships need special handling, and avoids inventing acceptance criteria when the cutover window is already under pressure.

Agree the comparison boundary

Choose a consistent point in time or documented change boundary for comparison. If the source continues changing while you count records on the target, different answers may simply reflect different snapshots. Explain how ongoing changes are captured and when the final comparison should be made.

List the tables in scope and identify exclusions. Record why an exclusion exists and who approved it. Include business-critical data even when it is small; a configuration table may have more operational importance than a large historical event table.

For each table, define the key, grain and expected transformations. Source-to-target equality is not always the right rule when a migration intentionally normalizes dates, splits tables or converts types. In those cases, define the expected equivalence before testing.

Use several kinds of evidence

Start with counts and distinct-key checks, then add comparisons that reflect how the business uses the data. Suggested evidence includes:

• Counts by table and agreed period, with documented exclusions.
• Duplicate or missing business-key reports.
• Financial or operational totals using consistent currency and rounding rules.
• Null-rate changes for critical fields.
• Date, timezone and precision conversion checks.
• Relationship checks for orphaned records.
• A small, explicitly chosen set of application and reporting tests.

Sampling can support investigation but does not prove that every row matches. Identify which checks are complete and which are sampled so a reviewer understands the strength of the evidence.

Understand the limits of automated validation

AWS DMS data validation can compare source and target rows and report mismatches. AWS also documents additional resource consumption on the source, target and network. Review the supported configuration and documented limitations for your particular migration rather than assuming validation applies to every endpoint or transformation.

Schedule validation with the source-system owner. An aggressive comparison during business hours can compete with operational queries. Include the expected impact in the migration rehearsal, and keep the migration team's business checks separate from the tool's validation result.

Make exceptions actionable

Each discrepancy should have a reproducible query or record reference, severity, owner and resolution status. Distinguish an expected transformation from an unexplained mismatch. Re-run affected checks after remediation and retain the original and corrected evidence.

Do not write a blanket 'zero data loss' conclusion when exclusions, unresolved differences or unsupported checks remain. Instead, describe what was tested, the observed result and the residual risk approved by the business owner.

Assemble the sign-off pack

The final pack should identify the migration run, source and target boundaries, test definitions, results, exceptions and approvers. Include rollback readiness and a plan for post-cutover checks. Store access-controlled evidence where operations staff can find it; do not distribute sensitive record extracts casually by email.

Microsoft's migration execution guidance provides broader preparation and execution context. Use it alongside the documentation for your actual migration tooling.

You'll Love Our Smart AI Data Studio (Demo), Try It to explore joining file extracts, inspecting differences with SQL and summarizing results in dashboards. This is a preparation demonstration, not an automated cloud migration service. Demo files are limited to 100MB each; deployed solutions can support 5GB uploads.

Izan Technologies provides on-premises-to-cloud migration and data engineering services. You own all IP in anything we build, provide or deliver. Book a consultation to agree migration scope, validation evidence and acceptance owners.