3 min read
The GoHighLevel migration checklist
Migrations fail quietly. This is the sequence we follow, including the verification step most cutover plans skip.
Quick answer
What are the steps in a GoHighLevel migration?
A GoHighLevel migration runs in five stages: audit the source platform including undocumented automations, map fields and objects onto the new data model, rebuild automations natively, run both systems in parallel while porting numbers, then cut over only after a written verification checklist passes.
Why migrations fail quietly
Exports are boring and mostly reliable. The failure mode that costs money is that automation problems after a migration produce no error at all.
A workflow that did not get rebuilt does not throw an exception. It simply does not run. The follow-up text that used to go out within sixty seconds stops going out, and nothing anywhere reports a problem. Eleven days later somebody notices that new enquiries have gone quiet.
That is why the verification checklist below is written rather than intuitive, and why the old platform stays live until it passes.
The verification checklist
Before switching the old system off, confirm each of these with an actual test rather than an assumption:
- A new lead from every channel creates a contact with the correct fields populated
- The first-response automation fires and the message is genuinely delivered, not just sent
- Appointment booking writes to the correct calendar with the correct owner
- Reminder and confirmation sequences fire at the right intervals
- Reply detection exits sequences correctly
- Every integration writes to the new system and nothing still writes to the old one
- Reporting returns numbers consistent with the old platform for an overlapping period
- Phone numbers ring through and calls are logged against the right contact
If any of these cannot be demonstrated, do not cut over. The parallel-running window exists precisely so that failing this list is cheap rather than expensive.
The steps, in order
- Step
Audit the source platform
Catalogue every contact field, automation, integration and phone number. Include the automations nobody remembers building — we routinely find sequences running that the client believed were disabled.
- Step
Map fields and objects
Decide what carries over, what merges and what is deliberately retired. Document the decisions, because you will be asked about them six months later.
- Step
Start number porting immediately
Porting is carrier-controlled and the longest-lead item. Submit it on day one and sequence everything else around it rather than the other way round.
- Step
Rebuild automations natively
Workflows do not transfer between platforms. Rebuild rather than translate — and use the opportunity to retire the sequences that were never working.
- Step
Import data in test batches
Load a sample, verify field mapping and de-duplication, then run the full import. A full load with a mapping error is painful to unpick.
- Step
Reconnect integrations
Every downstream system — ads, calendars, payments, reporting — repointed at the new source of truth and tested.
- Step
Run both systems in parallel
A defined window with the old platform still live. This is your safety net and it costs almost nothing.
- Step
Work the verification checklist
A written list of what must be true before cutover — not a feeling that things look fine. Rollback criteria defined in advance.
- Step
Cut over and monitor
Switch, then watch actively for the first weeks. Migration failures surface as absences rather than errors.
- Step
Archive, do not delete
Keep an export of the old platform. We have never regretted having one.
Questions
Related questions
What is the most common migration failure?
Silent automation failure after cutover. Nothing errors — a message simply does not send, a task is not created, a lead is not assigned. Nobody notices because the absence of an event does not announce itself, and you discover it weeks later.
How long should parallel running last?
Long enough to see a full cycle of your normal business activity, including whatever happens weekly and monthly. Cutting over on day three because everything looks fine is how you find out about the month-end process that nobody migrated.
Can conversation history be migrated?
Usually, if the source platform exposes it. Where it cannot be imported, archive an export so it remains retrievable even if it is not live in the new CRM. Losing four years of customer conversation is a genuine cost.
Should we migrate everything at once?
Data yes, automations no. Rebuilding every workflow before cutover delays the migration considerably. Build the critical ones, cut over, then add the rest — provided you have documented what is not yet rebuilt.
Services mentioned here
Move onto GoHighLevel without losing your history
A GoHighLevel migration moves contacts, custom fields, conversation history, pipelines, automations, forms, calendars and phone numbers from an existing platform into GoHighLevel. It involves mapping the old data model onto the new one, rebuilding automations natively, porting numbers, then cutting over with both systems briefly running in parallel.
A CRM structured around how you actually sell
GoHighLevel CRM setup involves designing the pipelines and stages that model your sales process, defining custom fields and objects to capture the data you need, structuring tags and segmentation, importing and de-duplicating existing contacts, and configuring the reporting those decisions make possible.