Operations
Moving from spreadsheets to a CRM: a practical migration checklist
Move your spreadsheet into a CRM with a clear plan for field mapping, duplicate records, test imports, ownership and a final check before your team switches.
Start with the work recorded in your spreadsheet
To move from spreadsheets to a CRM, preserve the original data, agree what each field means, test a small import, then reconcile the results before switching.
The migration needs to preserve the work behind each row: who owns the enquiry, what was discussed and what happens next. A contact list with those details missing leaves your team doing detective work after the move.
Choose one person to own the migration and one person who uses the current sheet daily to review it. Start with the sheet your team actually updates. Include the notes and exceptions people rely on, even if they live in an untidy column.
1. Save an untouched copy and define the cut-off
Save a dated copy of every source file before editing. Keep it separate from the working copy and restrict changes to it. Record which sheet, tab and export date supplied each batch, so a disputed record has a traceable source.
Agree when the team will stop editing the old sheet. If enquiries continue arriving during the migration, keep a separate change log with an owner responsible for carrying those additions across. Avoid leaving two editable systems in use without deciding which one holds the current record.
2. Give each column a destination
Field mapping means deciding where each spreadsheet column belongs in the CRM. Write the mapping down before importing. Keep a source row identifier, such as a stable record ID, to help trace individual rows through the process.
The table below is a suggested starting point, rather than a required Atlas import format. Confirm the accepted fields and file format for your agreed setup.
| Spreadsheet field | Decision before import |
|---|---|
| Contact name and company | Keep the person and the business distinguishable. |
| Phone or email | Agree formatting and the rule for identifying a duplicate. |
| Salesperson | Map each name to the correct active team member. |
| Status | Map old labels to a clearly defined CRM stage. |
| Follow-up | Separate the next action from its due date. |
| Notes | Preserve useful context and identify entries needing review. |
3. Resolve duplicates without guessing
Review records that share a phone number or email address before merging them. A shared office number does not prove that two contacts are the same person. Agree which fields establish a match and who decides uncertain cases.
Preserve conflicting notes for review instead of keeping whichever cell happens to appear last. If two salespeople have spoken with the same contact, decide the future owner and retain the useful conversation history.
Standardise stage names, date formats and owner names in the working copy. Put missing values on an exception list. An empty follow-up date is a question for the owner, not an invitation to invent a deadline.
4. Test the awkward records first
Ask for a test import before sending the full file. Choose a sample that includes blank fields, long notes, shared numbers, different stages and records assigned to different people. A sample made entirely of clean rows tells you little about the difficult cases.
Open the resulting records with the people who will use them. Check whether a teammate understands the next action without returning to the spreadsheet. Confirm how rejected rows and duplicates are reported, and how a mistaken test import will be removed before the full migration.
- Compare names, contact details and notes with the source rows.
- Check stage, owner, next action and due date on each sample record.
- Confirm that each team member sees the records appropriate to their agreed access.
- Resolve sample errors and repeat the affected checks before proceeding.
5. Reconcile the full import and make the switch
Count the source rows, successful imports, rejected rows and deliberately merged or excluded records. Keep these categories separate and explain every difference. Matching total counts alone is insufficient if records were assigned to the wrong owners or mapped to the wrong stages.
Compare counts by owner and stage as well. Review a fresh sample after the full import, then carry across the change log created during the migration. Ask the migration owner to record that the checks are complete.
Mark the old sheet as an archive and make it read-only where practical. Tell the team where new enquiries belong and who handles missing records. Keep the untouched source and migration notes under your business's agreed retention and access arrangements.
Bring a representative sheet to the setup conversation
Atlas includes lead import, duplicate handling, assignment and configurable sales stages. Its setup starts with understanding your existing workflow. Confirm the import format, mapping, responsibilities and acceptance checks with the builders for your particular migration.
For an initial discussion, share an anonymised sample that preserves the structure of your sheet. Include a few awkward records and explain why they matter. That gives the conversation something concrete to work through before any live customer data moves.
Put it into practice
Show us the sheet your team works from.
Talk through your fields, stages and migration checks with the people who build Atlas.
Talk to the builders