How to Update a GoHighLevel Snapshot Without Breaking Client Accounts

I can read a snapshot's structure all day, but I've never had a client scream at me because their version-2 push wiped a template. Mike Pacitto has — or has watched it happen to people who skipped the steps below. So I interviewed him about what actually breaks when you push a snapshot update onto live accounts, after five years of him doing exactly that. The absolutes in this guide are his, spoken from having watched them happen. I just wrote them down.

You built a snapshot. It works. You've got clients running on it. Now you've made version 2 — better logic, a new workflow, a fix everyone's been asking for — and you want to push it out to the accounts already live on version 1.

This is the moment snapshots stop being convenient and start being dangerous. Because pushing an update onto an account that's already running your last version is not the same operation as installing into a blank one, and GoHighLevel does very little to warn you about the difference. The rest of this guide is what actually happens when you push, and how to do it without becoming the person who broke a hundred client accounts at once.

One caveat before anything else, and it's the most important sentence here: GHL changes its snapshot transfer behavior constantly. The specific behaviors below were true as of mid-2026. Some of them will drift. What does not drift is the discipline — test on a real separate account, test the actual upgrade path, and know the overwrite-safety of every asset before you push. Learn the discipline and you survive whatever GHL changes next. Memorize only the specifics and you're re-learning this the hard way every quarter.

What quietly doesn't come along for the ride

The first trap is assuming a snapshot moves everything. It doesn't, and the gaps aren't announced.

Products don't transfer. Users don't transfer. Those are the two big ones people get burned by first.

"Products and users is a big one." — Mike

You build out products in the source account, push the snapshot, and they're simply not there in the destination. Same with users — the snapshot doesn't carry your team over.

The actual text inside a custom value isn't saved. The custom value comes across as a container, but whatever you typed into it does not. If your snapshot depends on a custom value holding a specific string, that string isn't riding along.

Calendars always arrive disabled.

"Calendars are always going to be disabled." — Mike

Every calendar lands with no users attached, so every calendar arrives switched off. You have to go in and manually enable each one. This is different from workflows — workflows have draft and active states and can arrive live. Calendars never do. If you push a snapshot and nobody turns the calendars back on, you have a booking system that silently accepts nothing.

The overwrite rules nobody wrote down

Here's where it gets genuinely counterintuitive, because two of the most common assets behave in exactly opposite ways — and GHL warns you about neither.

Custom values get skipped. Workflows get overwritten.

"If there's already a custom value with the same key in it, it doesn't overwrite the custom value. It'll actually just skip it." — Mike

If a custom value with the same key already exists in the destination account, the snapshot skips it. It will not overwrite what's there. Push all you want — the existing custom value stays exactly as it was.

Workflows are the opposite. Push a snapshot and your workflows do overwrite whatever's in the destination with the same identity. Whatever the client had is replaced by what you pushed.

Two assets, two opposite behaviors, and no warning about either one. This single asymmetry is behind more "why didn't my update take" and "why did my client's changes vanish" tickets than anything else on this list. If you don't hold both rules in your head at push time, you will guess wrong about half of them.

Two more breakage patterns worth burning in:

• Delete an asset that's referenced in a workflow, then recreate it, and that link will break. Mike doesn't soften this one: "That link will break. No, not sometimes — that link will break." The workflow was pointing at the original; the recreation is a new thing wearing the same name, and the reference does not reattach.
• If a workflow references a tag, custom field, custom value, or any other asset that you didn't include in the snapshot, the snapshot will not automatically pull it in — and probably won't tell you. In Mike's words: "Your workflow will just silently break. It probably isn't going to tell you, either." The workflow lands in the client account referencing something that isn't there. No error. It just quietly doesn't do its job.

Test on a real account. Then test the upgrade.

Everything above shares one property: it is invisible in the account where you built the snapshot. Of course the workflow works in the source account — that's where the tag and the custom field and the calendar user all still exist. The whole point of pushing is to find out what breaks when they don't.

So the first rule of testing is his, verbatim:

