From Excel to CRM: clean data, map fields and validate a trial import

Decide what deserves migration

An export may mix active enquiries, obsolete lists, tests and fields with unclear meaning. Inventory source, owner, data type, current relevance and reason for transfer before importing everything.

Separate active work from history. Completed enquiries should not reappear as active opportunities. Decide which history the new system needs and what remains in a controlled archive. Migration is not justification for indefinite retention.

Salesforce's migration guide highlights cleanup, mapping, tests and user preparation. The plan below develops those topics into an original checking approach for a simple transition.

Write the mapping first

Record transformations before editing the whole export. Clean a copy and retain the original as a controlled comparison source.

Check dates and decimals. “03/04” is ambiguous; “1.250,50” must retain the correct value. Use explicit formats and inspect imported values.

Deduplicate without destroying different projects

One contact can have several enquiries. Merging people is different from merging opportunities. Examine context, project and source references as well as contact details.

Salesforce's duplicate guidance explains that similar records may need to remain separate and false matches cause problems. Review uncertainty manually. Record source rows and retained values when merging.

Do not replace missing contact details with one shared placeholder. It can make unrelated people appear identical.

Import a representative trial set

Include normal and difficult records: several requests per customer, missing phone, former owner, multiple quotations, accented notes, cancelled appointments and completed opportunities.

Use the agreed test environment. Have future users inspect the records. A successful upload does not establish that history, tasks and documents are correctly related.

Check identity, relationships, text, dates, owner, status and next action. Test permissions too: migrated records might land in an unintended team scope.

Explain count differences

For a fictional example, 500 exported contact rows minus 20 confirmed duplicates and 10 excluded test rows should produce 470 contacts. Related enquiries may have a different count.

Maintain source ID, issue, desired correction, owner and resolution status. Distinguish missing imports, incorrect conversions, broken relationships and duplicated records. Correct recurring patterns before repeatedly repairing individual examples.

Agree cutover and recovery

Decide when the old source stops changing, who creates the final export and how changes since the trial are transferred. Avoid two systems remaining writable for the same process.

Specify whether a failed acceptance check causes delay, repair or return to the earlier process. Name the decision owner and explain how new work since cutover is preserved. A recovery plan must cover more than the original export.

First-day checklist

• Expected counts are reconciled.
• Sample records retain correct relationships and ownership.
• Open tasks remain accessible and current.
• Staff know the new source and issue-reporting route.
• The old system is read-only or closed as agreed.

Continue with implementation and integration design. Migration is complete when the team can perform its work, not merely when upload finishes.