A transfer can complete while customer links are broken, records are missing and descriptions are cut short. The application opens, but the data inside it needs checking before anyone relies on it.
Data integrity concerns keeping information accurate, complete and consistent through storage, processing and change. During migration, the immediate task is to establish whether records arrived as intended. Errors already present in the source need separate investigation and correction.
1. Define the data you are comparing
Start with an agreed source snapshot: a fixed version of the data at a known point in time. Specify which datasets, date ranges and record statuses belong in the migration. Document approved exclusions, such as historical records retained elsewhere, to distinguish intentional omissions from unexpected losses.
If the source remains live during the transfer, capture subsequent additions, updates and deletions separately. Reconcile those changes after the final update batch. Both sides of the comparison should represent the same agreed point in time.
These comparisons provide evidence for ITIL service validation and testing, helping reviewers decide whether the migrated data supports the service’s intended business tasks.
2. Reconcile identifiers, not just record counts
Compare expected and actual counts, then examine which records those counts represent. One missing record and one duplicate can leave the total unchanged.
Use stable identifiers to find missing, unexpected and repeated records. Where the destination assigns new identifiers, retain a mapping between old and new values. Deliberate merges need their own reconciliation: check that the contributing source records produce the destination record specified in the approved merge rules.
Save exception lists with the affected identifiers. A report saying “12 records differ” leaves reviewers guessing. Naming the records and showing their expected destination gives the team something concrete to investigate.
3. Check values against the transformation rules
A migration can change a value’s format while preserving its meaning. Compare destination values with the expected outcome of each transformation, using the agreed mapping rules as the reference.
Check decimal precision, date interpretation, mandatory fields and coded values. An incorrectly mapped status code could turn a closed record into an active one. Text-length limits deserve particular attention: a populated field can still be missing the end of a description.
Include awkward cases in testing, such as unusually long notes, blank optional fields and identifiers with leading zeros. Record these test cases and their expected outcomes alongside the mapping rules, giving testers a basis for distinguishing approved changes from unintended alteration.
4. Check that records retain the right relationships
Look for references to missing parent records, such as an invoice whose customer record was left behind. This tests referential integrity. Business correctness also depends on the record linking to the right parent. Imagine an invoice assigned to the wrong customer during identifier remapping. The destination customer exists, so the relationship could pass a database check while directing the invoice to the wrong account.
Use the identifier mapping to compare each source association with its expected destination association. Then open representative records in the application and confirm that users can see the correct linked information.
5. Reconcile business totals and inspect exceptions
Use control totals, such as invoice values or stock quantities, to reconcile amounts and quantities across the transfer. Group comparisons by currency, reporting period or status where relevant: a grand total can conceal errors that cancel each other out.
Account for approved exclusions and transformations before calculating differences. Agree the treatment of intentional rounding in advance, including any justified tolerance.
Combine automated comparisons across the dataset with targeted inspection of unusual and high-impact records. Report which checks covered the full dataset and which used samples. A clean sample supports conclusions about the records examined; broader comparisons help establish how widespread a problem is.
Turn discrepancies into a go-live decision
For each failed check, record the expected result, actual result, affected records, investigation findings and decision owner. Someone outside the migration team should be able to follow the issue and understand what remains unresolved.
Agree launch-blocking conditions before reviewing results. An unexplained difference in outstanding balances warrants a different response from an approved formatting change. The application owner should assess the business consequences, supported by technical evidence showing the extent of the problem.
After correcting a blocking defect, rerun the affected checks against the corrected dataset, including related comparisons that the fix could disturb. Base acceptance on reconciled records, explained exceptions and a named owner for each decision.
