Most spreadsheet-to-CRM moves don't fail on the software. They fail on the data: three versions of the same customer, a "notes" column holding five years of half-sentences, and a phone number field where someone typed "ring after 3". A CRM migration is mostly a cleaning and sorting job with an import at the end, and if you plan it that way it goes well.
This is the order we work through when moving a business off spreadsheets. It suits a small or mid-sized business doing it with help or on its own, and nothing in it requires special tools beyond the spreadsheet software you already have.
Step 1: find every spreadsheet that matters
The first job is an inventory, and it's almost always bigger than the owner expects. Take a hypothetical landscaping business. The owner thinks there's one customer list. Then the office manager mentions the quotes tracker, the estimator has his own sheet of commercial contacts, there's a maintenance-round schedule on a shared drive and someone keeps supplier contacts in a notebook by the phone.
Ask everyone, not just the boss. For each file, write down:
- What it holds (customers, leads, quotes, jobs, suppliers).
- Who updates it, and how often.
- Whether it's the master copy or a copy of something else.
- Roughly how many rows, and how far back it goes.
Don't forget the data living outside spreadsheets: contacts in phones, an email marketing list, the accounting package's customer list. Your accounting software is usually the cleanest source for billing names and addresses, so it's worth comparing against early on.
Where two sources disagree, decide now which one wins. If the quotes tracker and the customer list have different mobile numbers for the same person, which is more likely to be right? Usually it's whichever gets updated when the customer actually rings. Write that rule down so whoever does the cleaning doesn't have to guess each time.
Then freeze the structure. Tell the team not to add new columns or start new sheets until the move is done. Rows can keep coming in; the shape of the data has to stop changing.
Step 2: clean and de-duplicate
This is the slow part, and it's the part that decides whether the new system is trusted. Work on a copy, never the original.
Start with duplicates. Excel's built-in tools can either filter for unique values or remove duplicates, and Microsoft's own help page on filtering for unique values or removing duplicate values makes the key distinction clear: filtering only hides duplicates, while removing them deletes them permanently. On a customer list, filter and review before you delete anything. "J. Nguyen" and "Jenny Nguyen" at the same address are probably one person; two Smiths in the same suburb may well be two.
Then standardise. Pick one format for phone numbers, one for dates, one for states (VIC, not Vic or Victoria). Split full names into first and last if the CRM wants that. Move anything that isn't the field's job, like "ring after 3" in the phone column, into a notes field.
If you hold personal information, accuracy isn't just tidiness. Under Australian Privacy Principle 10, organisations covered by the Privacy Act must take reasonable steps to keep personal information accurate, up to date and complete; the OAIC's guidelines on APP 10 and the quality of personal information explain what that means. This is general information, not legal advice, so check how the Act applies to your business.
Step 3: map your fields to the CRM
Field mapping is where you decide, column by column, where each piece of spreadsheet data will live in the new system. Do it on paper (or a simple two-column sheet) before you touch an import screen.
Three things come up every time:
- Columns that don't fit anywhere. Either create a custom field, fold them into notes, or decide they're not worth keeping.
- One column that should be several. An "address" column holding street, suburb and postcode together needs splitting so you can filter by suburb later.
- Free text that should be a choice. If "lead source" has forty spellings of "Google", turn it into a short drop-down list and map every variation to one value.
Pay special attention to marketing consent. If your sheet records who has unsubscribed or never agreed to marketing, that status must come across and be respected by the new system from day one. Our plain-English guide to Spam Act rules for automated emails and SMS explains why this matters.
Step 4: decide how much history to bring
Here's where I differ from a lot of advice: you don't have to bring everything. I'd rather a business left ten years of stale history in an archived spreadsheet than imported it badly and cluttered every customer record with noise.
A sensible split for many small businesses looks like this. Bring across every current customer and open lead, every open quote and job, and recent closed work (often the last two or three years) so the team can see a customer's recent history. Leave older closed jobs in a read-only archive that anyone can still open. Financial records generally live in your accounting software already; ask your accountant which records you must keep and for how long.
There's a privacy angle here too. The OAIC's guidelines on APP 11 and the security of personal information explain that APP 11 requires covered organisations to take reasonable steps to destroy or de-identify personal information once it's no longer needed for any permitted purpose, unless a law requires them to keep it. A migration is a natural moment to ask whether you still need all of it.
Step 5: test the import on a copy
Never do the first import into the live system. Use a test copy or a sandbox, and import a small sample first: twenty or thirty records chosen to include the awkward ones. The customer with two sites. The one with an apostrophe in the surname. The record with a blank email. The one with notes that run to a page.
Check them by eye against the spreadsheet. Did dates flip from day-month to month-day? (A classic when a file passes between programs set to different regional formats.) Did the leading zero drop off phone numbers? Did postcodes starting with zero, like Darwin's 0800, survive? Did long notes get cut short?
Don't forget attachments. Photos of past jobs, signed quotes and site plans often sit in folders named after customers rather than in the spreadsheet itself. Decide whether they're coming across, and if they are, how each file will be matched to the right record. Matching on a customer name is fragile; matching on an email address or a customer number is much safer.
Fix the mapping, re-import, check again. Then run the full import into the test copy and compare totals: same number of customers, same number of open quotes, same total value of open quotes. If the numbers don't match, find out why before going further.
Step 6: plan the cut-over day
Cut-over is the moment the spreadsheets stop being the master and the CRM takes over. Make it a specific date and time that everyone knows.
- Pick a quiet day. Not the end of the month, not the Friday before the Christmas shutdown. A midweek morning is usually best, because problems surface while everyone's around to fix them.
- Take a final export of every spreadsheet and lock the originals as read-only.
- Run the final import using the mapping you tested.
- Repeat the total checks from step 5.
- Switch on the connections (email, calendar, accounting, website forms) and send a test enquiry through each one.
- Tell the team the spreadsheets are closed. Anything new goes in the CRM.
Keep the locked spreadsheets for a while. You'll want them when someone asks "what did that old note say?"
Step 7: train the team before they need it
The business.gov.au page on digital tools for business makes two points that apply directly here: train staff to use new tools before they need to use them, and ease people into the change rather than flipping everything at once. Short sessions built around each person's actual tasks beat a two-hour tour of every screen.
Give each role the three or four things they do most and show them just those. Name one person the team can ask questions in the first fortnight. And expect a dip. People will be slower for a week or two, and someone will keep a private spreadsheet "just in case". Gently close that door, or you'll end up running two systems.
What goes wrong in a CRM migration, and how to avoid it
The same handful of problems turn up again and again:
- Duplicates come back. If the web form, email and phone each create a new contact, you'll rebuild the mess within months. Make sure new enquiries are matched against existing records.
- Old habits survive. If the owner still asks for "the spreadsheet", the team will keep one. Ask for reports from the CRM.
- Nobody owns data quality. Give one person the job of a quick monthly tidy.
- Connections fail quietly. A sync that stops without telling anyone is worse than no sync. Ask how failures are reported.
- Too much at once. Moving data, changing processes and adding automation in the same week overloads everyone. Move first, improve second.
Moving data across from spreadsheets or another CRM is part of every custom CRM build we do, along with the connections described in our system integrations service. If you're still weighing up what to move to, our guide on choosing between custom and off-the-shelf CRM is a good place to start, and you can talk to our team about your migration on a 30-minute call.
— Craig Winder, Founder
