Data migration reconciliation report template and sign-off checklist

Copy the comparison contract first

A data migration reconciliation report should show the exact source and target states compared, each required check and its coverage, unresolved exceptions, and an explicit decision by named owners. Copy the fields below into a controlled report before cutover; equal row counts alone cannot establish matching keys, values or business outcomes.

Download the Excel template · View the filled example

Free download: blank template and fictional example (.xlsx). No registration required.

Paste tool exports into Table results (5,000 prepared rows) and the technical detail sheet (10,000 prepared rows). Enter shared run details once. Use Exceptions only for issues needing action; Fictional example shows both summary and technical results. Extend the tables and copy formulas when more rows are needed.

Run details — enter once

Use the approved mapping reference for all tables. If grain changes, populate Expected rows from the transformed expectation, not the raw source count. Only document mapping overrides for tables that differ from the shared configuration.

Align a stable comparison boundary. A timestamp on two independently changing databases does not prove equivalent transaction state. For a cutover, record a held source extract or snapshot, complete the corresponding load, and verify the target applied through the agreed source position. For CDC, specify a settled window and keep late changes pending. The broader reconciliation guide explains how to choose the underlying methods.

Prepare the source baseline with the data profiling report template.

Use a check register, not a single pass flag

Keep Source schema, Source table, Target schema and Target table in separate columns in every report sheet. The fictional examples use source and target as schema names; replace them with the actual names.

One row per table

Paste source schema, source table, target schema, target table, expected rows, target rows and Required checks status. The blue Row difference and Result columns calculate. Required checks summarises approved key, mapped-value and business checks: use Pass only when all are complete and passing. Partial, sampled or unrun mandatory work stays Not assessed. Equal counts alone never produce Pass.

Treat a skipped field as uncovered, not passing.

Technical checks by column and partition

Use Technical checks for one row per table pair, check, column and partition. It includes column sums, partition counts, rows per partition, null/distinct counts, numeric minimum/maximum, missing/unexpected keys and value mismatches. Paste expected and target values with the approved absolute tolerance; Difference and Result calculate automatically.

For missing keys, unexpected keys and value mismatches, enter zero as the expected value and the observed exception count as the target value.

Partition count is the number of agreed logical buckets, including empty buckets; partition row count compares rows in each named bucket. Compare the bucket identities too: equal partition counts can hide a missing and an unexpected bucket. Physical source and target partitions may differ by design.

A technical row passes only with numeric values, an explicit non-negative tolerance and full coverage within tolerance. Use zero tolerance for exact counts; missing inputs and partial coverage cannot pass. A matching sum can hide offsetting differences. Confirm all required checks against the shared check-set before setting the table summary to Pass.

• Counts and scope: compare included object and partition inventories, exact rows per agreed grain, and rejected or quarantined load rows. Missing and extra rows may cancel in a total.
• Keys and values: compare missing and unexpected keys in both directions, duplicate keys, then critical mapped fields with null-safe equality. If hashing narrows candidates, record selected fields, encoding, normalization and collision limitation.
• Aggregates: compare decimal sums and counts by a useful business slice such as period, entity and currency. Agree rounding and tolerance in advance. Opposing value errors can cancel even within a matching total.
• Business and relationships: run approved invariants, parent-child orphan checks, and report tie-outs with the same filters and parameters. A technically identical copy can retain an existing source defect.

Capture both the result and the method's blind spot. A sampled field comparison needs its selected-key list and sample design; it cannot be reported as complete value coverage. For a high-impact cutover, choose mandatory checks with the business owner before execution, not after seeing discrepancies.

Filled example: fictional orders cutover

Fictional batch summary

Fictional batch examples show how to filter table results. Record manual actions only for flagged issues.

Illustrative data only: RC-022 compares a held 24,000-row source orders extract, after source key remediation, with a completed target load at the same boundary on 27 September 2026. The approved mapping keeps one row per order_id, translates closed to complete, and excludes no orders. The figures below are invented for teaching, not customer results; the run remains open because required checks failed.

This continues PR-014 after eight misassigned order identifiers were corrected without deleting orders, giving 24,000 unique keys. All amounts are MYR. The report enumerates January–December 2026 buckets, including zero-row months, using the same date rules on both sides. Future-dated orders remain visible for business review.

Matching overall counts hide the missing and unexpected key. The baseline orphan count is not automatically acceptable simply because it was preserved. Retain masked key-level and field-level evidence in a restricted store. A real report should state the query IDs, execution times and exact partitions behind every row above.

Signed difference = target result − approved expected result. For percentage variance, divide by the absolute expected value; when expected is zero, report the absolute difference and mark percentage variance not applicable. Agree tolerance and approval before execution.

Keep incomplete and unsupported work visible

Filter Table results by Review, Not assessed or Not run to find the work that needs attention. Keep detailed coverage in the tool export; do not maintain a second manual coverage register. A count check across all rows does not imply all fields were compared.

AWS DMS exposes validation states and counts for pending, failed and suspended records, and documents cases such as missing keys and unsupported data. Those labels and automatic row comparisons are specific to DMS configurations. Use the equivalent evidence from the actual migration tooling, or create an explicit manual check register. Never copy a vendor's “validated” status into a blanket claim about transformed business outputs.

Filled coverage entry: RC-022 assessed all 24,000 expected keys. There were 23,999 paired rows: 23,998 statuses matched and one differed. One expected key was missing; one unexpected target key was reported separately. All 12 monthly amount groups were checked. The relationship decision remains pending; sign-off is held until correction, rerun and business review.

Register exceptions and rerun affected checks

Only record issues that need action

Keep a separate record for a tool error, an unavailable check and a genuine data mismatch.

Filled example: E-07 links to RC-022's missing and unexpected key pair. Impact: the target could attach one order to the wrong account. The data engineer compares extraction and load logs, corrects the mapping or data only after identifying the cause, then reruns key-set, mapped-field, amount and account checks on the affected range. The migration lead records the new run ID; the business owner reviews the result. E-07 is open, with no waiver.

Where a transformation deliberately changes values, compare against the approved transformed expectation and record the rule version. Keep exceptions traceable across reruns; replacing the old report with a fresh green summary would erase the decision trail.

Sign-off checklist and decision record

• Confirm the shared boundary, approved mapping and required checks.
• Resolve incomplete work or record an explicitly approved exception.
• Record the overall cutover decision, decision-maker, date and evidence once per run.

Record acceptance once for the migration run, not once per table. A passing table result is not cutover approval. RC-022 remains on hold in the fictional example.

This report is a good fit for cutover rehearsal and production acceptance where teams need a reviewable record. It is a poor substitute for ongoing CDC monitoring after sign-off: keep reconciling settled change windows and operational outcomes. The checklist is a practical editorial template, not a guarantee of correctness or a product certification.

Are matching row counts enough for migration sign-off?

No. A missing row and an unexpected row can cancel in the total. Compare keys, mapped values, business aggregates and relationships at the same boundary, with explicit coverage and approved exceptions.

Who approves reconciliation exceptions?

The designated business owner accepts the business impact; the technical owner records evidence and recommends action. The authorised cutover decision-maker records the final decision. Capture names, dates, conditions and expiry rather than inferring approval from a tool status.

Prepared by Monic Solutions Services. About our delivery experience.

The global SAP migration case describes reusable profiling, cleansing, matching and validation rules. That is why these templates retain rule versions, evidence and decision owners. The downloadable examples are fictional and are not client project records. Global SAP migration case.

Primary references

• AWS DMS: data validation states and limitations
• AWS DMS: validation task settings
• GoogleCloudPlatform: open-source Data Validation Tool methods