Most of your history isn’t in your CRM.

The short answer: switching CRMs is not an export problem. The export is a button. What goes wrong is that nobody read the contract before signing the next one, nobody decided which parts of the history were actually worth moving, and nobody checked the move worked until the old system was already switched off. Start with the contract, move less than you think, and verify against your DMS before you cancel anything.

Most of your history is not in your CRM

Before deciding what you would lose, be precise about what you have.

A dealership's record of a customer is spread across at least three systems. The deal — what sold, for how much, with what gross, on what date — lives in your DMS. That is the record your accounting office closes the month on, it is the one you keep for years for compliance reasons, and it does not move when you change CRM. The vehicle history lives there too.

What the CRM holds is the part before the deal: the enquiry, who owned it, what was said, what the customer looked at, the appointments, and the source the lead was tagged with.

That distinction matters because it changes the size of the problem. The fear in a CRM switch is usually “we'll lose fifteen years of customers”. You will not — the sold customers and their vehicles are in the DMS. What is genuinely at risk is the open pipeline and the recent conversation history, and those are a much smaller, much more tractable set.

So the first thing to do is not an export. It is to write down which of these you are actually trying to carry across, in order of how much it would hurt to lose:

1. Open opportunities. Anyone a rep is working right now. Losing these costs real money this month.
2. Recent conversation history — call notes, what the customer wanted, the trade they mentioned. Useful for roughly as long as a shopper stays in-market.
3. Appointments already booked. Small set, high consequence if dropped.
4. The customer list itself — names and contact details, plus consent status.
5. Everything else. Years of closed, dead and duplicate records, which is usually the bulk of the row count and almost none of the value.

Start with the contract, not the data

The expensive mistakes in a CRM switch are contractual, and they are all decided before you touch an export.

Four things to establish, in writing, for the system you are leaving:

• The notice period, and what triggers it. Auto-renewal dates have a way of sitting a few weeks before the moment you want to leave.
• What you are entitled to get out, in what format, and for how long after termination. “You can export” and “we will give you a complete, machine-readable copy on request after your account closes” are different promises.
• Whether API access survives notice. If you plan to pull data through the API rather than a UI export, confirm it stays on through the wind-down.
• Whether anything stops working early. Integrations sometimes get switched off at notice rather than at termination.

Then ask the same questions of the system you are joining, before you sign — because the day you want those answers is the day you are leaving, and you will have no leverage left. If the contract is a meaningful number, have a lawyer read the data and termination clauses. That is a cheap hour against a system you are about to run your store on.

The export is easy. The shape is the problem.

Every CRM will give you CSVs. The difficulty is that a CRM is relational and a CSV is flat.

You will typically get one file per object — customers, opportunities, activities, appointments — and the only thing connecting them is an internal ID that means nothing in any other system. If those IDs come across, you can rebuild the relationships. If they do not, you have a pile of notes nobody can attach to a person.

So when you export, check for three things before you consider the extraction done:

• Every file carries the record's own ID, and every related file carries the parent ID. An activity file with no customer ID is decoration.
• Timestamps include a timezone, or you know which one they are in. A store that gets this wrong finds its entire activity history shifted by several hours, which quietly wrecks any response-time number computed from it afterwards.
• Free-text fields are quoted properly. A rep's note with a comma or a line break in it will shift every column after it in a badly-generated CSV. Open the largest file and look at the last column of a few hundred rows; if it stops making sense, the file is broken, not the data.

Four things that break on arrival

Duplicate collapse. Your old CRM almost certainly holds the same person several times over — a shopper who enquired twice on different sites, plus a walk-in record, plus a service customer. Whatever you import into has to decide which of those are one person. Merging too eagerly fuses two different people who share a name; merging too cautiously carries the mess across, and you have paid to move a problem. Decide the rule deliberately rather than accepting a default, and spot-check the result on the duplicates you already know about.

