Transferring a GoHighLevel sub-account to another agency: what moves, what does not, what breaks

Sooner or later a sub-account has to leave. A client hires an in-house team and wants their own agency account. You sell part of your book. You inherit a portfolio from an agency that is winding down. A client fires you and wants their data.

GoHighLevel supports this natively — a sub-account can be transferred to another agency without rebuilding it. What it does not do is warn you about the things that stay behind. Those are the subject of this note.

The mechanics

From the agency view, open the sub-account, then Manage Client → Actions → Transfer Sub-Account. You are asked for the receiving agency’s relationship number — an identifier the receiving agency finds in their own agency settings — and then for your password. Confirming sends a request; the receiving agency accepts it, and the account moves.

Three requirements before that will work:

1. You must have the authority. Agency owner, or an agency admin explicitly granted transfer permission. A team member without it will not see the option.
2. The receiving agency must have room. If they are on a plan with a sub-account cap and they are at it, the transfer fails on their side.
3. The receiving agency must be a plain agency account. White-labelled sub-accounts and multi-location structures are excluded from the standard transfer path.

If you are moving several accounts at once, there is a bulk transfer flow rather than repeating the single-account action twenty times. Same exclusions apply.

What travels

Nearly everything a client would call “theirs”:

• contacts, custom field values, notes, files and tasks
• conversation history across channels
• opportunities and pipelines
• calendars and appointments
• workflows, triggers and campaigns
• funnels, websites, forms and surveys
• memberships and courses
• reporting history

This is genuinely good — it is a move, not an export and re-import, and it does not produce the duplicate-asset mess that loading a snapshot into a populated account produces.

What does not travel, and will bite you

Phone numbers

The single biggest one. Number continuity depends on whether both agencies use the same telephony arrangement. Same provider on both sides and the number generally comes with the account. Different providers — one on the platform’s own telephony, one on their own Twilio — and you are in porting territory, which is a days-to-weeks process with its own paperwork.

Establish this before you agree a transfer date. A client whose advertised number goes dark for a week during a hand-off will remember it for years.

Messaging compliance registration

Brand and campaign registration is attached to a business and to the agency that submitted it. Expect the receiving agency to re-register. Budget for the approval window, and do not schedule the first campaign inside it. If you have never done this, read GoHighLevel A2P 10DLC registration first.

Domains and DNS

Funnel domains, the sending subdomain, tracking domains. The records live in whoever’s DNS the client uses, and they point at configuration in the account. Nothing breaks automatically, but nothing re-points automatically either. Every domain attached to the account is a checklist row.

Integration credentials

Ad accounts, Google Business Profile, social channels, payment processors, calendar syncs, any third-party API key stored in the account. These are authorisations, not data. Some survive, many need reconnecting, and the ones you forget fail silently — the calendar simply stops syncing and nobody notices for a fortnight.

White-label branding and the login experience

The account inherits the receiving agency’s branding. The client’s login URL changes, the emails they receive change appearance, the mobile app they were told to download may be a different app. This is a client-communications problem more than a technical one, and it is the one that generates the angry email. See white-label sub-accounts for what is branded where.

Rebilling and usage markup

The commercial arrangement is agency-level. It does not follow the account. The receiving agency configures their own.

The pre-transfer audit

Run this before you initiate anything. It takes about an hour and it is the difference between a clean hand-off and three weeks of blame.

1. Inventory the phone numbers on the account, and confirm the telephony arrangement on both sides. Decide port or re-provision, in writing.
2. List every domain the account touches — funnel domains, sending subdomain, tracking domain — and who controls the DNS for each.
3. List every integration, with which credential it uses and who owns that credential.
4. Export a contact backup anyway. It costs nothing and it is the only thing you cannot rebuild.
5. Screenshot the workflow list with published states. After a move, “was this one on before?” is a question with no answer unless you took the picture.
6. Record the custom values. They contain the client-specific strings the whole account prints. Losing them is not fatal but re-deriving them is tedious.
7. Agree a go-dark window with the client and tell them what will look different afterwards.
8. Confirm capacity and compliance add-ons on the receiving side.

Selling sub-accounts, and buying them

The transfer flow is also what sits behind “GoHighLevel sub-accounts for sale”. Two honest notes if you are on either side of that trade.

Buying: you are buying a configured account and, if you are lucky, a client relationship. You are not buying the phone number’s history, the compliance registration, or the integrations. Price accordingly, and audit the account before money moves — specifically the exit conditions on the workflows, because an inherited account full of sequences that never stop is a liability.

Selling: the account is worth more if it is documented. A build sheet listing the account ID, numbers, domains, custom values and published workflows turns a hand-off from a fortnight of questions into an afternoon.

The first week in the new agency

Transfers do not fail on the day. They fail in the following week, quietly, in the four places below. Put a calendar reminder on day two, day five and day ten.

Inbound calls. Ring the client’s advertised number from a phone that is not in the CRM. Confirm it routes, confirm the recording and the AI receptionist behave, confirm the call appears in the conversation history.

Outbound SMS. Send one message to a test contact you control. If compliance registration is still pending on the receiving side, this is where you find out — before a workflow finds out on behalf of four hundred contacts.

Form to workflow. Submit a live form on the client’s public site. The form is often embedded on a page you do not control, pointing at an account that has just moved. If it silently posts nowhere, lead capture is down and the reporting looks like a quiet week rather than a broken one.

Calendar sync. Book a test appointment and confirm it lands in the human’s real diary. Calendar authorisations are the most common casualty of a move and the slowest to be noticed, because an unsynced calendar looks perfectly healthy from inside the CRM.

Who should own the account long term

One useful question to settle at transfer time, because it never gets easier later: does the client own their CRM, or do you?

If the client owns it, they need their own agency account eventually, and every build you do should assume an exit. Document accordingly.

If you own it, say so plainly in the contract, and be clear about what leaves with them if they go — their contacts and conversation history, yes; your snapshot, no. A licence to use a kit inside accounts you manage is not a licence for the client to take the blueprint to the next agency, and the cleanest time to say that is before anyone needs to hear it.

When a transfer is the wrong tool

If what you actually want is the structure rather than the account — the workflows and pipelines and calendars, in a fresh account, without the previous agency’s contacts and conversation history — you want a snapshot, not a transfer. That is a different operation with different trade-offs, and snapshot versus template versus clone explains which is which.

And if the reason you are transferring is that the account was never built to be maintainable in the first place, the fix is upstream. A sub-account kit is a blueprint designed to be loaded, documented and handed over; our snapshot loading and account migration service does the move, the audit and the reconnection pass for you.