How to Migrate from Zapier to n8n (2026): The Cutover Playbook and the Execution-Count Trap

Before you commit

Audit what you are actually paying for

The first move is not opening n8n. It is finding out what your Zapier bill is really made of, because the number you need is not "how many steps do I have" — it is how many billable tasks do I consume, and which Zaps consume them.

Zapier's own documentation is explicit about which steps count. A task is charged when Zapier successfully completes a unit of work, which in practice means action steps. Everything else in the following table is free:

Pull the three exports you need

Zapier gives you everything required to build a real inventory, and almost nobody uses it:

• Analytics dashboard reports. Download CSV reports of top task usage by Zap, by app, and by member — plus the Zaps with the highest error rates. Capped at 5,000 rows per report. This single export tells you which 10% of your Zaps are 80% of your bill, which is the only list that matters for sequencing the migration.
• Zap history export. Export up to 5,000 Zap runs at a time as CSV or JSON, filtered to specific Zaps. Use this to get real run volumes and real payload shapes — you will need both to size n8n and to validate the rebuild later.
• Member task usage. On Team and Enterprise accounts, "Download member data" produces a CSV of task consumption per member for the current billing cycle. This is how you find the shadow automations built by someone who left the company.

By the end of Phase 0 you should have a spreadsheet with one row per Zap: trigger type, billable action count, monthly runs, monthly tasks, error rate, and the apps involved. Everything downstream keys off this sheet.

Sort before you build

Classify every Zap into one of four buckets

Treating the migration as "rebuild all 40 Zaps" is how a two-week project becomes a two-month one. Zaps do not port uniformly. Sort them first.

The Class 3 example worth understanding

Digest by Zapier is the cleanest illustration of why "n8n is cheaper per run" is not a universal truth. Digest collects entries across many Zap runs and releases them on a schedule — daily, weekly, or once a threshold is hit — and it costs zero tasks.

n8n has no equivalent built-in. You rebuild it as two workflows: a collector that appends each event to a Data Table (native persistent storage, available on Cloud and on self-hosted from v1.113.1), and a scheduled sender that reads the table, aggregates, sends, and clears it. Functionally identical, and architecturally cleaner. But the collector now costs one execution per event where Zapier charged nothing, and the sender costs one execution per fire.

The number that decides everything

Run the break-even math on the right unit

Here is the part that no amount of rebuilding skill can rescue if you get it wrong.

How n8n counts an execution

Per n8n's documentation, production executions count like this:

Read the first and third rows together and the trap becomes obvious. On Zapier, a polling trigger checking a folder every 15 minutes is free forever; you only pay when an action runs. The instinctive n8n rebuild is a Schedule Trigger every 15 minutes that fetches, filters, and acts. That Schedule Trigger fires 2,880 times a month and bills every one of them.

Same business logic. Two orders of magnitude apart in cost. The rule: use a native app polling trigger or a webhook wherever one exists, and reserve the Schedule Trigger for work that genuinely must run on a clock — nightly reconciliations, report generation, cleanup jobs.

The tier cliff, not the tool, is the real decision point

n8n Cloud's published pricing (August 2026) is €20/month annually for Starter (2,500 executions), €50/month for Pro (10,000 executions), and €667/month for Business (40,000 executions, plus the self-hosted license, SSO/SAML/LDAP, and Git version control). Enterprise is custom. All paid tiers include unlimited users, unlimited workflows, unlimited steps per workflow, and every integration — executions are the only meter.

Plot that and the shape of the decision changes. Pro to Business is a 13x price increase for 4x the executions. That cliff, not any comparison against Zapier, is what determines whether you should self-host.

One more line item worth knowing: n8n runs a startup program offering 50% off self-hosted Business — €333/month billed annually — for companies with fewer than 20 employees and under €5M in total funding. If you are in that band and want Business features without running Community Edition, ask before you architect around the full price.

Infrastructure

Stand up n8n the way it will run in October

If you are deploying in the second half of 2026, one date should shape your setup: n8n 3.0 lands in October 2026 and drops npm/npx installs entirely. Self-hosted deployments will require Docker. It also removes the legacy Function node, the legacy Function Item node, the Item Lists node, and the $getPairedItem expression helper; changes Execute Workflow node behavior; retires Chat hub; and discontinues workflow URL imports in the editor.

Sizing and the queue-mode threshold

n8n runs on SQLite out of the box, which is fine for a single-process evaluation instance and unsuitable for anything else — SQLite does not support concurrent writes from multiple processes and will corrupt data if you try. Production means PostgreSQL.

The moment you need more than one worker, you need queue mode: set EXECUTIONS_MODE=queue on the main instance and every worker, back it with PostgreSQL (13+ is the documented queue-mode minimum) and Redis (6+ if you set a Redis username). The main process receives webhooks and pushes jobs to Redis; workers pull and execute them. We cover the full production topology in our n8n self-hosting and queue mode production setup guide.

On sizing, RAM is the bottleneck, not CPU. Each in-flight execution holds its payload in memory, and a single webhook workflow processing a large JSON body can consume 150–300 MB by itself. A 2 GB/1 vCPU box will technically boot n8n; production workloads generally want 4 cores and 8 GB or more, and a team running 50+ workflows with steady webhook traffic should plan for 4–8 cores, 16 GB, and NVMe storage.

Budget the OAuth work honestly

Zapier ships pre-approved OAuth apps for its connectors; you click "connect" and you are done. On n8n you will register your own OAuth applications with Google, Microsoft, Salesforce and similar vendors for several integrations — which can mean consent screens, verification, and in some cases a review process measured in days. For mainstream tools it is 5–10 minutes each. For anything requiring vendor approval, start it in Phase 3, not the night before cutover.

