Zenoti to GoHighLevel migration: a practical guide for med spas
Most med spas should keep Zenoti for operations and add GoHighLevel for marketing. Here is how to do it without breaking either.
Learn moreAgencies
How to roll out GoHighLevel snapshot updates across sub-accounts without breaking them
The question that keeps SaaS founders up at night: you have 50 or 100 sub-accounts on one master snapshot and need to ship an update. A versioning and rollout process that does not break every account.
Short answer: GoHighLevel snapshot updates are safe at scale only with a process. Keep one versioned master snapshot with a changelog. Keep all client-specific configuration in custom values and custom fields rather than inside workflow copy. Test every update in a staging sub-account that mirrors production. Take a snapshot of each target sub-account immediately before the push so you can roll back. Roll out in rings, a few accounts first, then the rest. Agencies that skip any of these steps eventually push one update that "breaks every other account."
What a snapshot actually is
A snapshot is a point-in-time copy of a sub-account's assets: workflows, pipelines, calendars, custom fields, funnels, templates. Loading it into a sub-account copies those assets. It does not create a live link. When you push an updated snapshot to an existing account, GoHighLevel asks whether to overwrite or add, and the result depends on what has changed in that account since. That is the whole problem in one sentence.
Rule 1: no snowflakes
The founders we work with say it themselves: "you've got to remember that you've modified that for that one, and that one's got a slight tweak." Every per-client edit to a snapshot-managed workflow is a future conflict. Put anything client-specific in custom values (business name, hours, offer text, booking link) and custom fields, and reference them from the workflow. If a client truly needs different logic, give them a clearly named client-only workflow the master snapshot never contains.
Rule 2: version the master
Name snapshots with a version and a date. Keep a changelog of what changed and which assets it touches. When something goes wrong in an account, you can see which version it is on and what changed since.
Rule 3: staging first
Maintain a staging sub-account loaded with the current production snapshot plus realistic test data. Apply the new version there, run the key flows end to end (new lead, booking, reschedule, review request, billing event), then promote.
Rule 4: pre-push snapshot of every target
Before pushing to an account, snapshot that account. It is the only rollback you will have. Automate the reminder if you must, but never skip it.
Rule 5: rings
Push to two or three friendly accounts, wait a business day, check conversations and error logs, then push to the rest in batches. A problem discovered at account three is an afternoon; at account eighty it is a week.
Onboarding is part of the same system
The same founders want 10 to 15 minute onboarding with no admin involvement. That is achievable when the snapshot expects its configuration in custom values: an onboarding form or AI assistant collects the values, an automation writes them, and the account is live. Steps you do not control (Stripe connection, WhatsApp, email domain) get a guided checklist with status checks, not a call.
This is the architecture work we do for agencies and SaaS founders, alongside usage-based billing for the accounts once they are live.
Frequently asked
Does updating a GoHighLevel snapshot update existing sub-accounts automatically?
No. Existing sub-accounts keep what they received. You push the updated snapshot to them, choosing whether to overwrite or add assets, and that push is where things break if the account has been customized.
How do I avoid breaking customized sub-accounts?
Do not customize them, or isolate customization to custom values, custom fields and clearly named client-specific workflows that the snapshot does not touch. Document every exception.
Can I roll back a snapshot update?
Only if you took a snapshot of that sub-account immediately before the push. Make the pre-push snapshot a mandatory step in the rollout checklist.
Keep reading
GoHighLevel vs HubSpot for service businesses: an engineer's comparison
For local and multi-location service businesses, the decision usually comes down to communication channels and cost structure. Here is how we think about it.
Learn moreRobot-proof businesses: why physical service companies win the AI decade
The businesses AI cannot replace are the ones AI helps most. A thesis on where automation pays for physical service companies.
Learn moreIs this happening in your account?
Book a 30-minute call. We look at the account live and tell you what is broken, what we would fix first and what it would cost.
No pitch deck. We look at your current setup and tell you what we would do and what it would cost.Need more than GoHighLevel? Yotomations, our parent company, also builds AI agents, custom software and websites.