A migration can load every record successfully and still leave the business unable to operate correctly. The destination may contain the wrong relationships, ambiguous statuses, missing history or opening positions that cannot be explained. Technical completion of a load is not evidence that the migrated information is fit for its intended use.
For an implementation sponsor, migration should be governed as a sequence of business decisions and proofs, not a late technical activity. The team must decide what to carry forward, how meaning changes, what evidence establishes correctness and how transactions occurring during the transition will be handled.
The title highlights a frequently overlooked class of exposure, rather than claiming a measured ranking of implementation risks. Its practical consequence is clear: investigate migration assumptions early enough that the findings can still change scope, design and cutover planning.
Start with future operating questions. Which records are required to fulfill open commitments? Which history is needed for customer service, analysis or an applicable retention obligation? Which information can remain in a controlled archive rather than the live transactional system?
Do not assume that copying everything is safest. Unnecessary history can increase transformation complexity, access exposure and reconciliation work. Conversely, excluding records without a usable retrieval plan can make the new process dependent on an old application that was expected to be retired.
Assign owners to the decisions. Business and relevant specialist teams should determine required scope and retention treatment. Technical staff can explain feasibility and cost, but should not silently choose which history the organization no longer needs.
Record inclusions, exclusions, dependencies and the evidence supporting them. A migration scope described only as “active customers and open transactions” still needs definitions of active, open, relevant entities and the cutoff time.
Inspect the source before estimating the final conversion effort. Look at identity, missing values, duplicates, status usage, units, relationships and historical exceptions. Include difficult populations rather than relying only on a clean sample selected for a demonstration.
The UK Government Data Quality Framework defines quality in relation to intended purpose and encourages assessment throughout the data lifecycle. Its government guidance is useful here because a field can be populated yet remain unsuitable for the decision the new system must support. Government Data Quality Framework, 2020.
Distinguish source defects from legitimate differences. Two records with similar names may represent separate legal parties, locations or contractual relationships. An old status may have a business meaning that no current employee remembers immediately. Automated cleansing should not erase those distinctions without approved rules.
Use profiling to create a prioritized issue list with owners. Some problems should be corrected at source; others require a governed transformation or an explicit exception. A spreadsheet of defects without decision ownership is not a migration plan.
For each material transformation, record the source meaning, destination meaning, rule, rationale, owner and test evidence. Preserve a mapping from destination records back to the relevant source identifiers where needed for reconciliation and support.
A transformation may be more than a field rename. It can split one record into several, combine legitimate duplicates, change units, map statuses or derive a new relationship. Each operation needs a rule that can be challenged with examples.
Keep assumptions visible. If the destination requires information that the source does not contain, the team needs a decision about enrichment, a permitted default, an exception or a change in scope. Filling the gap with a convenient value can create false certainty.
Version the rules and retain the configuration used in each rehearsal. When a result changes, the team should be able to determine whether the source changed, the mapping changed or the load behaved differently.
Use checks appropriate to the data and consequence. Record counts can establish whether the expected population was processed. Control totals can reveal some omissions or value changes. Relationship checks can identify records linked to the wrong parent. Scenario tests can establish whether the new process uses the data correctly.
No single check proves everything. A matching total can conceal values assigned to the wrong records. A matching count can include a duplicate replacing an omitted item. A valid foreign key can point to the wrong but existing customer or location.
Define tolerances deliberately. Some transformations legitimately change counts, such as splitting a source object into several destination objects. The expected relationship must be explained and reconciled, rather than treating every difference as an error or accepting every difference as unavoidable.
Give unresolved exceptions a disposition. Correct them, exclude them under an approved scope decision, or accept a documented operating treatment through the appropriate authority. Do not hide them inside an aggregate success percentage.
Consider a hypothetical equipment-maintenance provider moving open service jobs into a new platform. The example is illustrative. The source has 200 open jobs associated with customer sites and individual assets. The first rehearsal loads 200 jobs, and the overall estimated work hours agree with the source.
A relationship check nevertheless finds that twelve jobs are linked to a customer’s headquarters location rather than the actual service site. The destination accepts those links because headquarters is a valid location. Record counts and total hours therefore pass while dispatch information is wrong.
The team traces the issue to a transformation that used the billing location whenever a service-site field was blank. That default was technically convenient but had never been approved as a valid operating rule. Some source jobs recorded the service site in a separate asset relationship instead.
The corrective action is to establish an authoritative rule for resolving the service location, test it against representative asset and site combinations and route genuinely ambiguous jobs for business review. It is not enough to correct the twelve observed records manually if the same rule will run again at cutover.
The next rehearsal checks population, hours, site relationships and a dispatch scenario using the migrated jobs. The team also records which ambiguous items remain and how they will be handled. This produces stronger acceptance evidence without claiming that a small scenario test proves every possible future use.
A rehearsal should test extraction, transformation, loading, reconciliation, exception handling and the decisions that authorize progress. Measure actual elapsed time, resource needs and failure recovery, not just the load step.
Use a representative environment and data volume where feasible. Where a rehearsal differs from production, record the limitation and how the team will address it. A fast run on a small clean dataset should not become an unqualified cutover-duration commitment.
Include repeatability. Can the team reset the target safely, rerun a failed step and distinguish records already processed from records still pending? The required method depends on the platform and migration design, but it must be understood before the final window.
Involve business reviewers in the rehearsal schedule. If reconciliation requires their approval, their availability is part of the critical sequence. A technically finished load waiting for unavailable business acceptance is not a completed migration.
Determine how changes occurring after extraction reach the destination. Options may include a defined freeze, a controlled incremental transfer or another reconciled transition method. The choice depends on the operating tolerance and capabilities of the systems.
Make the boundary precise. A timestamp alone may be insufficient if clocks differ, transactions span the cutoff or updates arrive late. Define how the team establishes a consistent source position and accounts for subsequent changes, including cancellations and corrections.
Decide when the new system becomes authoritative and what actions are allowed before that point. Parallel activity without clear ownership can create conflicting records that neither a later load nor a simple rollback can safely resolve.
Recovery needs the same discipline. If users have begun creating new transactions, restoring the old system may require more than reloading a backup. The team must understand how new activity will be preserved and reconciled. Plan the decision points and evidence before the transition, with appropriate technical and business review.
The acceptance package should identify the approved scope, rules used, completed checks, unresolved exceptions and operational owners. It should also explain how historical records can be retrieved and how users can report a suspected migration defect.
Continue targeted reconciliation after launch. Some issues appear only when real work reaches a less common data condition. Preserve enough traceability to investigate without reconstructing the migration from memory.
Use those findings to correct the cause, including source or transformation rules where applicable. Avoid a growing collection of manual fixes that cannot be reproduced or explained.
Migration deserves early attention because it carries the business’s existing commitments into a new operating model. Begin with one consequential data population, define its future use and prove its relationships through a repeatable rehearsal. The organization should authorize transition because it can explain the resulting information, not merely because a load job finished without errors.