The rebuild

Translate concepts, not screens

The architectural difference matters more than any node-to-node mapping. Zapier is sequential: a trigger, then actions in a fixed order, with data passed implicitly from step to step. n8n is a node graph where each node emits a full JSON object to whatever is connected downstream, and you reference fields explicitly from the node that produced them. Trying to reproduce a Zap step-for-step fights the tool. Reproduce the outcome.

Rebuild in the order your Phase 0 spreadsheet dictates: highest billable-task consumers first, then highest error rates, then the long tail. Test each node individually and inspect its output as you go — n8n's per-node execution view is the fastest debugging loop you will get, and it costs nothing because editor runs are not billed.

Where you are rebuilding data-sync patterns specifically, our walkthrough of syncing Google Sheets with a CRM covers the native, iPaaS, and direct-API approaches to the same problem, and the dedupe logic there transfers directly.

The part everyone gets wrong

Shadow-run. Do not parallel-run.

Standard advice says to run Zapier and n8n side by side for a few days and compare. Taken literally, this is a data-integrity incident waiting to happen. If both platforms are live on the same trigger and both write to the same destination, you get two CRM records, two invoices, two Slack messages, two emails to the customer for every single event.

Do it in three stages instead.

Stage A — Shadow (3–7 days per batch)

Activate the n8n workflow on the real trigger, but replace every terminal write node with a log sink: a Data Table, a Postgres table, or a Google Sheet. n8n processes 100% of real production traffic and writes nothing anywhere that matters. Then diff what n8n would have written against what Zapier actually did. This catches the failure class that kills cutovers — date format drift, timezone handling, field mapping that looks right and is subtly wrong, and duplicate-detection logic that behaves differently.

Stage B — Canary with a free traffic split

Once the diffs are clean, let n8n write for real — but only for a slice, and make sure exactly one system handles each record. The elegant way to do this: add a Filter step to the Zap that excludes the slice n8n now owns (region = EU, or record type = renewal, or account ID modulo 10 = 0), and add the inverse condition in n8n.

Stage C — Make writes idempotent where you cannot split cleanly

Some flows do not partition neatly. For those, make the write itself safe to run twice: upsert on a stable external ID rather than create, use n8n's Remove Duplicates node, or keep a dedupe ledger in a Data Table keyed by source event ID. Then a duplicate execution is a no-op rather than a duplicate record. This is worth doing permanently, not just during the migration — it is also what makes replays and retries safe afterwards.

Cutover

Inventory every webhook before you turn anything off

This is the single most common cause of silent post-cutover failure, and it is structural: Zaps triggered by "Webhooks by Zapier" have a hooks.zapier.com URL that lives in someone else's system.

Your payment provider, your form tool, a partner's integration, a script someone wrote three years ago — each holds that URL in a config screen you may not have access to. Turn the Zap off and those events do not error loudly. They vanish.

The mitigation is a forwarder Zap. Before cutover, strip the old Zap down to a single action: POST the incoming payload to your new n8n webhook URL. Keep the same hooks.zapier.com endpoint alive so nothing external breaks, and let it relay into n8n. It costs one task per event, which is a rounding error against the confidence it buys. Retire each forwarder only once you have confirmed with the owning system that the URL has been updated — and if you never find the owner, the forwarder can simply stay.

• List every Zap with a Webhooks by Zapier trigger and its exact URL
• For each, identify the calling system and the human who owns it
• Stand up the n8n Webhook node and confirm it accepts the real payload shape
• Convert the old Zap into a forwarder rather than deleting it
• Update the caller's configuration; confirm traffic arrives at n8n directly
• Only then retire the forwarder
• Leave Zapier's plan active for one full billing cycle after the last cutover

That last point is not caution for its own sake. Zapier's Zap history is your audit trail for the migration period, and downgrading early can cost you access to it exactly when a discrepancy surfaces.

Day two

Build the operational layer Zapier gave you for free

Zapier handles failures, retries, alerting, uptime, and upgrades on your behalf. Self-hosted n8n hands all of that back to you, and the honest version of the cost comparison includes it.

Error handling is opt-in

Configure an Error Workflow for every production workflow — no exceptions. Because dedicated error workflows do not count toward your execution quota, there is no cost argument against instrumenting all of them. Route failures to a durable store (Postgres, a Data Table, or S3) plus a real alerting channel, so you have a dead-letter queue rather than a notification someone missed.

At the node level, enable Retry On Fail with a sensible attempt count and wait interval for anything hitting an external API — that covers the transient timeouts and rate limits that otherwise show up as mysterious data gaps. Use error output branches for non-critical steps (an optional enrichment lookup should not abort a workflow) and let critical steps fail loudly.

Backups, upgrades, and the ongoing tax

• Backups: PostgreSQL dumps on a schedule, plus N8N_ENCRYPTION_KEY stored separately in a secrets vault. A database backup without the key restores workflows with dead credentials.
• Upgrades: n8n releases frequently, and major versions can bring breaking changes to node configuration, credential format, or database schema. Pin your image tag, test upgrades in a staging instance, and keep a rollback path. Version 3.0 in October 2026 is the near-term one to plan for.
• Steady-state effort: for a small team on a stable instance, roughly an hour a month once past initial setup. Price that at your loaded engineering rate and put it in the comparison table. It is what turns "€8 a month versus €667" into an honest number rather than a marketing one.

If you are building out broader automation infrastructure alongside this, our survey of no-code automation tools sorted into the three categories that actually matter covers where n8n sits relative to the rest of the field.