"Don't just do the test within the account where the snapshot was built, because you're not going to be able to see these sorts of problems pop up." — Mike

Never test only inside the account where the snapshot was built. Push it to an actual, full, separate account and see what arrives dead. That's the only place these problems become visible.

But there's a second test, and it's the one almost nobody runs — and it's the critical one. When you build version 2, test pushing it onto an account that is already running version 1.

If you have a hundred clients on v1, "it works in a fresh account" is answering the wrong question. The question is: what happens when v2 lands on top of v1? That's where the overwrite rules above collide with real client data — where your workflow update stomps a customization, where a custom value you meant to change gets skipped because the old key's still there, where a recreated asset breaks a link across every account at once:

"You need to know that before you create a hundred-person tech-support call." — Mike

Find that out on one test account, deliberately, before you find it out across a hundred accounts as a tech-support avalanche you scheduled for yourself.

Know what's safe to overwrite — per asset, in writing

Now the discipline that ties all of this together and, honestly, is the whole game.

Remember that workflows overwrite on push. Now picture a real asset your snapshot installed — say an email template that shipped with lorem-ipsum placeholder text specifically so the client would fill it in with their own copy. The client (or their VA) did exactly that. They customized it. That was the design.

Once you push that template again:

"You can no longer push that asset in the new version without overwriting all of the client data and pissing them off royally." — Mike

The moment you do, the overwrite wipes the client's copy and replaces it with your placeholder text, and now you've stomped their data across every account you pushed to.

So here's the rule that makes snapshots actually usable at scale: every single asset in your snapshot needs to be documented with whether it is safe to overwrite or not. Safe to push — go ahead, the update improves it and nobody's editing it downstream. Or not safe — this one holds client-specific data, so pushing it means destroying their work, and it has to be updated manually in existing accounts instead.

Trying to remember which assets are which is "a mind-numbingly giant waste of time" — his words — and it does not scale past your first few pushes. A simple checkmark on every asset — safe to overwrite, yes or no — is the difference between a version update you can run in an afternoon and one you're afraid to run at all.

The flag also tells you if your snapshot is built wrong

There's a design signal hiding in that flag, and it's worth pulling out on its own because it's easy to miss. If you notice a lot of your assets are marked not safe to overwrite, that's telling you the snapshot is built wrong. Too many customization points. The fix is to reduce them: instead of one workflow that carries both the logic and the customizable parts, split it. Put the customizable pieces in one place and the non-customizable logic in another. Now you can fix and update the logic workflow freely, forever, without ever touching a thing the client edited. A snapshot designed this way gets more pushable over time instead of less.

Here's the punchline, and it's why this guide exists at all:

"If you do not know what can actually be pushed out, your snapshot is pretty much useless." — Mike

Snapshots and pushed updates work great in theory. But if you don't know what can actually be pushed without breaking client accounts, you can't push anything. The overwrite-safety map isn't a nice-to-have on top of a working snapshot — it's the thing that makes the snapshot a working product instead of a loaded gun.

When you don't need any of this

If you run one account, or a handful you built and personally manage, and you're not pushing versioned updates onto live client accounts you don't touch daily — most of this doesn't apply to you yet. Installing a snapshot once into a fresh account is a fundamentally safer operation than pushing v2 over v1, because there's no existing client data to stomp and nothing to silently skip. If that's where you are, build your snapshot, install it, and don't over-engineer an overwrite-safety system you have no accounts to break. This discipline earns its keep the moment you're pushing updates to accounts other people depend on. Before that, it's overhead.

Where PatchyHub fits

A per-asset map of your snapshot, with exactly this kind of safe-to-overwrite flag on every asset, is what I'm for. Import the snapshot, see every asset and every link between them, and document — right there on each asset — whether it's safe to push or has to be updated by hand. Plus version tracking between releases, so you know what actually changed between v1 and v2 before you send it anywhere.

That's the pitch, and it's a short one, because the testimony above is the real sell. If you take nothing else from this guide: test on a separate account, test the upgrade path, and never push an asset you can't prove is safe to overwrite. Do that by hand with a spreadsheet if you want. Just do it.