Migrating from Zapier to n8n: A Real Migration Checklist

TL;DR

• There is no automated migration tool. Every workflow is a manual rebuild, node by node.
• The pricing model shifts from per-task to per-execution, which changes the cost calculus significantly for multi-step workflows.
• Community nodes fill integration gaps but carry supply-chain risk; audit them before going near production.
• Self-hosting means you own uptime, backups, credential security, and version updates — Zapier handles all of that for you today.
• If your Zaps are simple, low-volume, and non-technical-team-owned, migrating may cost more in engineering time than you save.

---

The usual reason people look at migrating is cost. For 10,000 runs of an 8-step workflow, Zapier charges for 80,000 tasks, requiring a plan costing $300–500+/month, while n8n charges for 10,000 executions at roughly $50/month on the Pro cloud plan. That gap is real. What tends to go unsaid is that closing it requires rebuilding every workflow from scratch and then owning an infrastructure layer that Zapier manages invisibly for you.

I have worked on n8n automation builds, including production AI workflows — see the Biz365 AI project for context on what a production n8n environment actually involves. This checklist is what I would hand someone before they committed to a migration.

What does not port automatically?

There is no universal migration tool that reliably converts Zapier Zaps to n8n workflows. Complex logic, custom filters, and data transformations all require manual reconstruction. This is the first thing to accept. You are not migrating; you are rebuilding with n8n as the target.

Concretely, here is what has to be re-done by hand:

• Triggers. Zapier triggers are configured through its UI and stored in Zapier's backend. In n8n, triggers are nodes — Webhook, Schedule, or service-specific — that you wire up from scratch. Webhook URLs change completely, so any third-party system sending to a Zapier webhook URL needs to be updated to point at the new n8n endpoint.
• Credentials. Every OAuth connection, API key, and service account has to be re-entered in n8n's credential store. OAuth re-authorisations sometimes require a third-party app admin to approve again.
• Filters and branching. Zapier's filter steps map to IF nodes or Switch nodes in n8n. The logic is equivalent but the expression syntax is different — n8n uses JavaScript-style expressions while Zapier uses its own condition builder.
• Formatter steps. Zapier's built-in text, date, and number formatters do not have a single equivalent node. You write these as Code nodes (JavaScript) or chain basic n8n utility nodes together.
• Paths. Zapier's Paths feature is a multi-branch conditional. n8n handles this with IF or Switch nodes, but the branching model is different enough that non-trivial Paths workflows need deliberate redesign rather than direct porting.

In practice, migration means rebuilding the trigger, re-mapping each action to n8n nodes or HTTP Request calls, re-entering credentials, and testing against real data before cutover. The logic usually gets simpler in n8n because you can collapse several Zapier steps into one workflow with cleaner branching. That is genuinely true, but it requires understanding both tools well enough to see the simplification opportunity rather than just copying step-for-step.

The integration gap: when does n8n not have the node you need?

As of 2026, n8n includes more than 400 official integrations, covering popular tools like HubSpot, Google Workspace, Slack, Notion, and Airtable. Zapier advertises 7,000+ integrations and Make claims 2,000+; n8n's 1,000+ (counting community nodes) looks smaller on paper. But those numbers obscure the fact that Zapier's count is higher partly because they count every trigger and action variation separately.

n8n's HTTP Request node can connect to any API without a dedicated connector, making the effective integration count unlimited — but building against raw APIs takes engineering time and means you are maintaining that integration yourself. Community nodes are npm packages that anyone can install on a self-hosted n8n instance, adding new triggers, actions, and integrations.

The community node ecosystem is where the real risk sits. Earlier this year, attackers infiltrated n8n's community node ecosystem with a malicious npm package masquerading as a Google Ads integration, which tricked developers into entering OAuth credentials through what appeared to be a legitimate form and then silently exfiltrated them — a supply-chain attack that demonstrated how threat actors are exploiting trust in community-maintained integrations.

The practical rule: only install community nodes from packages with a verifiable public author, active maintenance history, and source you can read. Most community nodes are open-source and reviewed by developers, but you should always test them before deploying in production environments. If the service you need has no official node and no trustworthy community node, plan to build against its API directly with the HTTP Request node.

Is migrating the wrong call?

There are situations where the answer is yes. Run through these before you commit:

Situation	Migrate?	Reason
Simple Zaps, low volume, non-technical owner	No	Engineering rebuild cost exceeds years of pricing difference; Zapier's managed runtime is a real product you are giving up
Multi-step, high-volume workflows with a technical team	Yes	Per-task billing compounds fast; n8n's execution model is materially cheaper at scale
AI-heavy workflows (LLMs, agents, RAG)	Yes	n8n offers native LangChain integration, support for local LLMs via Ollama, vector database connections, and no per-step timeout that could interrupt long LLM responses
Data residency or GDPR hard requirement	Yes	Zapier is cloud-only with no self-hosting option; every piece of data flows through Zapier's US-based cloud infrastructure
Relies on niche Zapier apps with no n8n equivalent	Caution	Verify the integration exists and is official before starting; community-node alternatives carry supply-chain risk
No in-house engineer to maintain n8n instance	No (or hire one)	Self-hosting means you are responsible for setup, version updates, security patches, backups, credential security, uptime monitoring, compliance, and API updates for any endpoints you connect to

The migration checklist

If you have decided to move forward, run through these phases in order. Do not cut the parallel-run phase. Plan for one to two weeks of parallel operation, testing each rebuilt workflow against expected outputs before deactivating the corresponding Zap.

