Moving spreadsheet records into a CRM is a data and workflow decision, not just a file upload. This preparation checklist helps a small team agree what should move, who reviews it and how to handle a problem before live records are involved.
A reference you can compare against.
Check formats, missing values and possible duplicates.
Compare counts, field placement and access. Pause and correct the mapping if the sample is wrong.
Illustrative field mapping. Check the selected CRM’s actual import rules before moving records.
Name an owner and protect the source
Choose one person to coordinate the preparation and record decisions. List each spreadsheet, where its current copy is kept, who maintains it and which team uses it. Keep an unchanged source copy in the business-controlled location before any cleanup. Agree who may make a working copy and where that copy may be stored.
- List workbook and sheet names, their purpose and the person responsible for each.
- Record when a sheet was last updated and whether another system is the authoritative source.
- Identify formulas, hidden columns, notes, attachments or linked sheets that may affect meaning.
- Decide who approves field definitions and who resolves records that do not clearly match.
Do not send customer-level records for an initial scope discussion. A blank template or synthetic rows can show the column structure without exposing actual people.
Define fields and review duplicates
For each column, write down what it means, an example value, whether it is required and where it should go in the proposed CRM. Distinguish a missing value from a value that is not applicable. Agree how names, phone numbers, email addresses, dates and status labels should be represented before anyone edits the working copy.
Similar-looking rows are not automatically the same customer. Set a review rule and a person responsible for uncertain matches. The rows below are fictional and illustrate a preparation discussion only; they are not a tested import or a recommendation for a particular product.
| Source ID | Source values | Possible CRM fields | Review decision to make |
|---|---|---|---|
| S-104 | Riya Sen; riya@example.com; “New enquiry” | Name; email; stage | Confirm that “New enquiry” maps to the agreed stage label. |
| S-219 | R. Sen; riya@example.com; “Follow up” | Name; email; stage | Same email as S-104, but could describe a separate interaction. Review history before merging. |
| S-305 | Riya Sen; no email; “New” | Name; email; stage | Agree whether email is required and how an incomplete possible match is handled. |
Choose what to move and who can see it
A migration does not need to include every old column or record. Mark fields and records that are out of scope, no longer useful or need a separate decision. Minimise what is copied into the new system, and identify any information that should remain in its current approved location.
- List which roles need to view records, add them, change them or export them.
- Decide who can resolve duplicates, edit key definitions and approve access changes.
- Ask the selected provider how its current roles and export options fit those needs.
- Agree who owns records after migration and how staff hand over follow-up when responsibilities change.
These are scope questions, not a privacy or security compliance assessment. Sensitive customer records should be redacted or replaced with synthetic examples during preliminary planning.
Plan cleanup and a small review
Before changing a working copy, define a few cleanup examples: inconsistent stage names, blank required fields, malformed dates or possible duplicates. Agree the intended correction and who may approve it. Keep a note of changes so that a reviewer can compare the result with the source.
With the chosen provider and responsible staff, plan a small sample migration using synthetic or approved low-risk records. Review field placement, counts, missing values, duplicates and access before deciding whether to proceed. The provider’s actual import and export behaviour must be checked for the selected account and setup; this guide does not test an import.
Agree backups, rollback and handover
Decide where the untouched source and any approved export will be kept, who can access them and how long they should remain available under the business’s own policies. Before a larger move, write down who can pause the work, what condition triggers a rollback, which copy is authoritative during review and how records changed after the export will be reconciled. Confirm the steps with the chosen provider; do not assume that restoring a spreadsheet automatically reverses CRM edits.
Finish by assigning ownership for routine updates, duplicate questions, access requests and future exports. A staff walkthrough should use the agreed definitions and show where to raise an uncertainty, rather than asking each person to invent their own labels.
For a scoped discussion, see the CRM setup and migration service. If records also need to move between systems, the software integration service may be relevant. Start with a summary of the current sheets, owners and decisions still open, or contact VikaSquare.