Data validation establishes whether migrated records support the same required facts and activities in the replacement system. It compares more than row counts. Values, relationships, permissions, files, history, and resulting business actions all need defined checks before a team can treat the transfer as complete.
What validation must prove
A validation plan begins with the approved migration scope and data mapping. Those sources define what should move, how it should change, and what may be excluded. The checks then compare that expectation with the destination.
| Validation layer | What it checks | Typical evidence |
|---|---|---|
| Completeness | Required records and fields arrived | Counts by object and status |
| Accuracy | Values match or follow transformation rules | Source-to-target samples |
| Relationships | Links between records remain valid | Orphan and reference checks |
| Access | Roles and permissions expose the right data | Tests with representative accounts |
| Operational use | Workflows and integrations use the records correctly | Acceptance scenarios and interface logs |
No single check proves success. Matching totals can hide records assigned to the wrong owner. Correct individual values can still sit under broken relationships. A technically valid import can fail operationally when a status no longer triggers a required action.
Validation before and after cutover
Validation starts before the final move. Trial migrations reveal unclear rules, unsupported formats, duplicate identifiers, and source data that cannot satisfy destination constraints. Teams can correct the rule, clean the source, or document an accepted exception while both systems remain available.
The final migration repeats automated checks and targeted business review. A cutover plan assigns owners and deadlines to these checks because some can run before users enter the new system while others depend on the final data load.
Useful validation work includes:
- Reconciliation: compare counts, totals, date ranges, and category distributions between source and destination.
- Rule testing: confirm transformations, defaults, exclusions, and calculated values against the approved specification.
- Relationship testing: find missing parents, unresolved references, duplicate keys, and detached attachments.
- Permission testing: use representative roles to check viewing, editing, approval, and export access.
- Business scenarios: complete real tasks from start to finish using migrated records and connected systems.
How exceptions are handled
Validation commonly finds differences that are not all defects. Some records were deliberately excluded, some values were normalized, and some source data was already incomplete. The result needs an exception record that distinguishes expected changes from failures requiring correction.
Each exception should state:
- Affected scope: which objects, records, users, or periods are involved.
- Reason: whether the difference comes from an approved rule, source quality, or migration failure.
- Business effect: which work, reporting, access, or compliance duty may be affected.
- Decision: correct, accept, archive, or investigate before approval.
- Owner and evidence: who closes the item and what demonstrates completion.
Validation as an acceptance decision
The migration team can execute technical checks, but data owners confirm meaning and usability. Acceptance criteria therefore need both technical and business evidence. They also need a stated threshold for unresolved exceptions and a named authority for the final decision.
During a parallel run, teams can compare outputs from both systems against the same input. When only one system can process new work, rehearsed migrations and sampled business scenarios provide the main evidence. The experience of integrating several SaaS products also shows why interface behaviour belongs in validation: correct records are not enough when connected systems interpret them differently.
Approved validation results become part of the migration record. They support the decision to proceed, identify what still needs monitoring, and provide the evidence used if the team must invoke its rollback criteria.
