Move Your Detailing Spreadsheet to a CRM Without Losing History

Audit Your Spreadsheet Before Touching the CRM

Before you export a single row, spend thirty minutes reading your spreadsheet like a stranger would. Look for columns that have drifted in meaning over time, notes fields stuffed with unrelated data, and rows where a customer appears under two slightly different names. This audit is where you catch the problems that would otherwise silently corrupt your new system.

Pay specific attention to how you stored vehicle information. Many detailers record make, model, year, and color in a single freeform notes column, which works fine in a spreadsheet but breaks apart badly when a CRM expects discrete fields. Decide now whether you will split that data manually, import it into a general notes field, or leave it in a separate reference document until you have time to enter it cleanly. Each choice has a cost; none of them is wrong if you make it deliberately.

Count distinct customer rows and flag any obvious duplicates before export
Identify every column and write a plain-English description of what it actually contains now versus what it was originally intended to hold
Note any columns that mix data types, such as a status column that sometimes holds a dollar amount or a date
Check for blank required fields, especially phone numbers or emails, that a CRM may reject or require during import
Flag rows that represent businesses or fleet accounts rather than individual consumers, as they may need different handling in the CRM

Build a Field Map Before You Export Anything

A field map is a simple two-column document that matches each spreadsheet column to the corresponding CRM field, or explicitly records that no match exists. Creating this map before you export forces you to think through every data point rather than improvising during a stressful import session. It also becomes your rollback reference if something goes wrong.

Some CRM fields will have no spreadsheet equivalent, and that is fine. What you are trying to avoid is the reverse: spreadsheet columns that contain real information but have nowhere to land in the CRM. Those columns need a decision. You can create a custom CRM field if the platform supports it, consolidate the data into a notes block, or accept that it will be archived in the original spreadsheet and not migrated. Whatever you decide, document it in the map so you are not guessing six months later.

FIELD MAPPING WORKSHEET

Spreadsheet Column | CRM Field | Notes / Decision
-------------------|-----------|-----------------
First Name         | Contact: First Name | Direct match
Last Name          | Contact: Last Name | Direct match
Phone              | Contact: Primary Phone | Standardize to 10-digit format before import
Email              | Contact: Email | Flag blanks; do not import blank rows if email is required
Vehicle Info       | Contact: Notes (Vehicle) | Freeform; add prefix VEH: for searchability
Last Service Date  | Custom Field or Notes | Verify CRM supports date custom fields; otherwise use Notes with ISO date format YYYY-MM-DD
Service Type       | Tags or Job Type Field | Map common values; archive rare or one-off entries in notes
Lifetime Value     | Notes or Budget Field | Import as informational reference only; recalculate in CRM going forward
Referral Source    | Lead Source Field | Normalize values before import (e.g., Google, Word of Mouth, Repeat)
Internal Notes     | Contact: Notes | Review each row manually before migrating sensitive comments

Columns with NO CRM destination:
- [Column name]: Decision: [Archive in spreadsheet / Create custom field / Discard]

Reviewed by: ____________  Date: ____________

Deduplicate Before Import, Not After

Deduplication after import is painful because the CRM may already have generated activity records, tasks, or appointment stubs tied to both versions of a duplicate contact. Merging them after the fact often requires manual work and risks losing whichever version you collapse. Doing it in the spreadsheet first, while everything is still flat rows, is far faster.

The tricky cases are not the obvious ones where a name appears twice. The hard calls are husband-and-wife accounts sharing one phone number, a customer who gave you a cell number one year and a work number the next, or a business account where you also have the owner listed as an individual. Decide your rule for each scenario and apply it consistently. A shared household phone number does not automatically mean the same contact record; think about whether appointment history needs to stay separate for service differentiation purposes.

Sort by phone number first, then by email, to surface duplicates that use different name spellings
For true duplicates, keep the row with the most complete data and note the discarded row's unique information in the surviving record's notes field
For shared-phone household accounts, decide whether one contact record or two better serves how you schedule and communicate
For business versus individual overlap, consider whether you want a separate company record linked to a person record, or a single record with business name in a dedicated field
Document every merge decision in a separate tab so you can trace it if a customer later says their history is missing

The Dry-Run Checklist: Import Five Rows First

Never run a full import as your first import. Select five rows that represent the range of your data complexity: one clean simple contact, one with unusual characters in the name, one with a notes field that is long or contains commas, one with a missing email, and one that is a business account. Import only these five and inspect each one in the CRM before proceeding.

The dry run tells you whether your field map is actually working, whether long text fields are being truncated, whether special characters are causing parsing errors, and whether the CRM is treating your date formats correctly. Fixing these issues on five rows takes minutes. Fixing them on five hundred rows after the fact can take hours or may require a full delete and reimport, which introduces its own risks.

DRY-RUN VALIDATION CHECKLIST (complete for each of 5 test rows)

Contact imported: [ ] Yes  [ ] No
First and last name match source: [ ] Yes  [ ] No
Phone number format correct: [ ] Yes  [ ] No
Email present and correct: [ ] Yes  [ ] No
Notes field complete and not truncated: [ ] Yes  [ ] No
Custom fields populated correctly: [ ] Yes  [ ] No
Date fields parsed correctly: [ ] Yes  [ ] No
Tags or categories applied as expected: [ ] Yes  [ ] No
No unintended duplicate created in CRM: [ ] Yes  [ ] No

Issues found:
1.
2.
3.

