Case studyAt a glance
How the migration ran. Nothing was switched off early.
Audit
Every Zap catalogued: trigger, volume, actual business purpose
Rebuild
Workflows rebuilt on hardened self-hosted n8n
Parallel run
Both systems live together until output matched
Cutover
Zapier switched off only once n8n was proven
The problem
The automation worked; the bill did not
Zapier is the right answer until run volume makes it the wrong one. At that point the choice is to cap the automation, or to move it somewhere the marginal run is close to free. Native connectors are the right first move. At volume the bill scales with success and the failure modes live in someone else's queue.
The migration was not a lift and shift. Each workflow was reviewed against what the business actually needed now, and several were consolidated or dropped rather than rebuilt. The trigger is usually a bill that is growing faster than the revenue behind it, not a dislike of Zapier as a product.
What got built
Infrastructure you own, sitting alongside the CRM
HighLevel is a capable platform and it is not a general purpose application server. Heavy scheduled processing, integrations that must reconcile, and logic complex enough to need version control do not sit comfortably in workflows. Forced into Zapier, that work becomes expensive at exactly the point it becomes useful.
What survives is rebuilt on self-hosted n8n: workflow automation without per-task pricing, on infrastructure you control, with the execution history you need to debug it. Monitoring, retries and backups are part of the job, not an unspoken assumption. Servers are provisioned properly, firewalled, with private networking between services rather than everything exposed to the internet. You own the machines. They sit on your billing. They are documented so another engineer can take them over.
The diagrams below are architecture, not product screenshots. There is no FrontDesk queue here and no borrowed CRM UI. The story is infrastructure: where the work runs, how it is watched, and how a failure produces a diagnosable error rather than silence.
How it ran
Staged, with nothing switched off early
There is no weekend where the business holds its breath. Each stage has to earn the next one. The audit is where most of the value sits, because it is the only honest chance to drop work that no longer earns its place. The rebuild is where retries, logging and ownership get written down. The parallel run is where you find the Zap that still fires on a tag nobody uses. Cutover is a decision, not a date on a slide.
Audit
Every Zap catalogued by trigger, monthly volume and actual business purpose. That step routinely finds workflows that duplicate each other and workflows serving a process the business abandoned.
Rebuild
What survives is rebuilt in n8n on hardened self-hosted infrastructure: firewalled, monitored, with retries and execution history you can actually read when something fails at 4am.
Parallel run
Both systems live together until output matched exactly. Zapier stays on. n8n proves it. Silence is not treated as success.
Cutover
Zapier switched off only once the n8n version had been proven. The outcome is a lower cost per run, headroom to grow without a pricing cliff, and infrastructure that belongs to the client.
Honesty
What it did not do
Not every Zap should be rebuilt. Some get dropped. Faithfully recreating a dead process on nicer infrastructure is the most common mistake. If the volume does not justify self-hosting, managed services are often the right answer and cheaper overall once your time is counted.
Servers need patching and monitoring. Either that sits with you, documented, or it is a retainer. It should not be an unspoken assumption. Self-hosted n8n is reliable enough for production when it is provisioned properly. The failure mode is neglected infrastructure rather than the software, which is why patching and monitoring get agreed up front. Below that volume, I will say so. Managed services are usually the better answer.
Lower cost per run, and headroom to scale. The automation stopped being a line item that grew faster than the revenue behind it.
Related
Services and sibling write-ups
This sits with self-hosted infrastructure, MCP and APIs, and lifecycle automation that still belongs in HighLevel. Sibling write-ups: API onboarding, the platform layer, provisioning console. Worth an audit before a rebuild. Not every workflow that exists still earns its place.
Start here
Start with the audit
A written architecture record and a staged plan, useful whether or not I build the rest.