How to switch CRMs without losing your database

The thing people get wrong about migrations

Ask an agent what is in their CRM and they say "my contacts." That is why migrations go badly.

Your contacts are the least valuable thing in there. Names, emails, and phone numbers are replaceable. You could rebuild that list from your phone and your inbox in a weekend.

What you cannot rebuild is everything wrapped around each name. The note from 2023 saying they want to be near their daughter's school. The tag that says they came from an open house. The fact that you last spoke in March. That is the asset. That is also the part a CSV export usually drops on the floor.

Three ways to move, ranked by what survives

1. Direct API import

If your old CRM has an API, this is the best option by a wide margin. You give the new system a read-only API key, and it pulls records directly rather than reading a flattened file.

The reason this matters is structural. An API can return a person and then go back and ask for that person's notes. A CSV cannot, because a CSV is one row per person and a person has an unbounded number of notes.

Closr's Follow Up Boss import works this way. It pages through people, deduplicates against what you already have by email address, pulls each person's notes, maps their assigned agent to a matching user on your team, and preserves tags and stage.

One property worth demanding from any importer: running it twice should not duplicate anything. Closr's Follow Up Boss import backfills only the notes it has not already seen, so a second run is a no-op rather than a mess. Ask any vendor this question directly. If the answer is vague, assume the worst and test on a small subset.

2. CSV export and import

The universal fallback. Every CRM exports CSV, so this always works, and it always loses something.

What you typically get: name, emails, phones, address, tags, stage, source, created date.

What you typically lose: the timeline. Notes, call logs, email history, and task history are usually not in the export at all, because they do not fit the one-row-per-person shape.

Before you accept a CSV migration, open the export and look for a notes column. If it is not there, you are making a real decision about abandoning your history, and you should make it knowingly instead of discovering it a month later.

3. Manual entry

For under a few hundred contacts, or for an agent who is early enough that the database is mostly in their head, typing it in is defensible. It is also a forced audit, which has value.

Above a few hundred, it stops being realistic, and half-finished manual entry is worse than no migration at all because you cannot tell which half is missing.

The order of operations that actually works

Step one: do not cancel anything

Your old CRM is your only backup during a migration. Keep paying for it for one more month after you think you are done.

This is the single most common expensive mistake. Someone imports, glances at the contact count, cancels the old subscription to save the monthly fee, and discovers three weeks later that tags did not come across. By then the old account is gone.

One month of a subscription you are leaving is the cheapest insurance available to you.

Step two: export a full backup first

Even if you are using an API import, take a CSV export and put the file somewhere safe. Not because you will use it, but because a file on your own disk is the one copy nobody else can revoke.

Step three: test on a small slice

Import twenty contacts. Not two thousand. Open five of them and check, specifically:

• Did the phone numbers survive formatting? International and extension formats are where importers break.
• Did tags come across as tags, or did they become one comma-jammed string?
• Are notes present, and are they attributed to the right person and date?
• Did the assigned agent map to the right user on your team, or did everything land on you?

Step four: import everything, then clean

The temptation is to tidy up before migrating. Resist it. Cleaning in a system you are abandoning means doing the work twice and doing it in worse tools.

Import all of it, duplicates included, then clean in the new system where you have its deduplication and filtering to help.

Step five: verify with counts, not vibes

Compare the contact count in both systems. They will not match exactly, because the new system merged duplicates and skipped records with no usable identity. That is fine. What you need is an explanation for the gap, not a perfect match.

If your old CRM said 4,100 and the new one says 3,940, find out what happened to those 160 before you move on. Usually it is missing names or blank emails. Occasionally it is something that matters.

Step six: run both for two weeks

Work out of the new system. Keep the old one readable. When you cannot find something, you will know within days rather than months, and the answer is one tab away.

What to do in the first week after

A migration is the best opportunity you will ever get to fix things that were broken in the old system, because you are already looking at the data.

Two things worth doing immediately:

• Tag the imported batch. Tag everything from the import with the source and date, so a year from now you can tell migrated records from new ones. Closr can apply tags during the import itself rather than as a second pass.
• Find the silent ones. Every database has a segment nobody has spoken to in a year. They were invisible in the old system because they were buried. Right now they are in front of you.

The short version

Move history, not just names. Use an API import if one exists. Keep the old subscription for a month. Test on twenty records before you trust two thousand. Clean after, not before. Verify with counts and demand an explanation for any gap.

And do not migrate in the middle of your busiest month. The data will survive it. Your transactions might not.