Resolution before full import:
1.
2.
3.

Approved to proceed with full import: [ ] Yes  [ ] No
Reviewed by: ____________  Date: ____________

What to Do When the Full Import Goes Wrong

Even with a successful dry run, a full import can produce unexpected results because edge cases in your data only reveal themselves at scale. Before you run the full import, note the current contact count in the CRM so you have a baseline. If the CRM supports an import log or error report, download it immediately after the import completes and read it before doing anything else.

If the import created a large number of malformed records, the cleanest recovery path is usually a bulk delete of the imported batch followed by a corrected reimport, assuming you can identify the imported records clearly. This is why keeping your original spreadsheet intact and unmodified throughout the migration matters. It is your ground truth. Do not modify the spreadsheet to fix a CRM problem; fix the problem in a copy of the spreadsheet and reimport from the corrected copy.

Record the pre-import contact count in the CRM and compare it to the post-import count against your expected net-new additions
If the CRM provides an import error log, review every flagged row before dismissing the report
Identify imported records by import date or a temporary tag applied during import, so you can isolate and delete them if needed
Keep your original spreadsheet read-only and your corrected working copy clearly labeled with the date and what changed
If partial data landed correctly and partial data did not, correct only the affected rows rather than reimporting the entire file, to avoid creating new duplicates

Hypothetical Worked Scenario: Marcus Migrates 340 Contacts

Marcus runs a solo mobile detailing operation and has been tracking customers in a single Google Sheet for three years. His sheet has 340 rows, but after sorting by phone number he finds 28 apparent duplicates, mostly repeat customers who contacted him through different channels and got entered twice. He creates a separate Duplicates tab, resolves each one manually, and ends his audit with 312 unique contacts. He also discovers that his notes column contains a mix of vehicle descriptions, customer preferences, and one-time reminders he never deleted. He adds a VEH: prefix to vehicle entries and a PREF: prefix to preferences, then moves the stale reminders to a Done column he will not import.

Marcus builds his field map and finds that his spreadsheet has no equivalent for the CRM's lead source field. He decides to leave it blank for historical records and commit to capturing it on all new leads going forward. He runs his five-row dry run, discovers that his date format is MM/DD/YYYY but the CRM expects YYYY-MM-DD, and fixes the entire column in his working copy using a spreadsheet formula before proceeding. The full import of 312 contacts completes with four errors, all related to one customer whose name contained an ampersand in a business name field. He corrects those four rows and reimports just them. His total active time is about four hours spread across two evenings, and he ends with a cleaner dataset than he had in the spreadsheet, including consistent date formats and searchable vehicle notes.

Validate the Import Before Going Live

Spot-checking ten to fifteen contacts after a full import is not enough validation if you have several hundred records. A more reliable approach is to cross-check the total row count, run a search for several customers you know well and verify their data looks right, check that your oldest customer records are present, and pull up at least one business account to confirm it was handled the way you decided during field mapping.

Also validate the data you chose not to import. Pull up a contact whose notes field in the spreadsheet was particularly dense and confirm the relevant parts made it into the CRM. If you used a PREF: or VEH: prefix system, search for that prefix in the CRM's notes search to confirm it is working and returning results. This is also the moment to confirm that the original spreadsheet is archived somewhere stable, not just sitting in a Downloads folder.

Validation Check	How to Verify	Pass Criteria
Total contact count	Compare CRM contact count to final spreadsheet row count after deduplication	Counts match within expected import errors
Known customer lookup	Search for 5 customers by name and by phone	Records appear with correct name, phone, email, and notes
Oldest record present	Look up your earliest customer from the spreadsheet	Record exists with notes intact
Business account format	Pull up one fleet or business contact	Business name and contact name handled per your field map decision
Notes prefix searchability	Search notes for VEH: or PREF: prefix	Results return expected contacts
Date fields	Open 3 records with last-service dates and check format	Dates display correctly and sort chronologically
Duplicate check	Search by phone for a number you know appeared twice in the original sheet	Only one record exists
Archived spreadsheet	Confirm original unmodified spreadsheet is saved in a known location	File is present, dated, and read-only

Using Weavr After Migration: Connecting Contacts to Workflow

Once your contacts are in Weavr, the migration payoff comes from connecting those records to actual work. You can link contacts to quotes, requests, and appointments, attach tasks directly to jobs, and use the scheduling tools to set up recurring appointments for customers who appeared frequently in your spreadsheet history. The Google Calendar two-way sync lets appointments you schedule in Weavr reflect on your work calendar and vice versa, which matters when you are coordinating a newly organized contact list with an existing calendar. Budget projection and reporting tools become more useful as you populate appointment history going forward, since the migrated data gives you a reference baseline for who your regulars are even before the CRM has its own built-up history.

The value of the migration is not just having data in a new location. It is that the data is now connected to a workflow where leads, quotes, scheduled jobs, and follow-up tasks are linked to the same contact record. That connection is what a spreadsheet cannot provide, and it is the practical reason the migration is worth the effort.

The practical takeaway

Audit and deduplicate your spreadsheet before touching the CRM, build a written field map, run a five-row dry run before the full import, and validate with a structured checklist after. Keep your original spreadsheet intact and unmodified throughout as your rollback reference. The migration itself is a few hours of focused work; the payoff is customer history that is now connected to your scheduling, quoting, and follow-up workflow instead of sitting in a static file.

Explore the relevant WeavrCRM workflow · Review integrations and requirements