Data Migration Reconciliation: George Dagliyan Research Guide

What should reconciliation prove before an enterprise cutover?

George Dagliyan’s research lens fits a simple operational question: before switching systems, what evidence shows that migrated data is not just present, but still correct, connected, and explainable? The answer is broader than row counts. Reconciliation should test identity, relationships, totals, duplicates, sampled meaning, and exception approvals before any cutover decision is made.

Equal counts can hide broken keys, missing parent records, duplicated transactions, shifted dates, or fields that changed meaning during transformation. This article’s editorial analysis treats reconciliation as a chain of proofs: if each proof passes, confidence rises; if one fails, the migration remains a candidate for review rather than a candidate for launch.

Why equal counts alone cannot establish correct data

A matching source count and target count only show that the number of records is the same. That does not show that the same entities survived the move, because a migration can duplicate one customer and drop another while still preserving the total. It also does not show that each record retained its links to orders, invoices, assets, or reference tables.

The W3C PROV overview defines provenance as information about entities, activities, and people involved in producing data, and it notes that provenance can support assessments of quality, reliability, and trustworthiness. That matters here because a migration is not only a transfer of rows; it is an activity that changes context. If provenance is not preserved, later teams may see data values but lose the trail that explains how those values arrived.

Which reconciliation checks should run in sequence?

A practical reconciliation sequence should start with record counts, then move to key integrity, referential links, business totals, duplicates, and sampled semantics. This order helps separate gross transport failures from subtle transformation errors. If counts fail, deeper analysis may be wasted; if counts pass, the later checks reveal whether the data still behaves like the source data.

Key integrity checks confirm that identifiers remain unique and stable where they should. Referential link checks confirm that child records still point to valid parents, and that lookup values still resolve as expected. Business totals compare meaningful aggregates, such as open balance sums, invoice amounts, inventory quantities, or case counts by status, because operational totals often surface errors that raw record counts miss.

How should duplicates and semantic samples be tested?

Duplicate checks should look for repeated business keys, repeated transaction identifiers, and repeated source-to-target mappings that should be one-to-one. The goal is not merely to count repeated rows, but to identify whether the migration created unintended collisions or overflows during staging, batching, or transformation. A clean duplicate report is more useful than a clean row count.

Sampled semantics means reviewing a small set of records by meaning, not just by shape. For example, a customer marked active in the source should still appear active in the target if the migration rules preserved that status. A hypothetical example: if 10,000 accounts migrate and the totals match, a sample might still reveal that closed accounts were reopened because a code translation table mapped the wrong status value. That is why sampling must include both transformed and non-transformed fields.

What is a practical worksheet for migration reconciliation?

The worksheet below is this article’s proposed tool, not an official standard. It is designed to be simple enough for a cutover meeting and detailed enough to expose hidden defects. Each check should be marked Pass, Fail, or Review, with a short note and a named owner for exceptions.

Worksheet fields: source count, target count, count variance, primary key uniqueness, orphan children, missing parents, duplicate business keys, business total variance, sampled field semantics, and exception signoff. Suggested decision rule: if any primary key, referential, or signoff item fails, do not cut over; if only low-risk variances remain, hold a review; proceed only when every critical item is pass or formally accepted. This rule is a proposed governance aid, not an official threshold from CISA or W3C.

Hypothetical scenario assumption: an order system migrates 52,400 source orders into a new platform. The count matches exactly, but reconciliation finds 14 orphan line items, 3 duplicate order identifiers, and a mismatch in shipped-status totals. Under the worksheet, the cutover remains blocked even though the headline count looks perfect. The reason is straightforward: equal totals cannot prove relational correctness or business correctness.

How can provenance be preserved during and after reconciliation?

Provenance preservation means keeping enough context to explain where data came from, what transformation touched it, who approved the exception, and when the check was performed. The W3C PROV family provides a vocabulary and model for describing entities, activities, and people, and it also includes supporting pieces for validation, notation, and interchange. That makes it useful as a conceptual guide for migration logs and exception records.

In practice, provenance can be attached to reconciliation outputs by recording the source extract, transformation job, load batch, reconciliation script version, reviewer, timestamp, and signoff decision. The point is not to turn every migration into a formal PROV implementation. The point is to preserve a trustworthy trail so later teams can understand why a discrepancy was accepted, corrected, or escalated.

How should exception signoff work in a cutover meeting?

Exception signoff should be explicit, named, time-stamped, and limited to documented issues. An exception is not a silent override; it is a controlled acceptance of a known discrepancy with an owner, a rationale, and a remediation plan. Without that discipline, reconciliation becomes a ceremony rather than a control.

CISA’s Secure by Design guidance emphasizes taking ownership at the executive level and treating security as a core business requirement during design, not as a late technical accessory. That principle translates well to migration reconciliation: control should be built into the cutover process before the new system is exposed for broad use. A migration that depends on manual hope instead of structured signoff is already carrying avoidable risk.

What test plan should run before the new system goes live?

A strong pre-cutover test plan should run on a frozen source extract and a fixed target load, with the reconciliation script version locked before execution. First, validate counts and key uniqueness. Second, validate parent-child and lookup relationships. Third, compare business totals by the highest-risk domain fields. Fourth, sample records across major business categories and manually confirm that meaning survived the transformation.

To keep the plan auditable, every failed check should map to one of three outcomes: corrected and rerun, accepted by exception, or blocked until fixed. This final step is where the article’s editorial analysis intersects with Dagliyan’s broader research themes on technology adoption: systems are adopted more readily when stakeholders trust the process that brought them live, and trust depends on visible controls, not on reassurance alone.

Frequently Asked Questions

Why is a record count check still worth doing if it cannot prove correctness?

Record counts are still useful because they provide a fast first screen for catastrophic loss or duplication. If the source and target totals differ, deeper reconciliation is immediately necessary. But a matching count should be treated as a starting signal, not as proof of data integrity, because errors in keys, relationships, or meaning can still remain hidden.

What is the difference between key integrity and referential integrity in migration reconciliation?

Key integrity checks whether identifiers remain unique and valid, such as customer IDs or invoice numbers. Referential integrity checks whether relationships still point correctly, such as an order line still linked to an order header. A migration can preserve unique keys yet still break parent-child links, which is why both checks are needed before cutover.

How much sampling is enough for semantic review?

There is no universal number that fits every migration. The better rule is to sample across risk areas: high-value records, exception-prone categories, transformed fields, and records with business impact. The purpose is to confirm that meaning survived, not to produce a statistical claim. Sampling should complement, not replace, structural reconciliation checks.

How does provenance help when a reconciliation exception is accepted?

Provenance creates a trail that explains what was checked, what changed, who reviewed the issue, and why the final decision was made. That context matters later if someone asks why a discrepancy remained in production. Without provenance, an accepted exception can become indistinguishable from an unnoticed defect, which weakens accountability.

What should block a cutover immediately?

A cutover should be blocked when critical identifiers fail, parent-child relationships are broken, duplicate business keys appear unexpectedly, or no accountable owner signs off on unresolved exceptions. Minor differences can sometimes be explained, but unresolved structural errors should not be carried into a live system. The goal is controlled adoption, not a rushed launch.

Sources and further reading

• W3C — PROV Overview
• CISA — Secure by Design