Migrate Zapier to n8n: A Practitioner's Playbook for 2026
Most teams that want to migrate Zapier to n8n hit the same wall: pricing crosses a threshold around 10,000 tasks per month, or a data sovereignty requirement lands on the roadmap, and Zapier’s per-task model becomes a liability. n8n fixes both, but only if you pick the right deployment and plan the cutover properly.
I run n8n self-hosted in production for RedaktFlow, alongside Make.com blueprints for clients who do not want to operate their own infrastructure. This is the zapier to n8n migration playbook I wish I had: concept mapping, pattern translation, a six-step rollout, the cost math that decides Cloud vs self-hosted, and the gotchas that burn people in week two.
If you already know you want to move from Zapier to n8n and need the translation layer, jump to “Zapier concepts and n8n equivalents”.
Why teams move from Zapier to n8n
Four reasons come up in every migration I have seen. All of them compound.
Pricing crosses a threshold. Zapier’s Team plan at $103/mo gives you 2,000 tasks. Company at $208/mo gets you to 50,000. AI workflows that fan out (one trigger, ten steps, several branches per run) burn tasks fast. Past roughly 10,000 executions a month, self-hosted n8n on a €10-20/mo VPS is the obvious move.
DSGVO, air-gap, or data residency. Zapier is US-hosted. For DACH clients handling customer PII or regulated data, routing every webhook through a third country is either a full DPIA exercise or a non-starter. n8n self-hosted in an EU data centre removes the question entirely.
Custom code is a first-class citizen. Zapier’s Code step is limited: short scripts, no npm, strict timeouts. n8n’s Code node gives you real JavaScript with helper imports, plus a Python sub-node. If your workflows do anything non-trivial with LLM output or transformations, the difference is night and day.
Open source means you own the roadmap. n8n is fair-code licensed. Read the source, fork nodes, write your own. No feature gates. No vendor deciding your SLA.
A fifth reason worth flagging: queue mode. n8n supports a Redis-backed worker pool that handles thousands of parallel executions on your own infrastructure. You will not need this at day one, but it is why n8n scales past the point where Zapier just charges you more.
When NOT to migrate
Migration has a cost. Three situations where I tell people to stay on Zapier or pick something else.
Two to five simple workflows. Zapier Free or Starter covers you for €0 to €29/mo. The engineering time to stand up n8n and rebuild the flows will cost more than three years of Zapier subscriptions. Do not migrate for ideology.
No DevOps capacity. Self-hosted n8n is a real service. You are responsible for updates, backups, monitoring, TLS, and disaster recovery. If nobody wants that job, n8n Cloud is one option, but Make.com is usually the better Zapier alternative for no-ops teams. See the Zapier to Make migration guide for that path.
A Zapier integration n8n does not have. Zapier’s catalogue is still larger. Before committing, check n8n’s node list against every app your Zaps touch. If two critical ones are missing, you will end up writing HTTP Request nodes against raw APIs, which works but adds maintenance.
Cloud vs self-hosted: the first decision
This is the decision that shapes everything else, so make it before you start rebuilding workflows.
n8n Cloud gets you running in fifteen minutes. Starter is €20/mo for 2,500 executions, Pro is €50/mo for 10,000. You get managed updates, backups, and a public webhook URL out of the box. Pricing is comparable to Make.com at similar volume, and you trade the cost advantage for zero ops.
n8n self-hosted is where the economics get interesting. A €5-20/mo VPS (Hetzner CX22 is my default, see the Hetzner vs AWS comparison) runs n8n comfortably for small to medium workloads. Add PostgreSQL and Redis when you need queue mode. You own the data, you control the network, and the marginal cost of an extra 10,000 executions is roughly zero.
The honest break-even: below 10,000 executions per month with no data sovereignty pressure, Cloud (or Make.com) wins on total cost of ownership because your time is not free. Above that, or if regulation forces your hand, self-hosted pays for itself quickly. I walk through the setup in the n8n self-hosting guide (German), and there is more on the tradeoffs in Make.com vs n8n for production workloads.
Zapier concepts and n8n equivalents
The mental model port is mostly one-to-one. Here is the translation table I keep in my head.
| Zapier | n8n equivalent |
|---|---|
| Zap | Workflow |
| Trigger | Trigger node (Cron, Webhook, or app-specific trigger) |
| Action | Regular node |
| Filter | IF node |
| Paths | Switch node with multiple outputs |
| Delay | Wait node |
| Storage | Data Store, or a table in n8n’s PostgreSQL, or an external store |
| Formatter | Code node (JavaScript) |
| Digest / batching | Item Lists node plus Code transformations |
| Sub-Zap | Execute Workflow node |
Two differences that trip people up. First, n8n is item-based: most nodes run once per item in the incoming array. Feature once you internalise it, confusing if you expect Zapier’s linear pass. Second, n8n’s Code node exposes full item context, so you reach back into earlier nodes with $('Node Name').item.json.field rather than juggling Zapier’s field mapping UI.
Account and instance setup
Keeping this brief because the self-hosting guide covers the full setup.
n8n Cloud: sign up, pick a region (Frankfurt is available), and you have a workspace with a public webhook URL in minutes.
Self-hosted via Docker Compose: pull the image, mount a volume for the SQLite or PostgreSQL data, set N8N_ENCRYPTION_KEY and WEBHOOK_URL, put it behind a reverse proxy with TLS. I run it under systemd on Debian for clean restarts and log handling.
Credentials: in the n8n UI, each integration has an OAuth or API-key flow. You enter them once, n8n stores them encrypted with your encryption key, and all workflows reference them by name. This is the same pattern as Zapier’s connected accounts.
Translating common patterns
This is where most migration time is spent. The patterns below cover 80% of what I see in real Zapier accounts.
Webhook in > webhook trigger. Zapier’s catch-hook URL maps to n8n’s Webhook trigger. The twist: n8n has a test URL and a production URL that behave differently. Test only catches one payload at a time while the editor is open. Activate the workflow to get the production URL, which is what upstream systems hit.
Schedule > Cron trigger. Familiar cron syntax. The gotcha: n8n’s cron defaults to UTC. Set the workflow’s timezone in settings, or your “9 AM daily” Zapier Zap will fire at 10 or 11 in Madrid depending on DST.
Zapier Code > n8n Code node. JavaScript is the richest path. You get previous node data through $input.all() and $('Node Name').all(), you can require built-in modules, and return an array of items to fan out. Python works via a separate sub-node.
Zapier Storage > n8n Data Store or Execute Query. For small key-value state, n8n’s built-in Data Store node works. For anything bigger, I point an Execute Query node at the same PostgreSQL n8n uses, on a separate schema. External options (Redis, Supabase) are one node call away.
Zapier’s formatter tricks > straight JavaScript. Zapier’s Formatter covers dates, text, numbers. All one-liners in a Code node. Feels like a downgrade for two days and then you never look back, because you chain transformations without six sequential Formatter steps.
Zapier’s OpenAI node > n8n OpenAI node or HTTP Request. n8n has first-party nodes for OpenAI and Anthropic. For anything custom (streaming, tool use, extended thinking on Claude), I drop to HTTP Request and hit the API directly. See Claude API vs OpenAI for business automation for the model-choice angle.
Zapier’s chat memory AI > n8n LangChain nodes. n8n’s LangChain integration is maturing fast: memory, agents, tool calling, vector stores. Good enough for most RAG and assistant workflows without writing custom orchestration.
The migration strategy that actually ships
A six-step rollout I have used for my own workflows and client migrations.
1. Inventory every Zap. Export or screenshot each one. Tag by criticality (mission-critical, nice-to-have, experimental) and data sensitivity (PII, public, internal). If you skip this, you will forget the quiet Zap that emails a customer on signup and notice only when support tickets spike.
2. Stand up an n8n instance. Cloud or self-hosted. Configure encryption key, TLS, backups, and monitoring before you touch migration. If self-hosting, set up off-site PostgreSQL backups on day one.
3. Pilot one non-critical Zap. Something boring: a notification, an internal digest, a log-to-spreadsheet flow. Rebuild it in n8n, activate it, and run it in parallel with the Zapier original for a week. This is where you learn n8n’s item model.
4. Validate for one to two weeks. Keep both versions live. Diff outputs daily. When they match for seven consecutive days on a non-trivial flow, migrate the next tier.
5. Migrate by shared-integration batches. All Gmail Zaps together, then Slack, then HubSpot. Credentials only need setup once per integration, and you build reusable sub-workflows inside each batch. Migrating randomly wastes that compounding.
6. Cutover and monitor. For each batch, switch upstream webhooks and disable the Zapier original (do not delete for two weeks). Add n8n’s error workflow feature and wire a notification channel (Slack, Telegram, email). Monitor execution count and error rate for a fortnight. Then delete the Zapier originals.
Plan on two to six weeks of calendar time for a team with 30-80 Zaps. Most of that is validation, not rebuilding.
Cost math, honestly
Rough numbers at 2026 prices.
| Plan | Monthly | Tasks / executions |
|---|---|---|
| Zapier Team | $103 | 2,000 tasks |
| Zapier Company | $208 | 50,000 tasks |
| n8n Cloud Starter | €20 | 2,500 executions |
| n8n Cloud Pro | €50 | 10,000 executions |
| n8n self-hosted (Hetzner CX22) | €5-20 | Effectively unlimited |
Two things to watch. Zapier counts tasks per step, so a five-step Zap that fires a thousand times is 5,000 tasks. n8n counts executions per workflow run, so the same five-step workflow fired a thousand times is 1,000 executions. The apples-to-apples break-even is not where the raw numbers suggest.
Break-even for self-hosted: roughly 10,000+ executions per month, OR any data sovereignty requirement that makes a US SaaS a non-starter. Below 10,000 executions with no regulatory pressure, n8n Cloud or Make.com usually wins once you price in operating time.
The honest extra cost on self-hosted: plan for 2-4 hours per month of ops work (updates, backup verification, occasional restarts). At a consulting rate that is €200-600/mo of hidden cost. Factor it in.
n8n for AI workflows
This is where n8n pulls ahead for anyone shipping AI automations as part of the product, not just around it.
Model swapping is a one-setting change. LangChain nodes flip between Anthropic and OpenAI without rewriting the workflow. For teams evaluating providers or running A/B cost experiments, that is a real advantage.
Custom Claude calls via HTTP Request. When I need prompt caching, extended thinking, or the latest Claude 4.7 tool-use features, I drop the LangChain node and wire an HTTP Request node to the Anthropic API directly. Patterns I use are in the Claude API German guide; the code is language-neutral.
Agent-style workflows with real error handling. Zapier’s Paths are shallow. n8n’s Switch, IF, Loop Over Items, and Error Trigger nodes let you build workflows that retry, branch on LLM decisions, and hand off to sub-workflows. I have agents running in production that do three-step reasoning loops inside a single n8n workflow, not buildable in Zapier without a lot of external glue.
Queue mode for scale. When one webhook kicks off a cascade of LLM calls, queue mode moves execution to a Redis-backed worker pool. Thousands of parallel runs on infrastructure you control.
The gotchas to plan around
I have hit most of these.
Credentials are tied to the instance. If you migrate between n8n instances (dev to prod, Cloud to self-hosted), credentials do not move cleanly. Plan to re-enter them. Document OAuth scopes and API-key values somewhere secure.
Webhook URLs change on migration. Not only from Zapier to n8n, but also every time you move n8n instances. List upstream systems that hit your webhooks (Stripe, HubSpot, custom apps) and plan the update order.
Rate limiting is your responsibility. Zapier backs off and retries on 429s. Self-hosted n8n does not, unless you build retry logic. For rate-limited APIs, add HTTP Request retry configuration or a Code-node retry loop.
Cron default is UTC. Scheduled workflows need an explicit timezone or they drift across DST boundaries. Trips almost every migrator outside UTC. Set it in workflow settings.
N8N_ENCRYPTION_KEY is critical. Lose it and every credential in the database is unrecoverable. Back it up somewhere other than the VPS. I keep mine in a password manager with a second copy in an offline encrypted file.
Queue mode is a separate deployment. Not a toggle. You need Redis, worker containers, and main-instance configuration for queue execution. Plan for it before you need it.
Error workflow is opt-in. n8n silently swallows failures unless you set one. First week of production, every workflow should have one pointed at a notification channel.
When to pick Make.com instead
If you are reading a zapier to n8n migration guide, you have probably already decided. Three situations flip my recommendation.
No ops capacity and want a better Zapier alternative. Make.com is visual-first, handles scale well, no self-hosting burden. The Zapier to Make migration guide walks through that move.
No self-hosting requirements now or planned. If data residency is not on your roadmap and you do not want to operate infrastructure, Make.com on an EU tier covers most of what self-hosted n8n offers with better UX for non-engineers.
Your team is visual-first, not code-first. Make’s scenario builder is friendlier for business users. n8n leans technical once you use Code nodes and HTTP Request nodes for real work. The Make vs n8n comparison (German) covers this tradeoff.
Which should you choose?
The decision in one page:
- Stay on Zapier if you have under 5 workflows, no DSGVO pressure, and Zapier’s Free or Starter tier covers you.
- Move to Make.com if you need more power than Zapier but have no ops capacity and no self-hosting requirement.
- Move to n8n Cloud if you want n8n’s open-source model and code flexibility but do not want to operate infrastructure.
- Move to n8n self-hosted if you have 10,000+ executions/month, DSGVO or data residency requirements, or a team that can run a service. This is where n8n’s economics and control actually pay off.
For most DACH teams I work with, the path is Zapier > Make.com if they are small, or Zapier > n8n self-hosted if they have the engineering to run it. The middle path (n8n Cloud) is narrow but real.