Ownership. “Which rep owns this customer” is a field full of people, some of whom no longer work for you. Decide before import whether departed reps' records go to a house account, to the current manager, or stay as-is for the history. Doing this afterwards means touching every record twice.

Source values. The source field is free text in most systems, which means the same channel appears under four spellings. Importing them as-is carries that mess forward — and the source field being unreliable is a problem that predates your switch and will outlive it. That is its own subject, covered in why your CRM's lead source is wrong. For the migration itself, the pragmatic call is usually to import source as a plain text field you keep for reference and do not report on, rather than trying to map it to clean values during a cutover week. It is also worth knowing that a switch breaks the continuity of any attribution you have built, so plan to start that history again rather than expecting it to carry.

Consent and contactability. Whatever marks a customer as having opted out has to survive the move intact, and it has to survive it conservatively — if a record's consent status is ambiguous after import, it is not a licence to contact. Getting this wrong in Canada is a compliance problem, not a tidiness problem. Treat it as the one field where “we'll clean it up later” is not available.

Run both for a month, and cut at month end

Two sequencing decisions make the rest easier.

Overlap deliberately. Keep the old system readable — not written to, readable — for a defined period after cutover. The point is not to run two CRMs; it is that in week three somebody will need to see what was said to a customer in March, and the answer should be “look it up”, not “it's gone”. Agree the date it goes dark and put it in a calendar.

Cut at a month boundary. Reporting breaks at the seam of a migration, and a seam in the middle of a month means that month's numbers come from two systems and reconcile to neither. Cutting on the first gives you one clean before and one clean after.

If you run more than one rooftop, do not cut them all on the same day. Take the smallest store first, let it run a full week, and fix what you learn before the big store moves. The problems are the same at every store; the cost of finding them is not. If the group shares reporting, see dealer group reporting across rooftops for what a mid-migration seam does to a consolidated number.

Verify before you cancel anything

The migration is not done when the import finishes. It is done when you have checked it, and the check has to happen while you can still get back into the old system.

Four checks, in increasing order of how much they tell you:

1. Row counts per object. Customers in, customers out. This catches a truncated file and nothing else, but it catches it immediately.
2. Ten customers, end to end. Pick them deliberately rather than randomly: one open deal, one sold last month, one you know is a duplicate, one who opted out, one owned by a rep who has left. Walk each one through the new system and confirm the notes, the owner, the appointments and the consent flag are all what they should be. Ten records inspected properly tell you more than a hundred thousand counted.
3. Reconcile the sold count against your DMS. Take the last ninety days of delivered units from the DMS and confirm the new system agrees about which customers bought. This is the check worth doing above all the others, because the DMS is the one record in this exercise that did not move and cannot be wrong. If the two disagree, the import's customer matching is wrong, and you want to know that now.
4. Have a rep work a real lead in it. Not a test record — an actual customer, start to finish, before the old system goes read-only. Everything above tests the data. This tests whether the thing is usable on a Tuesday afternoon, which is the only test that predicts whether your floor will adopt it.

Only once those pass do you cancel. Not before — a cancelled contract is extremely hard to un-cancel, and the leverage you have while you are still paying is the only leverage you will ever have.

The checklist

• Read the exit terms of the CRM you are leaving: notice period, renewal date, export entitlement, API access during wind-down.
• Read the same terms in the contract you are about to sign, before signing.
• Take a full export before giving notice, and store it somewhere that is not the CRM.
• Decide what you are actually migrating, in the five-tier priority above. Be honest about tier five.
• Check the export for parent IDs, timezone-bearing timestamps, and intact free-text fields.
• Decide the duplicate-merge rule, the departed-rep ownership rule, and the consent rule — in advance, in writing.
• Schedule the cutover for a month boundary. Smallest rooftop first.
• Keep the old system readable for a defined period, with a dark date in the calendar.
• Run all four verification checks, including the DMS reconciliation, before cancelling.
• Have one rep work one real lead end to end before the old system goes read-only.

Written by the founder of GhostDrive — a dealer principal, in the business since 1999