An accepted import is not yet usable data
A new system may accept every row while users still cannot find the right contact or continue an open job. What matters is whether data retains its meaning and relationships. Before transferring anything, ask what work the team must be able to complete on day one.
List concrete tasks. Sales needs to open an active job and its contact; a coordinator needs its deadline and assigned person; management needs a comparable report. These tasks define which information must be complete. The transferred record count is only one part of verification.
Decide what moves and what remains in an archive
Separate information needed for ongoing work from history mainly needed for lookup. For each group, identify the decision owner, source, and access method after the move. Do not migrate everything simply because export supports it, or exclude data without agreement from those who need it.
For an archive, check search, access permissions, and how an old record connects to the new system. Open cases may depend on older attachments or correspondence. Creation dates alone should not decide the scope.
- Active contacts and current reference lists.
- Open jobs, including status and ownership.
- Attachments and relationships needed to continue work.
- Historical records with an agreed lookup method.
- Excluded information with a reason and approver.
Record a conversion rule for each field
Map source fields to target fields. A job title may transfer directly, while a status or category needs a decision. Old labels such as 'open' and 'waiting' may not represent the same stage in the new workflow. Rules should explain meaning rather than name similarity.
Handle empty values, date formats, units, and identifiers explicitly. Jobs must remain attached to the correct customer even if internal numbers change. Keep a traceable link between old and new records. Flag unknown values for a decision instead of filling them with information that appears verified.
Resolve duplicates using rules
Two similar names do not necessarily identify the same customer. They may represent branches, different contacts, or separate companies. Before merging, define identity criteria, the surviving record, and what happens to linked jobs.
Ask the data owner to confirm ambiguous cases. Record corrections and retain original values so changes can be explained. Distinguish verified repairs from guesses when numbers or contacts are missing. Migration should not hide uncertainty behind a polished new form.
Verify a trial transfer through everyday tasks
Have staff perform the prepared tasks after a trial import: find a job, open an attachment, make an authorized status change, and produce a report. Include incomplete, older, and unusual records. Check selected cases from source to result, recording expected outcomes and differences.
Compare counts by group and relevant totals. Changes caused by approved duplicate merges should be explained. A missing contact or a job linked to the wrong company must not disappear inside an overall total. Track rejected rows, reasons, and who will resolve them.
Define the cutover boundary and return procedure
Agree when entries stop in the old system and start in the new one. If new cases arise during transfer, define how they are added and who checks completeness. Parallel work without a clear rule can create two conflicting versions of the same job.
Before launch, decide which defects require postponement and who can approve proceeding. Prepare a backup, a verified restoration method, and a procedure for records created after cutover if a return becomes necessary. Returning involves preserving the team's new work as well as restarting the old system.
- Final export time and responsible person.
- Data checks required before launch.
- Open discrepancies and a decision for each.
- Rules for new cases during cutover.
- User support and an issue-reporting channel.
Accept migration together with the workflow
A completed migration should have agreed scope, recorded conversion rules, and verification results. Users should be able to find information, continue open cases, and recognize problems. During the first days, watch whether staff need another spreadsheet to work around the new system.
If you are replacing an internal system, bring a list of data sources, an anonymized sample, and the users' main tasks to a consultation. At DAVOND, we can review the transfer scope and uncertainties so migration is planned alongside the new workflow rather than left until the final step before launch.