Establish the live position before planning change
Data validation in a legacy migration is the process of confirming that information has moved from the old system to the new one accurately, completely and in a usable state. It is not the same as cleaning up poor-quality source data, which is a separate concern handled before and alongside the migration itself. Validation answers a specific question: given the data we chose to move, did it arrive correctly?
This matters because legacy systems often hold years of operational records, customer relationships and transaction histories that the business depends on. If those records are corrupted, truncated or misaligned during the move, the new system inherits problems that may not surface until staff rely on the data in live operations. By that point, the old system may already be decommissioned.
Validation operates at several levels. Structural validation checks that the right number of records exist, that tables and fields are populated and that data types match what the new system expects. Content validation examines individual values for format, length and permissible ranges. Business-rule validation goes further, checking whether the data still makes sense in the context of the new system's processes — for example, whether every customer record in the new CRM has a valid status, a matching address and an intact order history.
Responsibility for validation is shared. Technical teams confirm that the migration scripts ran without errors and that structural checks pass. Business owners and operations staff confirm that the data means what it should mean in the new environment. A migration is not complete until both sides have signed off.
| Assessment area | What to establish | Evidence to retain |
|---|---|---|
| Record-level checks | The most basic validation is a count comparison: how many records existed in the source, and how many arrived in the target? | Validated samples, reconciliation results, a named data owner and logged exceptions. |
| Field-level and format validation | Even when record counts match, individual fields can be corrupted. | A named owner, current-state evidence, unresolved questions and a dated decision record. |
| Referential integrity | Legacy data is relational. | A named owner, current-state evidence, unresolved questions and a dated decision record. |
| Business-rule validation | Some problems only emerge when you apply the new system's logic to the migrated data. | A named owner, current-state evidence, unresolved questions and a dated decision record. |
Record-level checks
The most basic validation is a count comparison: how many records existed in the source, and how many arrived in the target? This catches wholesale omissions — entire tables or partitions that failed to transfer. However, matching totals alone is insufficient. A count tells you nothing about whether the right records moved, whether duplicates were introduced or whether some records were merged or split during transformation.
More useful record-level checks include comparing sets of unique identifiers between source and target, verifying that no expected IDs are missing and no unexpected IDs have appeared. Sampling is another approach: selecting a defined percentage of records and comparing every field between the old and new system manually or with scripted comparisons.
Field-level and format validation
Even when record counts match, individual fields can be corrupted. Dates may shift format or lose time-zone information. Currency values may lose decimal precision. Text fields may be truncated if the new system imposes shorter length limits. Null values may appear where data existed before, or data may appear where the source was empty.
Field-level validation requires a clear mapping document that specifies the expected transformation for every field: source field name, target field name, data type, format, length and any conversion logic. Without this, there is no baseline against which to validate.
Referential integrity
Legacy data is relational. A customer has orders, orders have line items, line items reference products. If the migration breaks these links — for example, by migrating customers and products but failing to migrate the order lines that connect them — the data becomes structurally intact but operationally useless.
Referential validation checks that every foreign-key relationship in the new system resolves correctly. In a CRM migration, this means confirming that every contact is linked to the right organisation, every opportunity to the right contact and every activity log to the correct record.
Business-rule validation
Some problems only emerge when you apply the new system's logic to the migrated data. A customer record might pass all structural checks but fail a business rule — for instance, a record marked as "active" with no associated billing details, or an account with a future closure date. These checks require business input because the rules are specific to how the organisation operates.
Staged validation and sign-off
Validation should not be a single event at the end of the migration. A practical approach is to validate in stages: first after a test migration with a subset of data, then after a full dry run, and finally after the live cutover. Each stage should have explicit pass/fail criteria agreed in advance. If any criterion fails, the migration team must investigate, fix and re-run before proceeding.
Relying solely on row counts
The single most common mistake is treating matching record counts as proof of a successful migration. Counts confirm volume, not accuracy. A migration can move exactly the right number of records while corrupting every date field, dropping every optional field and breaking every relationship. Row counts are a starting point, not a conclusion.
Not defining pass/fail criteria before the migration
If you do not agree what "success" looks like before the migration runs, you cannot objectively determine whether it worked. Criteria should be specific and measurable: for example, "zero null values in mandatory fields," "100% of source customer IDs present in the target," "all order totals match to the penny." Vague criteria such as "data looks correct" create disputes and delay go-live decisions.
Excluding business users from validation
Technical teams can verify structure and format, but they cannot determine whether a migrated status value of "pending" in the new system corresponds correctly to "under review" in the old one. Business users who understand the operational meaning of the data must be involved in defining validation rules and reviewing results. When they are excluded, errors persist until live use exposes them.
Assuming the source data was correct
Validation confirms that the migration transferred data faithfully. It does not confirm that the source data was accurate to begin with. If the legacy system contained duplicate customer records, incorrect addresses or stale statuses, the new system will inherit those problems. This is why data quality assessment is a prerequisite, but it is also why validation should flag anomalies that look suspicious, even if they match the source.
Key checks to insist on
- Record-count reconciliation for every entity type, broken down by any relevant category (status, date range, region) rather than just a single total.
- Unique-identifier comparison confirming that every expected ID is present and no extras have been introduced.
- Field-level sampling comparing source and target values for a statistically meaningful subset of records.
- Referential-integrity checks confirming that all relationships between entities are intact.
- Business-rule execution running the new system's validation rules against the migrated data and reviewing every failure.
- Checksum or hash comparisons where feasible, to detect subtle corruption that field-level checks might miss.
- Sign-off documentation recording who validated what, when, against which criteria and with what result.
Limitations to accept
Validation has boundaries. It cannot verify data that was never documented — if nobody in the business can explain what a particular legacy field was used for, there is no meaningful way to confirm its migrated value is correct. It also cannot compensate for a poorly defined target data model. If the new system was designed without adequate input from operations staff, validation will reveal mismatches, but resolving them may require rework on the system itself rather than the migration.
Leave the next team with verifiable evidence
Finally, validation adds time and cost to a migration project. Attempting to validate every field in every record across a large legacy dataset may be impractical. The practical approach is to prioritise: validate critical data exhaustively, validate high-volume data through sampling and automated checks, and accept a measured level of residual risk for low-priority historical records where the business impact of an error is minimal. That prioritisation should be explicit, agreed and documented before the migration begins.