Cloud Data Migration Validation: Proving Records Arrived Intact

\1**\1**.

Inventory before extraction

Identify source systems, record types, owners, interfaces, retention requirements, metadata, attachments, audit trails, and excluded data. Record the source version and the migration scope.

Do not start with a row count alone. One source record can contain linked files, history, signatures, or relationships that a simple count will not reveal.

Approve mapping rules

Define how fields, codes, dates, units, statuses, identifiers, and relationships map from source to target. Document transformations and truncation rules. A mapping rule should be reviewable and testable.

If a target field cannot preserve the source meaning, decide whether to retain the source record, add a controlled note, or exclude it with an approved rationale.

Reconcile the result

Use independent checks suited to the risk, such as counts by record type and status, key-field comparisons, checksum or file checks, relationship checks, and sample review. Reconcile exceptions rather than hiding them in a pass rate.

For audit trails and signatures, verify the attributes that establish history and attribution. A migrated current value without its required history may not be a complete record.

Test failure and restart

Test rejected rows, duplicate identifiers, interrupted transfers, partial retries, and restart behaviour. The migration should not silently duplicate or omit records when a job is rerun.

Keep the original source protected until acceptance and retention decisions are complete. Record the cutover decision and who approved it.

Close with evidence

The final report should state scope, counts, exceptions, decisions, test results, approvals, and open follow-up. Link the evidence to the migration plan and validation traceability record.

FAQ

Can a migration be validated with sampling only?

Sampling may be suitable for some attributes, but completeness and critical data may require broader reconciliation. Base the approach on risk and document it.

Should source records be deleted after migration?

Only under an approved retention and disposition decision. Preserve required records and evidence.

What is the difference between migration verification and validation?

Verification checks that the transfer followed defined rules. Validation considers whether the resulting system and process are fit for intended use.

How should failed records be handled?

Keep an exception record, investigate the cause and impact, correct through control, and rerun or disposition with approval.

Decision rule: choose evidence from the consequence of failure, the control being relied on, and the ability to detect a problem. A larger document set is not automatically stronger. Clear scope, reproducible evidence, and an approved conclusion are what make the decision defensible.

Keep the rationale with the controlled record. Future reviewers should be able to see what was considered, what was tested or reviewed, what remains uncertain, and who accepted the residual risk.

During review, compare the approved requirement with observed use, current configuration, and retained evidence. That simple comparison often finds drift before an auditor does.

For related work, read our validation traceability matrix guide.