Switching CRMs as an Insurance Agent: The Migration Plan

Most agents switch CRMs the same way. They pick the new platform, export a contact CSV on a Friday, import it Saturday, cancel the old subscription Sunday, and start dialing Monday.

Then Tuesday happens. Two callbacks that were scheduled in the old system never showed up in the new one. A lead swears he asked to be taken off the list last month, and the note proving you honored it is in an account you just closed. The Facebook lead form is still posting to a webhook that no longer goes anywhere. And the phone number on eight hundred of your business cards now belongs to somebody else.

None of that is dramatic. It is just quiet, expensive attrition, and it happens because the export button only gives you the easiest layer of your data.

I want to lay out the order that actually works — what to pull, what to start early because it waits on other people, and what to verify before you cancel anything.

The five things you are actually moving

A CRM looks like a list of contacts. It is not. For an agent who dials, it is five separate data sets that happen to share a screen, and they export through different doors — sometimes not at all.

Read down that right-hand column. The difficulty of getting data out rises in almost exact proportion to how much you would miss it. That is not a coincidence and it is not always malice either — call history and recordings are simply bulkier and less standardized than a name and a phone number. But the effect is the same, and the effect is what you have to plan around.

Start with the three things that wait on other people

Here is the single scheduling mistake that turns a clean switch into a bad month. Agents do the fast work first — the export, the import — and then discover that the slow work has not started.

Three items run on someone else's clock. Begin all three before you touch a CSV.

1. Number porting

If prospects have your number, that number is an asset. Porting it to a new platform takes days to weeks depending on the losing carrier, and it fails on trivial mismatches — a service address that does not match the account, a name spelled differently, an account PIN nobody wrote down.

Before anything else, ask the outgoing vendor one direct question in writing: am I the account of record on this number, and will you release it?If the number was provisioned under the vendor's own account rather than yours, the honest answer is sometimes no. That is worth knowing on day one rather than day twenty.

Critically: do not cancel the old account while a port is pending. Cancelling releases the number back to the carrier pool and the port dies with it. The old account gets closed after the port completes, not before.

2. Messaging registration

If you text leads at all, your A2P 10DLC brand and campaign registration does not travel with you. The new platform files its own, review takes time, and until it clears your texts get filtered or dropped — silently, with no error on your side.

Get the 10DLC registration submitted on the new platform the same week you sign up. It is the longest lead-time item after porting and the one most likely to be forgotten entirely, because texting failure is invisible.

3. Lead-source connections

Every place a lead enters your world has a destination configured somewhere: a webhook URL, a form integration, a Zap, a vendor delivery endpoint. Those keep pointing at the old CRM until someone changes them, and some of them are changed by people who are not you.

Write the list down before you migrate. Vendor delivery, Facebook lead forms, your website form, any referral or partner feed. Each one needs a new endpoint and each one needs a live test — not an assumption that it worked.

Clean the list before you move it, not after

There is a real temptation to move everything and sort it out later. Do not. A migration is the one moment you will ever touch every record at once, and dead weight costs more in the new system than it did in the old one — it inflates the import, muddies your metrics from day one, and hides the records that matter.

Before export, do a pass that looks a lot like a monthly pipeline audit, just applied to the whole book:

• Segment by whether you will ever dial it again. Active pipeline, dormant-but-workable, and archive. The archive tier still gets exported and stored — you may need it — it just does not get imported as a dialable record.
• Pull your internal DNC list out as its own file. This one is non-negotiable and I will come back to it.
• Kill obvious duplicates now. Duplicates that survive an import multiply, because the new system also has its own dedupe rules and they will not match the old ones.
• Note which fields you actually use. Most agents carry twenty custom fields and use six. Map the six carefully and let the rest go.

The DNC list is the one you cannot lose

I want to isolate this because it is the single highest-consequence item in a migration and it is stored in the most fragile way.

Your internal do-not-call list — the people who personally told you to stop calling — is usually not a tidy separate list. It is a checkbox on a contact, or a disposition code, or a tag, or a note somebody typed. Export contacts without carrying that field through, import them into a fresh system, and every one of those people becomes a normal dialable record again.

Then you call someone who already asked you not to. That is not a filing error. Federal rules require you to honor an internal do-not-call request for five years, and a call after the request is exactly the fact pattern a demand letter is built on. “We changed CRMs” is not a defense; if anything it reads as an admission that your process does not survive contact with an ordinary business event.

