Migrating GoHighLevel workflows is less about copying steps and more about carrying their dependencies — pipelines, tags, users, fields and calendars — into the new account so nothing breaks on the way.
When you move an account, onboard a client, or split work out of an agency, the automations are usually the hardest part to bring along. A workflow looks self-contained, but almost every step points at something else in the account: a pipeline stage, a tag, an assigned user, a custom field, a calendar. Those references are the real payload of a migration, and they are exactly what a naive copy leaves behind.
GoHighLevel helps only partway. Its native Copy Workflow to Sub-Account can move a workflow into another sub-account, but only if you are an agency-admin user, only into sub-accounts inside your own agency that you can access, and the copy always lands as a draft carrying a narrow set of references — it leaves out email-builder templates and clears most other references — with no reliable bulk select-all. The plain Duplicate action only copies a workflow within the one sub-account you are in, and there is no native export-to-file. So for a cross-agency move, a non-admin user, or an off-platform backup, the usual workarounds are to rebuild each automation by hand in the destination, or to push a whole-account snapshot. Rebuilding is slow and error-prone. Snapshots copy an entire account template, which is fine for standing up a brand-new sub-account but poor for moving a handful of workflows into an account that already has live contacts and settings you do not want to overwrite.
If you are an agency admin moving a workflow to another sub-account inside your own agency, GoHighLevel's native Copy Workflow to Sub-Account will do it — the copy lands as a draft and carries only a narrow set of references. For everything outside those limits — a different agency, a non-admin user, a backup off the platform, or a clean remap into an account that already has live data — you save the workflow to a cloud library and deploy it into the destination as a new workflow, with pipelines, stages, tags, users, custom fields and email templates matched by name. The export GoHighLevel workflows hub walks through saving to a library and deploying from it.
Every id inside a workflow is local to its account. The pipeline stage "Booked call", the tag "hot-lead", the user it assigns a task to, the custom field it reads, the calendar it books into — each has an internal id that exists only in the source account. Carry the raw workflow across and those ids resolve to nothing in the destination. The result is not an obvious error; it is a step that quietly does nothing, sends to the wrong stage, or fails to assign. By the time you notice, contacts have already run through it.
A clean migration therefore has two jobs: move the workflow's structure, and re-point every reference at the matching thing in the destination account. Miss the second job and you have moved a shell.
Before you migrate, inventory what each workflow depends on. These are the references that have to exist — by name — in the destination:
The rule of thumb: if a step names something you also see elsewhere in the account, it is a dependency, and the destination needs its own copy with the same name.
Order matters, because a workflow can only map to dependencies that already exist when it lands. Work through it like this:
ExportGHL Workflows is built for exactly this move. You save each workflow from the source account to a cloud library, then deploy it into the destination. A deploy always creates a new workflow in the destination — it never overwrites an existing one unless you deliberately choose to update it — so there is no risk of clobbering automations the account already runs.
The part that saves the migration is cross-account remap. On a cross-account deploy it runs automatically, rewriting the ids that only exist in the source — pipelines, stages, tags, users, custom fields and email templates — to the matching ones in the destination, matched by name. That is the step the JSON-based tools skip: GHL Workflows Pro has a cloud workflow library and one-click import across locations, but it does not rewrite source-only ids, so its imports still need every reference re-pointed by hand in a live account. (Super Cloner, despite the name, clones funnel and website pages — not workflows, automations or triggers — so it does not apply to a workflow migration at all.)
Anything ExportGHL cannot confidently map is not published. The imported workflow is saved as a draft and the unmatched reference is flagged, so you fix it on purpose rather than discovering it in production. That single guardrail is what makes it safe to migrate into an account that is already serving customers.
Treat verification as part of the migration, not an afterthought. Open each migrated workflow in the destination and confirm every reference resolved: no blank stages, no missing calendars, no draft flag you did not expect. Then run a single test contact through the trigger and watch it travel the whole path — tags applied, stage moved, task assigned to the right user, the right template sent. Publish only once a test contact completes cleanly.
Workflow migration sits inside a bigger move when you are relocating a whole account. For the end-to-end picture — front-end pages as well as automations — see the complete migration guide. If you just want to try it, the free trial moves your first workflow with no card; see pricing for how credits and the one-time Toolkit licence work after that.
Move your first workflow free — no card. Deploy into any account with dependencies remapped for you.
Start free
ExportGHL