> For the complete documentation index, see [llms.txt](https://seedly-crm.gitbook.io/seedly-crm-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://seedly-crm.gitbook.io/seedly-crm-docs/migrating-off-gohighlevel/the-migration-playbook.md). # The Migration Playbook ![A documentation-first migration that drives an automated rebuild](/files/Yi5ly3Crn6j7yl1ypegI) You know what actually kills most GoHighLevel migrations? It is not the new CRM. It is the moment you sit down in front of an empty system and try to rebuild three years of accumulated automation from memory. The traditional way to leave GoHighLevel is to open the destination, start clicking, and rebuild each workflow the way you think it used to work. It takes weeks per sub-account. You forget half of what the old setup actually did, because some of it was wired up two years ago by someone who is no longer at the agency. And three weeks after you flip the switch, you are staring at a dashboard wondering why leads stopped flowing, because one silent automation, the one that tagged inbound form fills and kicked off the nurture, never got rebuilt. Nobody noticed it was gone until the pipeline went quiet. There is a faster, lower-risk way, and it has almost nothing to do with the destination CRM. The whole trick is to solve documentation first, then let documentation drive the rebuild. Get that order right and the migration stops being a memory test and turns into a checklist. ![The five-step documentation-first migration playbook](/files/82iLez2RQKZDK3FgMX0A) ## Step 1: Document the account You cannot migrate what you cannot describe. So describe it completely, on paper, before you touch the new system. If you are doing this by hand, work through the inventory from the data chapter: every workflow, every trigger, every connection, every pipeline and stage, every custom field, every calendar, every integration. Open each workflow and write down what fires it, what it does, and where it hands off to the next thing. It is tedious. It is also the part that actually saves you later, because the value of this whole approach lives or dies on the spec being complete. A few things people miss every single time, so go looking for them on purpose. The workflows that are paused but not deleted (decide now whether they come along or stay behind). The ones triggered by an inbound webhook from a tool outside GHL, because those have a dependency that does not show up inside the account. The fields that one workflow writes and another one reads three steps later, which is exactly the kind of silent chain that breaks in the dark. A tool called PatchyHub (built by Mike Pacitto, who has spent years living inside the HighLevel ecosystem) speeds this up a lot. You drop in a snapshot or a location export and it produces a visual map of every workflow, funnel, custom field, and automation, plus how they all connect to each other. It flags what is broken, orphaned, or undocumented, and (this is the part I like) it does not invent anything. If something is not documented, it tells you so instead of guessing. That last bit matters more than it sounds, because a confident wrong map is worse than no map. Whichever route you take, the output is the same: a complete, verified description of what your account does. That is your migration spec. Treat it like the source of truth, because for the rest of this process it is. ## Step 2: Stand up the destination Get your chosen CRM deployed on your own infrastructure. For a source-available option like Seedly, that is roughly a day of work with the included setup guides... not a quarter-long IT project. For agencies running multiple clients, each GoHighLevel sub-account maps cleanly to one sub-account in the new system, so the isolation model you already rely on carries over without you re-architecting anything. Do this in parallel with the old account still running. The reason migrations go down badly is that people treat it like a light switch, off here, on there, in the same hour. You do not have to. The old GHL account keeps sending and keeps capturing leads while you build the replacement next to it. Nothing about standing up the new system touches the live one. That overlap is your safety net, and it costs you almost nothing to keep it for an extra week. While you are here, get the boring infrastructure done so it is not a fire drill on launch day. Point your sending subdomain, set up SPF, DKIM, and DMARC, connect your telephony, wire up whatever inbound webhooks the old account depended on. Build the plumbing now, against a system nobody relies on yet, so launch day is a data move and not a scramble. The difference, and it is the whole point, is that you now own the code underneath it. Nobody can change the pricing, deprecate a feature you depend on, or throttle your sends because you are not a tenant on someone else's platform anymore. You stopped renting a stack you do not control. ## Step 3: Let an AI agent rebuild from the spec This is where the documentation-first approach pays off, and it is honestly kind of fun to watch. Open Claude Code in your CRM project directory, paste in the documentation from Step 1, and tell it to rebuild the equivalent setup: the workflows, the pipelines, the custom fields, the automations described in the document. Claude Code can read the codebase, understand the workflow engine and the available node types, and construct the equivalent configuration directly. Your documentation supplies the "what." The codebase supplies the "how." You are no longer rebuilding from a blank page with a half-remembered idea of what the old account did. You are handing a verified spec to something that can read both the spec and the machine it is building on. Two things make this go smoother. First, build the custom fields and pipelines before the workflows, because the workflows reference them, and an agent building in dependency order makes far fewer mistakes than one jumping around. Second, work one sub-account or one workflow cluster at a time and review as you go, rather than dumping the entire account in and hoping. Smaller batches are easier to verify, and a mistake caught at workflow three does not quietly propagate into workflow thirty. That is the move. The blank page was always the enemy, and now it is gone. ## Step 4: Verify, do not rewrite Walk through each workflow the agent built and confirm it matches the documented behavior. Adjust anything that needs tweaking for the new system's architecture, because no two engines are identical and a few nodes will want a slightly different shape. Wait timers, conditional branches, and anything time-of-day or timezone dependent are the usual suspects, so check those by hand. The practical way to verify is to run a live signal through it before you trust it. Fire a test contact through each pipeline, trigger each entry condition the way a real lead would, and watch the record move. A workflow that looks right in the editor and a workflow that actually fires are two different claims, and the only way to know you have the second one is to push something through and watch. This goes FARRR faster than people expect. You are proofreading a pre-built system against verified documentation, not writing one from scratch while second-guessing yourself. Reading is faster than writing. It always has been. And because the spec is sitting right next to the build, every check is a direct comparison instead of a memory exercise. ## Step 5: Move the records Configuration and records move separately, and keeping them separate is what keeps this clean. You already built the configuration in Steps 3 and 4. Now you move the data into it. Export contacts, opportunities, conversations, and notes from GoHighLevel via the API or CSV, then import into the new system. The model maps cleanly: contacts to contacts, opportunities to deals, pipelines to pipelines. Do a small import first. Take fifty records, push them through, and check that the custom fields landed in the right place, the opportunities attached to the right pipeline stages, and nothing got mangled in the date or phone formatting (GHL and your new system will not agree on phone formatting, they never do). Fix the mapping on fifty records, not on fifty thousand. Once the small batch lands clean, run the rest. The custom fields already exist, because the agent created them back in Step 3. And because you culled the dead records before you started, you are importing a clean dataset, not a junk drawer with five years of test contacts and dupes you forgot were in there. Clean in, clean out. When the data is in and verified, then you cut over. Repoint the inbound webhooks, the forms, the calendar links, and the sending domain to the new system, and let the old GHL account go quiet on its own. Because you ran both in parallel, there is no window where leads fall on the floor. The switch is the last thing you do, not the first, and by the time you flip it you have already watched the replacement work. ## Why this beats a manual rebuild Here is the thing nobody says out loud. The bottleneck was never the destination CRM. It was the documentation and the rebuild itself, and people blame the new tool because the new tool is the thing in front of them when it hurts. Documenting first removes the first bottleneck. An AI agent working from that documentation removes the second. What is left is verification, which is the one part that genuinely needs your expertise and judgment... and that is exactly where your time should be going anyway. You stopped being a transcriptionist for your own account. You became the person checking the work. For the long-form version of this process, including how to handle dense accounts with dozens of interconnected workflows, read [the full GoHighLevel migration playbook](https://seedlycrm.com/blog/migrate-from-ghl-with-patchyhub). Next: [What it costs after you leave](/seedly-crm-docs/migrating-off-gohighlevel/what-it-costs-after-you-leave.md). --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://seedly-crm.gitbook.io/seedly-crm-docs/migrating-off-gohighlevel/the-migration-playbook.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.