So handle it deliberately. Export the internal DNC as a standalone file, import it into the new system as a suppression list first — before any contacts land — and then spot-check ten of those numbers in the new platform to confirm they are actually blocked from dialing. A written DNC policy is worth exactly as much as the list behind it.

Consent records travel badly

The second fragile layer. Consent is not a yes/no field — a usable record includes the language shown, the timestamp, the source, and ideally the IP or lead ID. In most CRMs that lives across several custom fields or, worse, inside the original lead payload attached to the record.

Column mapping is where it dies. An import wizard confidently maps name, email, and phone, then shrugs attcpa_consent_text and drops it. Nobody notices, because nothing looks broken until the day it matters.

Two rules. First, map consent fields explicitly and verify them on a sample record after import. Second, keep the raw export files — the original CSVs, in cloud storage, indefinitely. They are the closest thing you have to a snapshot of what the record looked like on the old system, and they cost nothing to keep. What belongs in a defensible consent record does not change because you changed vendors.

Call history: keep it somewhere

Activity history is the layer agents most often decide to abandon, usually with the reasoning that old dispositions do not matter much and re-creating them is not worth the effort.

Half true. You genuinely do not need three-year-old dial attempts inside the new CRM. But you may badly need to prove, on some future Tuesday, that you called a specific number four times over two weeks and stopped when asked. If that record only existed in a platform you cancelled, it does not exist.

The practical middle: export activity history to CSV and store it in your own cloud drive, even if you never import it. If the new platform accepts a history import, bring in the last ninety days so recent context follows the lead into the first conversation. Beyond ninety days, the archive is enough.

Call recordings deserve their own decision. They are large, they are often download-one-at-a-time, and in all-party consent states they can be evidence in both directions. If you keep recordings, budget real time to pull them, or accept deliberately that they are going away — and write down which choice you made and when.

The import itself

Once the slow items are moving and the list is clean, the import is mechanical. It is covered in more depth in the guide to importing a lead list without wrecking it, and the same rules apply here with one addition: you are also carrying state, not just contacts.

The migration-specific traps:

• Phone formatting. Exports emit(555) 123-4567,555.123.4567, and+15551234567 in the same file. Normalize before import. And check for the classic spreadsheet crime: a leading zero or plus stripped by Excel because it decided your phone column was a number.
• Scheduled callbacks. Future-dated appointments usually live in a tasks or calendar object, not on the contact, so a contact export loses them entirely. Export them separately, or at minimum print the next fourteen days of callbacks and re-enter them by hand. Fourteen days of manual entry beats one missed appointment with a lead who was ready.
• Pipeline stage names. They will not match. Decide the new set first, map old to new in a two-column sheet, and import against that — do not improvise per record.
• Import in tiers. DNC suppression first. Then active pipeline. Then dormant. Check after each. If something is wrong you want to find it in a hundred records, not eleven thousand.

Overlap, then cut over

Run both systems briefly, with a clear rule about which one is authoritative. The old platform goes read-only — you can look things up, you do not work in it. The new one takes every new lead, every dial, every note from the cutover date forward.

One to two weeks is the right window. Long enough to surface what did not come across, short enough that your call history does not permanently split into two halves. Agents who let this drag for a month end up with no single system that knows who was contacted when, which is worse than either platform alone.

Before you cancel, verify these:

• The number port has completed, and you have made and received a test call on it.
• Every lead source has delivered a live test lead into the new system.
• Ten sampled records show correct phone, consent fields, and stage.
• Ten sampled DNC entries are confirmed blocked from dialing.
• Raw exports — contacts, activity, DNC, consent — are in your own storage, not just the vendor's.
• Recordings are either downloaded or consciously written off.

Then cancel — and take a final export the same day, after the last billing period, so your archive matches the account's final state.

Ask the exit questions before you sign up

The best time to learn how hard it is to leave a platform is before you join it. When you are evaluating a dialer or CRM, the exit questions are more revealing than the feature list, because every vendor demos well and only some of them let go gracefully.

• Can I export contacts, activity history, and call recordings myself, without asking support?
• Are phone numbers registered to me, and will you release them for porting?
• Is my internal DNC list exportable as a standalone file?
• Do consent fields export with the record, including timestamp and source?
• What happens to my data after cancellation, and how long do I have to retrieve it?

A vendor that answers all five plainly is telling you something about how it expects to keep you. A vendor that routes the number question to a sales manager has already answered.