November 9, 2026 · Faith Forge Labs Editorial Team
Moving Business Data Without Losing Track of What Changed
Moving records is only part of a migration. Decide what should move, how it maps to the new system and how the business will check the result before switching over.
A new system can be ready while the information moving into it is not. Old labels may mean different things, a field may contain several kinds of information or staff may have used free-text notes to work around missing features.
That makes data migration a business decision as well as a technical task. Agree what the records should mean in the new system before asking someone to import them.
Decide what moves and what stays behind
List the information needed for the new workflow and identify who can decide how it is handled. Separate active records from material that may be retained elsewhere under the business's established retention rules. Do not treat migration as permission to copy everything into every environment.
For a hypothetical stock system, an item might have several names in the old application but one identifier in the new one. The team needs an agreed matching rule. Guessing from similar names could merge things that should remain separate.
Use a field map: source field, destination field, any conversion rule and the person who approves it. Make unknown or missing values explicit.
Rehearse with a controlled sample
Begin by testing the mapping and import process with fictional or appropriately protected data in a suitable environment. Include ordinary records and awkward cases: missing values, long text, unusual characters, duplicate candidates and linked records.
When authorised real-data rehearsal is necessary, restrict access and protect that environment to match the information involved. Avoid copying private records into a developer's informal test setup or putting them into issue screenshots.
Ask the people who use the information to check the result. A valid import file can still put a telephone number in the wrong place or change the meaning of a status.
Check completeness and meaning separately
Compare record counts and investigate differences, but do not stop there. Matching totals can hide missing records balanced by duplicates. Check identifiers, important values and relationships between records, as well as what users see when completing a real task.
AWS DMS documentation treats data validation as a separate migration activity, with failed, pending and suspended outcomes as well as validated records. The available checks depend on the tool and source involved; a completed transfer is not a universal proof that all data is correct.
Keep a reconciliation record explaining what was compared, which exceptions remain and who accepted the result.
Plan the switch and the way back
Decide when staff stop changing the old system, how later changes will be handled and who authorises the final switch. Tell the people doing the work which system becomes authoritative and when. Leaving both editable without a plan invites disagreement between them.
Agree what would stop the switch and what rollback actually means. Restoring an earlier snapshot may discard work entered since that snapshot, so account for new activity before treating rollback as a simple undo button. Keep the original source protected until the agreed checks and retention decisions are complete.
A migration is ready when the process has been rehearsed, the business has checked the result and unresolved exceptions have owners. If you are changing platforms, our modernization decision guide provides context. For a migration planning discussion, describe the two systems and the kinds of records involved without sending the records themselves.