How to switch CRMs without wrecking your database

Most agents stay on a CRM they’ve outgrown for about two years longer than they should, and the reason is almost never the software. It’s the migration. Specifically, it’s a vague fear that something irreplaceable will be lost in the move, and that fear is reasonable because occasionally it is.

Here’s the version that actually works, in order.

Before you do anything: export

Do this today, whether or not you’re switching. Export your contacts from whatever you currently use, download the file, and put it somewhere that isn’t the CRM. A folder on your machine, a Drive folder, both.

You want this file regardless. It’s your insurance against the vendor going out of business, getting acquired and sunset, changing pricing in a way you hate, or locking your account over a billing problem at the worst possible moment. All four of those happen.

If your current CRM makes this hard — if it’s a support ticket rather than a button — write that down, because it tells you what the cancellation experience is going to be like.

What actually moves, and what doesn’t

Moves fine: names, emails, phones, addresses, tags, custom fields, notes, and usually the activity timeline. This is 90% of what you think of as “my database” and it’s the part everyone worries about, which is a bit unfair since it’s the reliable part.

Moves awkwardly: email threads. Most CRMs store these by syncing your actual mailbox rather than owning them, so the fix is usually to connect the same mailbox to the new system and let it re-sync. You’ll often get the history back automatically. Don’t panic if the first import looks thin here.

Doesn’t move: automations, drip sequences, action plans, lead routing rules, saved searches, and anything else that’s logic rather than data. These have to be rebuilt. There’s no standard format for “when a lead comes in from Zillow between 6pm and 9am, do this,” and there probably never will be.

That last category is where the real work is, and it’s also, quietly, an opportunity. Most agents’ automation setups have accreted over years and contain at least two sequences nobody remembers writing and one that’s been emailing people something embarrassing since 2023. Rebuilding is a chance to only rebuild what’s actually working.

The order that avoids pain

1. Set up the new system and import. Don’t cancel anything. Don’t repoint anything. Just get the data in and look at it.

2. Check the import properly. Not “does it look about right.” Pick fifteen contacts you know well — a past client, someone mid-transaction, someone with a long history — and check each one field by field. Import problems are systematic. If one contact’s phone number landed in the notes field, they all did, and you want to find that on day one rather than in month three.

3. Rebuild the automations you actually use. Look at what fired in the last 90 days in your old system. Rebuild those. Ignore the rest until you miss them, which you mostly won’t.

4. Repoint lead sources one at a time. This is the step people rush and regret. Your website forms, your portal accounts, your ad platforms, your Zapier connections — each one goes over individually, and you confirm a test lead actually arrives before moving to the next.

Some platforms make this easier than others. Our lead intake deliberately accepts the same shape Follow Up Boss uses, which means sources already pointed at a Follow Up Boss account can usually be repointed rather than rebuilt. That was a specific decision to lower this exact step, because it’s the one that generates support tickets.

5. Run parallel for two to four weeks. Both systems live. New leads go to the new one; you keep the old one open and readable. This costs you one extra month of a subscription you’re about to cancel, and it’s the cheapest insurance in the whole process.

6. Then cancel. After you’ve exported again, from the old system, with the final state of everything.

Two things people forget

Your calendar and email connection. Reconnecting these on the new system is usually five minutes, but if you skip it, the new CRM looks broken and empty and you’ll conclude the migration failed when actually you just didn’t plug it in.

Telling anyone who needs to know. If you have a transaction coordinator, an assistant, or a team, they need warning and about twenty minutes of orientation. A migration that surprises your TC mid-closing is a migration that goes badly for reasons that have nothing to do with software.

How long it takes

For a solo agent with a few thousand contacts and a handful of automations: an afternoon of setup, then two to four weeks of running parallel while you build confidence. Actual hands-on time is maybe four to six hours total.

For a team, add a week and a real conversation about who owns what, because permissions and record ownership are where team migrations get complicated. That’s not a data problem, it’s an agreement problem, and it’s better solved before the import than after.

The thing nobody tells you is that the anxiety is disproportionate to the work. The database is the part that moves cleanly. It’s the rules and the habits that take time, and those were going to need revisiting anyway.

If you want to try this against ours, Workspace Free costs nothing and has no contact cap, so you can import your whole database, look at it properly, and decide — without cancelling anything or paying us. That’s deliberately the least risky version of this we could build.