> 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/where-your-data-lives.md). # Where Your GoHighLevel Data Actually Lives ![Sorting a CRM database and cutting dead contact records before a migration](/files/8SPCbTMudfnTN1KrMLrF) Ask any agency owner to list everything in their GoHighLevel account and watch them freeze. They built the thing. They live in it every day. And they still cannot tell you what is inside it without clicking around for twenty minutes first. That is not a knock. It is just how these accounts grow. You wire up lead capture, then onboarding, then a follow-up sequence, then review requests, then appointment reminders, then a funnel feeding a pipeline, then a custom field that quietly triggers two more workflows you forgot you made. It works, so you stop looking at it. Months pass. The account turns into a house you have lived in so long you no longer notice the rooms. Then migration day shows up and someone asks the simple question: can you list every workflow and explain how they connect? Silence. That silence is the real migration blocker, not the export button. So before you move a single record, you need an honest inventory of what is actually in there. Not what you remember building. Not the version of the account that lives in your head. The real one. Because the account you are paying for is bigger and weirder than the one you picture, and the gap between those two is where migrations go to die. ## The two things every account holds Everything in GoHighLevel falls into two buckets, and they could not move more differently. **Configuration.** Workflows, funnels, pipelines, custom fields, triggers, calendars, forms, surveys, snapshots. This is the logic of your business. It is the part nobody writes down, the part that took the longest to build, and the part that quietly breaks migrations because none of it exports as a tidy file you can hand to the next platform. **Records.** Contacts, conversations, opportunities, notes, appointments. This is the data. It leaves cleanly through the API or a CSV and maps to almost any destination, because a contact is a contact anywhere. Name, email, phone, a few custom values. Boring, portable, easy. The mistake people make is treating both as equally precious. They are not. Configuration is worth carrying carefully, one piece at a time, with notes. Records almost always need a hard cull before they go anywhere near a new system. ## What actually lives in there Let me get specific, because "configuration and records" is too tidy a way to describe the pile you are about to inherit from past-you. Open a sub-account and you are really looking at a dozen separate systems wearing a trench coat. **Contacts and custom fields.** The contact list is the easy part. The custom fields are not. Every "Lead Source," "Service Interested In," "Last Quoted Price," and one-off dropdown you added at 11pm is a column that means nothing to the next platform until you tell it what it means. The values export. The definitions, the field types, the picklist options, the logic that populates them... those live only in the account, and in your head. **Opportunities and pipelines.** A pipeline is not just a list of stages. It is the order of those stages, the stage a deal sits in right now, the monetary value attached, the owner, and the rules that move a card from one column to the next. Export an opportunity and you get a row. The shape of the board it came from does not come with it. **Workflows and triggers.** This is the engine room, and it is the single most underestimated thing in any account. Wait steps, if/else branches, the contact-replied condition, the webhook that pings an outside tool, the trigger that fires when a field changes. There is no clean export for this. None. You rebuild it on the other side from notes, or you do not have it at all. **Funnels, websites, and forms.** The pages that capture leads, the forms and surveys feeding them, the thank-you redirects, the order forms. Snapshots can carry a lot of this between GHL accounts, but the second you leave the platform entirely, those pages are HTML and field mappings you recreate by hand. **Calendars and conversation history.** Calendars hold availability rules, round-robin assignments, and buffer times that almost never travel. Conversation history, the SMS and email threads tied to each contact, is the part people forget exists until a client asks why the record looks blank. Some of it pulls through the API. A lot of it is effectively read-only history you screenshot and walk away from. **Snapshots.** Worth a line of their own, because they are GoHighLevel's answer to all of the above, and a trap if you misread them. A snapshot bundles workflows, funnels, pipelines, and field structures into something you can drop into another GHL location. Inside the ecosystem, gold. The moment your destination is anywhere else, a snapshot is a locked box you do not have the key for. ## What actually exports vs what is trapped Here is the honest split, and it is the line that matters most before you commit to a move. Out the door clean: contacts, their field values, opportunity rows, appointment records, and most conversation text, all of it reachable through the API or a CSV. If it is a record with a value attached, assume it travels. Trapped, or close to it: the workflow logic, the trigger wiring, the funnel and page builds, the calendar rules, the snapshot internals. None of that is a file. It is structure that only exists as live config inside the platform, which is exactly why "I'll just export everything" is the sentence that precedes a stalled migration. You are renting the part you cannot pack. That is the quiet cost of building your whole operation on a stack you do not control, and you do not feel it until the day you try to leave. ## Do not migrate your junk drawer Here is the part nobody wants to hear. A large share of the contacts in your CRM are dead weight, and dragging them into a new platform just moves the problem one address over. B2B contact data decays at roughly 2% per month. That compounds to more than 22% a year. People change jobs, companies rebrand, phone numbers get reassigned, email addresses start bouncing. Stack a few years of imported spreadsheets and old lists on top of that, and most accounts are sitting on a compost pile, not a goldmine. Every dead record inflates your pipeline numbers, drags down your sending reputation, and turns your reporting into fiction you start to half-believe. A migration is the worst time to be precious about this. You are paying, in effort and sometimes in per-contact pricing, to carry every one of those corpses into the next system. Why would you? A simple rule keeps the cleanup fast: if you cannot say in one sentence why a record is in your CRM, it does not come with you. ![The Live, Reference, Dead framework for sorting CRM contacts before a migration](/files/L6EHQt2ZtS4MTXxIn8EM) The Saturday before a migration is the perfect time to run this. Export everything to a spreadsheet, tag each record Live, Reference, or Dead, and only carry the first two across the line. ## What to capture before you migrate Records you can clean and re-import. Configuration is the part that will bite you, so document it like you are handing it to a stranger (because in six months, future-you is basically a stranger to past-you's workflow logic). For each sub-account you plan to move, get the following on paper before you touch anything: * Every workflow and a one-line description of what it actually does * How workflows connect to each other... the webhook that updates a field that triggers another workflow that fires a third * Every pipeline and its stages, in order, with the value and owner rules attached * Every custom field, its type, its picklist options, and where it is used * Every funnel, form, and calendar, plus what each one feeds into * A cleaned contact export, Dead records already removed That set of bullets is doing more work than it looks like. The first five are the map of a system no file will ever hand you. The last one is the difference between a migration that lands light and one that drags your old mess into a fresh start. When I ran this process on my own account, I tagged 71% of contacts as Dead and deleted them. Reply rates went up. Deliverability went up. And my reports finally told the truth instead of a flattering story. The full breakdown, including the Live / Reference / Dead framework and exactly what to delete after a deal closes, is written up here: [how I audited my CRM and deleted 71% of my contacts](https://seedlycrm.com/blog/crm-data-audit-how-i-deleted-71-percent-and-my-reports-stopped-lying). The inventory and the cleaned export together are your migration spec. Configuration documented on one side, lean records on the other, nothing carried that you cannot justify in a sentence. That is the work most people skip, and skipping it is exactly why so many migrations stall halfway and get quietly abandoned. The accounts that move well are the ones whose owners did the boring counting first. So before you go shopping for somewhere new to put all this, open the account, click into the workflows tab, and start writing down what is really in there... Next: [Alternatives where you own the code](/seedly-crm-docs/migrating-off-gohighlevel/alternatives-that-own-the-code.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/where-your-data-lives.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.