A migration can copy every row and still leave a product unusable. An active customer appears archived. A familiar status acquires a different meaning. A historical record loses the connection that made it understandable.
The engineering task is to move data correctly. The product task is to preserve the meaning that people rely on. Both need a place in the release plan.
Agree on meaning before mapping fields
Consider moving service requests from an older application into a new one. The old system has a status called “closed,” but teams use it for completed work, duplicate requests, and requests withdrawn by the customer.
Mapping that value into one new status preserves the text while potentially losing the distinction the new product needs. The team must decide whether the source contains enough evidence to separate those cases and what to do when it does not.
Do not make uncertain records look more certain than they are. A documented exception or preserved original value may be more useful than an apparently clean but unsupported interpretation.
Work through a representative sample with people who know the records. Include old, incomplete, unusual, and recently changed examples. The easiest records are useful for getting the mechanism running; they do not establish that the mapping fits the product.
Rehearse what users will actually do
Counts and validation rules are necessary checks, but add task-based review. Can someone find an existing customer, understand the history, continue unfinished work, and explain a discrepancy?
Compare the source and destination using stable identifiers and explicit mapping rules. Keep a record of exceptions and how they were resolved. If the migration is repeated during rehearsal, make sure the process does not silently duplicate work or overwrite a correction made after an earlier run.
A rehearsal should also measure the operating steps around the transfer: how long access is restricted, who validates the result, and which decision allows normal work to resume. These details shape the customer's experience of the change.
Plan for work that continues during the move
The business may keep creating and updating records while the new system is prepared. Decide how those changes reach the destination and when each system becomes authoritative.
Explain the return path if the release cannot proceed. Restoring an earlier copy is not automatically a complete rollback if new work has been accepted elsewhere. The plan needs to account for that work and the people depending on it.
Finally, give support a way to investigate reported differences. A customer should not need to understand a migration script to explain why a record looks wrong.
Treating migration as a product release changes the acceptance question. It becomes “Can people continue their work with the information they need?” rather than only “Did the transfer finish?”