Migrate to GoHighLevel: Real Numbers From a CRM Migration

How to migrate to GoHighLevel from another CRM or agency setup, with real counts for contacts, workflows and triggers, plus import limits and phone rules.

By Carlos Familia, CRM & AI automation expert. Updated October 19, 2026. 5 min.

• 281 workflows inherited, only 95 of them active
• 190 of 190 old workflows copied into an archive folder, with 1,559 actions and 0 differences
• 1,583 contacts imported, 0 errors
• 57 opportunities created, 507 records set to update only, 14 stray opportunities removed
• 226 of 2,032 contacts carried an ID from the loan origination system (LOS)

A Florida mortgage brokerage asked me to take over the GoHighLevel setup its previous agency had built and turn it into something documented and reusable. Next to it sat a spreadsheet of contacts that included realtors as well as borrowers, and a bridge to the brokerage's LOS that ran outside HighLevel.

To migrate to GoHighLevel from another CRM or an agency's setup, move in this order: decide where each type of record will live, archive the old automations and compare the copy, import contacts with routing rules, and only then move phone numbers and sending. Each step needs a check you can read afterward. The numbers above came from checks like these.

What did I do with the old workflows?

At first, nothing except copy them. Of the 281 workflows, 186 were legacy drafts. The previous agency's 190 workflows went into an archive folder before anything else, and a comparison against the source matched every workflow, every one of the 1,559 actions and all 257 triggers.

Then I scanned the archive and edited nothing inside it. An archive you can compare is a safety net. If a rebuilt workflow misbehaves later, the old version is one folder away, with a comparison that shows it matches what ran before.

How did the contact import work?

The rules came before the file. Realtors could land in the referral pipeline and nowhere else, and no one was dropped into "New Lead" by default. Without rules like these, an import can greet existing clients with a sequence meant for brand-new leads.

HighLevel's own documentation adds limits worth knowing before you start:

• File size. The help center gives two answers. The bulk import troubleshooting article says 20 MB or 10,000 rows, whichever comes first. The import guide says CSV files up to 50 MB. Test with a small file, and split a large one.
• Phone numbers. The troubleshooting article lists error 1013 for numbers it cannot parse, such as values with stray characters or not in E.164 format. Those records still import, but without the phone. Clean the column first, and add a country code for numbers outside the sub-account's country.
• One phone and one email per row. A contact with several must be split into rows, and notes are limited to one per contact at 5,000 characters.
• Tags can start workflows. The same article uses a tag added during import to fire a workflow on purpose, which means an old tag can do it by accident.
• There is no undo. Tag everything you import so you can filter and delete it if something goes wrong.

If you are coming from HubSpot, HighLevel's HubSpot importer brings contacts, deals as opportunities with their pipelines and stages, companies, notes, tasks and emails. Imported emails are read-only. The article says to turn on "Allow duplicates" for contacts and opportunities first, test in a non-production location, and validate critical associations afterward. Workflows are not on its list of supported objects.

What happens to the old CRM's automations?

They do not import, so you rebuild them. The useful work is deciding which ones deserve it.

For every automation in your old CRM, write down its trigger, what it changes and whether anyone would notice if it stopped. Rebuild the ones people would notice. That list is also your test plan, and it is the step I most want to see from a migration specialist. My longer notes on this are in CRM implementation consultant.

What about phone numbers and sending?

Move them last, and expect weeks. HighLevel's phone number migration guide gives about 2 to 4 weeks for a port of fewer than 50 numbers after the paperwork is in. It says to keep the old service active until the port completes, and that contacts, conversation history, recordings and voicemails do not move with the number. It also says a successful transfer does not complete messaging compliance, so check the texting registration in the new account before you send.

Moving a line the other way breaks things too. When the brokerage's office line moved to another phone system, HighLevel lost access to the WhatsApp Business Account behind its staff alerts. The alert step kept logging "accepted" for days while nothing arrived. Staff alerts moved to SMS, and the first real lead after the switch reached 4 staff phones.

What did the numbers hide?

Just 226 of the 2,032 contacts had an LOS ID of any kind. Any rule that depended on that ID would have missed most of the database.

A second field misled in a different way. The loan ID on a lead turned out to be a back-reference, not a sign of conversion: 707 of 733 leads carried one, and 0 of the 733 had converted.

A new rule also meets old data on day one. The first version of a calling rule I built for this brokerage locked 573 contacts who had already been called before the rule existed. Check ID coverage and run every new rule against the existing records before you rely on either.

What happened afterward?

The structure held. Its folder layout has since been reused for five other builds, from a life insurance agency to an HVAC company. On top of it, the loan sync reads 560 active and 1,163 archived loans from the LOS.

What would I do differently?

• Check ID coverage and the meaning of every "converted" field before writing a rule on top of it.
• Run each new rule against the existing records before switching it on.
• Test the import with a small file and tag every imported contact.
• List the automations that live outside the CRM (Zapier, n8n, alerts) on day 1.
• Keep the old phone service on until the new number is confirmed working.

What should a migration specialist hand you?

A count of what existed, a map of what moved, import results with errors listed, the archive, and a test log for each rebuilt workflow. To judge whoever does the work, use the GoHighLevel expert checklist and write the job into a scope of work. If you inherited the account instead of choosing it, start with rescuing a broken GoHighLevel account. If the move is between two builders rather than two systems, replacing a GoHighLevel freelancer has the order of moves. The full audit of this account is in the mortgage CRM audit case study, and the structure it produced is in mortgage CRM.

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.