Phase 1 — Audit (before you touch n8n)

1. Export a full list of your active Zaps with their step counts and monthly task consumption. Zapier's dashboard shows this per Zap.
2. Categorise each Zap: simple linear, filter/path branching, or code-heavy. Simple ones are fast to rebuild; branching and code-heavy ones are not.
3. Flag every app integration your Zaps touch. Check the official n8n integrations directory for official node coverage before assuming a community node will suffice.
4. Identify which Zaps are business-critical and which are nice-to-have. Migrate nice-to-haves first as practice runs.
5. Note every webhook URL that a third-party service sends data to. Those URLs will change and the third-party systems need to be updated at cutover.

Phase 2 — Environment setup

1. Decide on hosting: n8n Cloud, self-hosted on a VPS, or Docker on your own infrastructure. n8n Cloud has no permanent free tier in 2026 — only a 14-day trial. Self-hosted removes execution caps but adds operational overhead.
2. If self-hosting, set up Postgres as the n8n database backend, not SQLite. SQLite will cause performance problems under any meaningful workflow volume.
3. Configure environment variables for credential encryption key, timezone, and webhook base URL before adding any workflows.
4. Set up a basic monitoring stack — at minimum, a health-check ping on the n8n webhook URL and alerting if it stops responding. Be prepared to debug edge cases like workflows that stop firing, version updates that break things, and performance issues because your database fills up.

Phase 3 — Rebuild and test

1. Rebuild triggers first. Confirm the webhook endpoint is reachable from the public internet before wiring up the rest of the workflow.
2. Re-enter credentials one service at a time, testing each auth connection immediately after adding it. OAuth failures discovered mid-workflow rebuild are time-consuming to diagnose.
3. Rebuild logic nodes. Use the n8n Code node for anything that was a Zapier Formatter or JavaScript action — it is cleaner than chaining multiple utility nodes.
4. Budget time for testing webhooks and authentication — those are where surprises hide.
5. Run the rebuilt workflow against real test data, not the sample payloads n8n generates. Sample payloads often omit edge cases your Zap was already handling.

Phase 4 — Parallel run and cutover

1. Run both Zap and n8n workflow simultaneously for one to two weeks. Compare outputs at every step.
2. Update webhook-receiving third-party systems to the new n8n URL only after output comparison passes.
3. Deactivate the Zap — do not delete it yet. Keep it inactive for two weeks as a rollback reference.
4. Pin the n8n version in your deployment after a stable run. n8n releases a new minor version most weeks, and uncontrolled updates to a production instance are a common source of breakage.

What about the Notion node change?

If any of your Zaps connect to Notion, be aware of a breaking change on the n8n side. The Notion node has been overhauled with a new v3, migrating to Notion API 2026-03-11, which replaces database queries with data sources, and adds a Data Source resource, markdown get/update operations for pages and blocks, JSON block support, and file downloads for database pages. Database IDs are no longer accepted for database-page query and create operations; a data source must be selected instead. If you are building a Notion workflow today, build to v3 from the start rather than inheriting the older node pattern from a Zapier migration.

For a broader picture of what AI-native workflows look like once you are on n8n, the AI-powered lead qualification post walks through a production n8n setup in detail. And if you are comparing the two platforms before committing, the n8n vs Zapier breakdown is worth reading first.

If you need the migration done without disrupting live operations, the n8n automation service covers the full rebuild, parallel testing, and cutover as a contained engagement. Most engagements start around $5K; smaller well-scoped work is considered case-by-case.

FAQ

Is there a tool that automatically converts Zaps to n8n workflows?

No. There is no universal migration tool that reliably converts Zapier Zaps to n8n workflows; complex logic, custom filters, and data transformations all require manual reconstruction. Some community scripts exist for exporting Zap metadata, but they do not produce working n8n workflow JSON. Every workflow is a rebuild.

Will my Zapier webhook URLs still work after migrating?

No. Zapier and n8n generate entirely separate webhook endpoints. Any third-party system that POSTs to a Zapier webhook URL needs to be updated to the new n8n URL before or at the point of cutover. If you control both ends, this is straightforward. If a third-party vendor is sending the webhook on your behalf, you need to coordinate that change with them in advance.

Do I need DevOps experience to self-host n8n?

Teams that go for n8n self-hosting are typically either small, highly technical, and willing to own the operational burden to cut costs, or large, with an IT team that already manages infrastructure and drawn to n8n for data residency, compliance, or on-premises control. If you are neither, n8n Cloud is a reasonable middle ground, though it carries execution caps rather than unlimited runs. Managed self-hosting through a provider is a third option that splits the difference.

How do I handle Zapier integrations that have no official n8n node?

n8n's HTTP Request node can connect to any API without a dedicated connector. For most REST APIs this is the right path: authenticate with an API key or OAuth credential stored in n8n's credential vault, then call the API endpoints directly. The trade-off is that you are building and maintaining that integration yourself. Community nodes are an option, but audit the package's source and maintenance history before installing one in production.

What is the biggest operational difference I will notice post-migration?

Version updates. Zapier handles platform updates invisibly. On self-hosted n8n, you are responsible for version updates, security patches, backups, uptime monitoring, and API updates for any endpoints you connect to. This is not a dealbreaker, but it is a real ongoing cost. Pin your n8n version, test updates in a staging environment, and do not let the instance auto-update in production without a review step.