Preparing your data before migrating to a CRM

The import is the easy part. The preparation is where a migration succeeds or quietly fails.

Import dirty data and you spend the next year not trusting your own CRM. Nobody says that out loud; they just keep using the spreadsheet.

Start with one file

If your data lives in several places — a spreadsheet, an old system’s export, someone’s contacts — consolidate into a single sheet first. Do the hard thinking once, in a tool where sorting and filtering are fast.

Add a source column as you combine. When something looks wrong later, you will want to know where it came from.

Deduplicate properly

Duplicates are the single biggest cause of distrust in a new CRM.

1. Sort by email and scan for repeats. Email is your most reliable key.
2. Sort by phone, normalised — strip spaces, dashes and country-code variations first, or the sort is meaningless.
3. Sort by company name and look for near-matches: Acme Ltd, Acme Limited, ACME.

When merging, keep the most recent activity date and the most complete contact details. Note the merge in a comments column so the decision is auditable.

Normalise the fields that will be filtered on

Anything you will later group, filter or report by needs consistent values:

• Phone numbers — pick one format and apply it to all.
• Company names — one canonical spelling each. Decide about suffixes and be consistent.
• Stage and status — map every legacy value to exactly one of your new stages. Write the mapping down before you start.
• Owner — must match a real user who will exist in the new system. Records assigned to someone who left are records nobody will action.
• Dates — one format, ideally YYYY-MM-DD, which sorts correctly as text.

Free-text notes do not need normalising. Do not spend time there.

Decide what not to bring

This is the step people skip, and it is the highest-value one.

• Leads with no activity for over two years
• Records with no email and no phone — you cannot contact them, so they are not leads
• Test and placeholder records (asdf, Test Customer, your own name)
• Contacts at companies that no longer exist

Archive them in a separate file. You are not deleting history, you are keeping it out of the working system. A CRM with 800 real records is more useful than one with 4,000 where half are dead.

Structure it the way the CRM thinks

Most CRMs, MyERPZ included, separate the organization from the person: a customer company, and contacts belonging to it. Spreadsheets usually flatten this into one row per person, with the company name repeated.

Split it before import: one sheet of companies, one of contacts with a company reference. Doing this afterwards means editing every record by hand.

If your business tracks inventory — units, towers, properties — those are their own list too, linked to bookings rather than typed into a note.

Test with twenty records

Import twenty first. Not two hundred.

Open every one. Check that names landed in name fields, that dates parsed as dates rather than text, that the owner assignment worked, and that nothing arrived truncated. Fix the mapping, delete the twenty, and import again.

Doing this once costs fifteen minutes. Skipping it costs a full re-import after everyone has already started adding notes to the broken records.

After the import

• Spot-check twenty random records against the source.
• Confirm the total count matches what you expected. A mismatch means rows were silently rejected — find out which.
• Check that owners see what they should, and only what they should.
• Keep the source file, read-only, for a month.

Then delete the spreadsheet. Two systems in parallel means two versions of the truth, and the spreadsheet always wins.

Next: the CRM implementation checklist.