CRM Migration Consultant: Six Checkpoints, Export to Day 30

What a CRM migration consultant does from export to day 30: counts before and after, duplicate rules, a test import, cutover and checks that catch lost data.

By Carlos Familia, CRM & AI automation expert. Updated October 15, 2026. 6 min.

Someone who manages the CRM at an HVAC company wrote on r/HVAC that the business had migrated to ServiceTitan a few years earlier, and that it beat the old system. The trouble came after the move. New hires took forever to train, and even then they only scratched the surface. The post called the software "too big to where my people are scared to dive in" and guessed that a much cheaper tool would do the same job.

The thread says nothing about lost data. The move worked on paper and still disappointed, because moving the records was only half the job.

A CRM migration consultant moves your contacts, deals, notes and automations from the old system to the new one, then proves nothing was lost and makes sure your people can use what arrived. The proof is a set of counts taken before and after. The second half is a plan for who uses what on the first Monday.

I run a migration as six checkpoints, timed against cutover, the day the old system goes read-only. This is the order I follow, not the diary of one job. The examples come from separate builds.

14 days before: count the old system

Count every object before you map anything: contacts, companies, open and closed deals, notes, files, tags and automations. Then write down what happens to each one. "Migrate" is not an answer. Some records move, some get archived, some are deleted on purpose.

Coverage matters more than totals. In a life insurance agent's account in Utah, 126 contacts carried the "client" tag, but only 10 of them had a policy start date. Any rule built on that date would have reached about one client in thirteen. Counting first turns a gap like that into a design decision before any data moves.

Count the automations separately and mark the ones that really run. Inherited accounts are full of drafts and switched-off copies, and the mortgage CRM audit shows what a real census looks like. Decide which to move, which to archive and which to drop.

10 days before: set the rules for duplicates, fields and deals

Duplicates first. HighLevel's help center says duplicate contacts cannot be created through a CSV upload: it merges on email or phone whatever the duplicate setting says, and the lookup defaults to email. My reading is that two people who share a family email can collapse into one record, so look for shared emails before you import.

Fields come next. In HighLevel a custom field has to exist before a column can map to it, and the file must be a CSV, since Excel files are not accepted, according to the import guide. Dropdown values must match exactly. On a credit repair build, "Si" and "Sí" counted as different options, and the write failed with no error.

Then deals. GoHighLevel can refuse a second opportunity for the same contact in the same pipeline, even when the first one is won or abandoned. A repeat client then has nowhere to go, so settle that rule before the first row loads.

7 days before: import a slice of real rows

Pick a slice that includes the ugly rows: no email, two phone numbers, a company name typed into the first-name column. Import it into the real destination and read what landed.

I learned the value of this on a spreadsheet import I wrote for a mortgage brokerage's realtor referral tracking. The first version read only the first sheet of each workbook, and a yes/no column called "Has Real Estate Agent" created 33 agents named "Yes" and 48 named "No". Real rows found both bugs.

The test to copy came after the fixes. I uploaded the same file a second time, and it created zero new records. Import your slice twice. The second run should change nothing.

Cutover day: freeze, import in order, keep automations off

Nobody types into the old system once the final export starts. Import in dependency order: contacts and companies, then deals, then notes and files. Bring automations over as drafts and keep them off until the counts match, so the old and new systems never message the same person.

Name the destination in the plan and check it before every run. I once sent a first run into a client's live business account instead of the new one, and I tell that story in what a CRM consultant does.

Day 1 after: compare counts, then sample by hand

Take the same counts you took 14 days earlier and set them side by side. Then open a handful of records at random in both systems and compare them field by field.

For automations, scan for references that point at nothing. Cloned steps that add or remove a contact from another workflow keep the old account's workflow IDs and fail silently, and WhatsApp templates do not travel between business accounts. In a move for a portable storage company in Alabama, the scan found 3 real issues among 79 workflows, and all three were already broken in the source account.

Record that split. Problems the move created belong to your consultant. Problems the old account already had are a separate list, with its own owner and its own price.

Day 7: sit with the people who use it

This checkpoint is easy to skip, and the HVAC thread is the case for it. Ask each person what they did in the old tool in a normal week, then give them a one-page map of where each task lives now. Hide or remove what nobody will use. A system that feels too big gets used as a contact list.

Also read the log of a real run, not just the editor. At that brokerage, converting marketplace action steps into webhook steps left a hidden flag behind, GoHighLevel skipped those steps, and five leads got no welcome message for about two days.

Day 30: retire the old system

Keep the old system read-only through one full billing cycle. Export a final copy, then cancel. Do not cancel the day the counts match. Wait until the first month's reports from the new system agree with what your team remembers.

What should you ask before agreeing to a migration?

• What counts will you take before the move, and will I receive them in writing?
• Which rule decides that two records are the same person?
• Will you import a slice twice before the real run, and show me the result?
• Which system will carry the live data on cutover day, and what stays read-only?
• If the counts do not match, what is the plan? The honest answer is to keep the old system untouched, fix the cause and run again.

A consultant who answers these with numbers has done this before. One who answers with "we handle it" has not.

What would I change?

• Count field and ID coverage in the first week, before choosing how records are matched or which dates drive automations.
• Put the same-file-twice test into every statement of work.
• Write the destination's name into the plan, in bold.
• Start the adoption conversation at the first checkpoint, not at Day 7.

If you are weighing a builder for the destination, the questions are in migrate to GoHighLevel, and the budget side is in CRM consultant cost. My GoHighLevel expert checklist covers who to trust with the keys. Common automation traps after a move are in GoHighLevel workflow mistakes, and the testing method for Day 1 is in how I test GoHighLevel workflows. Or bring your counts to the calendar below and book a call.

About the author

Carlos Familia, CRM & AI automation expert. GoHighLevel, n8n, AI agents, servers. Full-stack developer.

I build CRM systems in GoHighLevel, n8n automations on my own servers and AI voice and chat agents for service businesses. Full-stack developer: I write the workflow, the API integration, the database and the server it runs on, and I test every build with real journeys before handoff.