The CSV Migration Playbook: Spreadsheets to Client CRM

What a client-list migration actually involves

A client-list migration moves every client record out of spreadsheets into one database, in five steps: consolidate to a single sheet, clean the fields filings depend on, map columns to the import template, run the import, and verify before retiring the spreadsheet.

The work is almost entirely in the cleaning. The import itself takes minutes; deciding which of three conflicting fiscal year-ends is correct takes judgment, and doing that once — now, deliberately — is the entire value of the exercise.

Step 1 — Consolidate to one sheet

Gather every place client data lives — the master spreadsheet, a partner's personal version, the billing export, the paper file — and merge them into one sheet with one row per client. Duplicates and conflicts surface here, which is the point.

Resolve conflicts in favour of source documents: the legal name as registered, the fiscal year-end from the articles or the last T2, the contact who actually replies. A migration that imports the conflict just relocates it.

Step 2 — Clean the fields filings depend on

Clean the load-bearing fields first: legal name exactly as registered, fiscal year-end, client status, and at least one working contact per client. These drive deadlines and correspondence — a typo here surfaces at filing time, not import time.

Everything else — plan, assigned manager, notes — improves the record but does not break a deadline if it arrives later. Tidy those after the import, once the load-bearing fields are safely in.

• Legal name — as registered, not the trade name in an email signature
• Fiscal year-end — one value, checked against the last return filed
• Status — active, prospect, dormant or departed, decided honestly
• Contacts — a named person with a designation, not a shared inbox

Step 3 — Map columns to the import template

SpidNums imports clients from CSV or XLSX against a downloadable template, so mapping means renaming and reordering your cleaned columns to match it. Do the mapping in the spreadsheet, where mistakes are visible and reversible.

Where your sheet holds data the template does not cover — referral source, ledger software, preferred language — keep those columns. Admin-defined custom fields can hold that data on the client record once the clients are in.

Step 4 — Create custom fields for what your firm tracks

An admin defines custom fields for the data your firm genuinely tracks and the standard record does not: referral source, ledger software, preferred language, anything the firm reports on. The client record should end up holding what the spreadsheet held — all of it.

Resist inventing fields nobody has ever filled in. The spreadsheet's columns are an honest record of what the firm actually tracks; mirror those, and add new ones when a real need appears.

Step 5 — Import, then verify before retiring the sheet

Run the import, then verify: the record count matches the sheet, spot-checked clients show the right year-end and contacts, and a search for a known client finds them. Only then does the spreadsheet become read-only history.

Keep the final sheet as a dated archive that is never edited again. The failure mode to avoid is the half-migrated month where some staff update the database and others update the sheet — retire it visibly, the same week.

What changes once the spreadsheet retires

After migration, the client record starts working: services with cadences drive next-due dates, the Reminders feed aggregates deadlines from the data you cleaned, and export to CSV or XLSX stays available at any time — migration in is not lock-in.

Firms in this position typically notice the change at the first deadline run: instead of scanning a sheet for red cells, the Overdue, Due soon and Upcoming groups are computed from the records — and they are only as good as the year-ends cleaned in step 2.