How to Migrate From Zapier to n8n
Most teams that move from Zapier to n8n aren't doing it because something broke. They're doing it because the Zapier bill crossed a number that's hard to justify, or because they hit a workflow that needed a loop, a code block, or a data transformation that Zap logic can't express cleanly. The per-task pricing model that made Zapier accessible at 500 tasks/month becomes a budget problem at 50,000 tasks/month, and n8n's self-hosted model changes that math completely.
The other driver is ownership. With n8n, your workflow definitions live in your infrastructure. You can version-control them in Git, deploy them via CI/CD, and inspect every execution log without a SaaS plan upgrade. For teams that have hit Zapier's walls around branching logic, multi-step error handling, or custom JavaScript transformations, the migration is less about cost and more about capability. Both are real reasons to switch, and this guide treats them as separate paths where relevant.
What's actually different
Zapier and n8n share the core metaphor of trigger-plus-action, but the execution model diverges quickly past that. Zapier wraps each integration in a curated "App" with a fixed set of triggers and actions. n8n calls them nodes, and nodes are more general: an HTTP Request node can talk to any API, a Code node can run arbitrary JavaScript or Python, and a Set node can reshape data with expressions instead of a GUI field mapper.
| Dimension | Zapier | n8n |
|---|---|---|
| Pricing model | Per task/run | Self-host free; cloud by workflow count |
| Branching | Paths (limited nesting) | IF + Switch + Merge, fully nestable |
| Code execution | No native code | Code node (JS/Python) |
| Error handling | Catch-all email | Error Trigger node per workflow |
| Deployment | Cloud only | Self-host (Docker/npm) or cloud |
| Integrations | 7000+ curated | 400+ nodes + HTTP fallback |
The integration count difference matters less than it looks. Zapier's 7000+ apps include many long-tail SaaS products, but n8n's HTTP Request node covers anything with a REST API. You may rebuild a few steps manually instead of clicking a dropdown, but you gain full control over headers, pagination, and response parsing.
Pricing deserves a concrete example. A team running 100,000 tasks/month on Zapier's Professional plan is spending roughly $500+/month. The same workload on a self-hosted n8n instance on a $20/month VPS costs $20/month. The crossover point where n8n self-hosting saves money is usually somewhere around 5,000-10,000 tasks/month depending on workflow complexity.
Mapping your existing workflows
Zapier's vocabulary maps to n8n almost 1:1 at the concept level, even when the implementation differs.
A Zap becomes a workflow in n8n. The trigger node is always the first node in the canvas. Every action step that follows is a node connected in sequence.
A Zapier Filter step maps to n8n's IF node. In Zapier you pick a field and a condition from dropdowns; in n8n you write an expression like {{ $json.status === 'active' }}. More verbose, but it handles edge cases that Zapier filters can't.
A Zapier Path (the branching feature) maps to n8n's Switch node. Switch lets you define multiple output routes with conditions, and you can merge them back together later with a Merge node. n8n's branching is more expressive: you can have more than two paths, and you can merge multiple branches before continuing.
A Zapier Formatter step (text, number, date transformations) usually maps to n8n's Set node with expressions, or a short Code node. The Set node can do string manipulation, date formatting, and number rounding via the expression language. For anything more complex, dropping into a Code node is cleaner than chaining multiple Formatter steps.
A Zapier AI step (ChatGPT or similar) maps directly to n8n's OpenAI node or, if you prefer full control, the HTTP Request node calling the OpenAI API directly. The n8n OpenAI node exposes the same parameters: model, temperature, system prompt, user message.
Zapier's multi-step Zaps with storage (using Zapier Tables or Storage) don't have a direct single-node equivalent in n8n. You'll use a combination of the Set node for in-workflow state and an external tool (Postgres, Redis, or a simple Airtable/Notion node) for persistence across executions.
The actual migration steps
Step 1: Document what you have. Before touching n8n, export or screenshot every Zapier workflow that's currently active. Note the trigger, each action, any filters or paths, and, critically, what data each step passes forward. Zapier doesn't have a bulk export, so this is manual. Prioritize the workflows that process the highest volume or touch revenue-critical data.
Step 2: Set up n8n. For a self-hosted install, Docker is the fastest path. The official Docker image is n8nio/n8n. Set N8N_BASIC_AUTH_ACTIVE=true and configure a persistent volume for your SQLite or Postgres database. If you'd rather not manage infrastructure, n8n Cloud is a reasonable middle ground before you commit to self-hosting.
Step 3: Rebuild one critical workflow as a pilot. Pick a workflow that's important enough to validate parity but not so critical that a day of downtime hurts. Rebuild it in n8n, wire up the same credentials, activate it, and run both Zapier and n8n in parallel for a few days. Compare the output. When you're confident n8n is producing identical results, turn off the Zapier version.
Step 4: Migrate incrementally. Don't try to move everything at once. Work through your workflow list by priority. Deactivate each Zapier Zap only after the n8n equivalent has run successfully in production for at least a few days.
Step 5: Deprecate the Zapier account. Once all workflows are confirmed running in n8n, downgrade your Zapier plan. Don't cancel immediately; keep it for 30 days as a fallback in case you missed something.
Gotchas you'll hit
Webhook URLs change. Every Zapier webhook trigger has a unique URL that external systems are calling. When you move a workflow to n8n, you get a new webhook URL. You need to update every external service that posts to that Zapier URL before you deactivate the Zap. Make a list of these before you start.
Credentials don't transfer. Zapier stores OAuth tokens and API keys in its own credential vault. You'll re-authenticate every integration from scratch in n8n. This is expected, but budget time for it, some OAuth flows require admin access to the source system, which may involve another person.
Execution history is gone. Zapier keeps execution logs that you may reference to debug historical issues. Export or screenshot any logs you care about before deactivating Zaps.
n8n's expression syntax takes adjustment. Zapier uses a simple {{field}} syntax. n8n uses {{ $json.field }} and a more explicit data reference model. Expressions that reference data from multiple previous steps use {{ $('NodeName').item.json.field }}. Expect to spend an hour with the n8n documentation on expressions if you're building complex data mappings.
Self-hosting means you own the uptime. Zapier's SLA is their problem. On a self-hosted n8n instance, if the server goes down, your workflows stop. Set up health monitoring and automatic restart policies (Docker restart policies, or a process manager like PM2) before you go live.
Rate limits behave differently. Zapier handles rate limiting automatically for many apps. In n8n, if you hit a rate limit on an API, the node will error unless you add retry logic or throttling. The Wait node and the workflow error trigger are your tools for this.
When NOT to switch
n8n doesn't cover every Zapier use case equally well. A few situations where staying on Zapier makes sense:
You rely on a niche Zapier app that has no REST API. A handful of Zapier integrations use proprietary connectors for systems that don't expose a standard API. If your workflow depends on one of these, you'll need to verify n8n has a node for it or that the underlying service has a public API you can call with the HTTP node.
Your team is non-technical and needs to edit workflows independently. Zapier's interface is genuinely easier for non-developers. If the people maintaining automations are business users without coding comfort, the n8n learning curve is real.
You need guaranteed uptime without infrastructure overhead. Zapier's managed cloud is simple. If you don't want to think about server health, Docker versions, or database backups, n8n Cloud is an option, but self-hosting's cost advantage disappears.
You're running fewer than a few thousand tasks per month. At low volumes, the Zapier bill is modest and the migration effort may not pay off quickly.
The migration is straightforward for most workflow patterns. The credential re-authentication and webhook URL updates are the biggest time sinks, not the workflow logic itself. Teams that have gone through it typically report that rebuilding their top 10 workflows takes a weekend, and the rest follow quickly once you're comfortable with n8n's node model.
Start with one workflow, run it in parallel, and let the output quality make the decision for you.