Identify the source of truth
A customer may appear in a spreadsheet, an old database and a staff member’s notes. Decide which source wins when records disagree. Map names, statuses, dates and units explicitly. Keep an authorised original copy so the team can investigate discrepancies.
- List the source systems and file owners.
- Define required fields and acceptable missing values.
- Resolve duplicate identities before importing.
Rehearse with a representative sample
Choose examples that include ordinary records and difficult cases: archived customers, unpaid balances, reused identifiers or missing dates. Test the agreed import process and review the resulting records with the people who understand them. A row count alone cannot confirm that the data means the same thing.
- Compare record counts and financial or quantity totals where relevant.
- Check linked records and attachments.
- Document rejected rows and their correction process.
Control the changeover
Agree a cutover window and what happens to changes made during it. Avoid two teams updating different systems as if both were the final record. Verify the new system after launch and keep a clear route for reporting an incorrect opening position.
- Name the person who approves the migration.
- Agree fallback criteria before the cutover.
- Preserve access controls and retention rules during transfer.
Questions, answered
Can a developer infer missing balances or dates?
They should not invent business facts. The data owner must resolve or explicitly accept missing information.
What proves that an import worked?
Use counts, totals, sampled records, relationships and business-owner review together.
Should old data be deleted immediately?
No. Follow the agreed retention and recovery process, with appropriate access controls.