Zapier to n8n migration in 2026 — the 5-step playbook

Zapier raised prices in 2024 and again in early 2026. For SMBs running anywhere between 10,000 and 100,000 tasks per month, the monthly bill stopped being trivial somewhere around Q3 2025, and "should we move?" has become the single most common opening question on NexFlow's 15-minute scoping calls. We've now done 23 Zapier → n8n migrations in the last 18 months. This is the playbook.

The honest answer up front: n8n is not strictly cheaper than Zapier for every workload. It is cheaper for almost every committed workload — i.e. workflows you'll keep running every month for the next 12 months. Spinning up a Zap for a one-off campaign and tearing it down a week later is something Zapier is actually better at. The migration math turns positive when your automation estate stabilises around a known set of recurring jobs, which is true for most SMBs by year 2.

Why this question is everywhere in 2026

Three forces hit at once. Zapier's pricing climbed past US$100/month for Team plans at typical SMB volume (50,000 tasks). n8n shipped version 2.0 in January 2026 with 70+ AI nodes and persistent agent memory — closing the last functional gaps to Zapier and Make. And the broader "we want to own our automation stack" sentiment, which used to be a developer-only opinion, has gone mainstream as SMB owners watch their SaaS subscription totals climb every renewal cycle.

A small Australian retail operator we mapped in March was paying US$179/month for Zapier (300K tasks) while two-thirds of those tasks were duplicate-fire webhooks from an old Shopify-Klaviyo bridge that had been live since 2022. The fix wasn't "migrate to n8n" — it was "delete the bridge first, then migrate the rest." This is the most underrated step in every Zapier → n8n conversation: your Zapier bill is probably half junk.

Step 1 — audit your Zapier estate (1 day)

Export every Zap. Zapier's admin console lets you download a CSV of all Zaps with task-count history per Zap. The CSV is your map. Add three columns by hand:

• Business criticality (1–5). 5 = "if this breaks we lose money today." 1 = "nobody would notice for a week."
• Replacement complexity (1–5). 5 = "fragile, has 8 paths, integrates with a CRM custom field nobody documented." 1 = "trigger → action, basic."
• Last reviewed (date). When was the last time someone confirmed this Zap is doing the right thing? If you can't remember, it's probably a candidate for deletion, not migration.

Step 2 — score and triage (½ day)

Compute a score for each Zap: monthly_tasks × business_criticality ÷ replacement_complexity. Sort descending. You're looking for two things in the result:

1. The top 20% of rows by score will account for 80% or more of your monthly Zapier cost. These are the migration targets.
2. The bottom 20% of rows will include 3–6 zombie Zaps you can delete on the spot. Confirm each by checking the "last task run" date — anything that hasn't fired in 90 days is almost always safe to disable.

The middle 60% is the hardest call: low volume each, but collectively non-trivial cost. Our rule: migrate them in a second batch if and only if the top-20% migration goes well. Often you'll find that the cost reduction from migrating the top 20% alone already drops your Zapier plan a tier or two, making the long-tail migration not worth the engineering time.

Step 3 — port the top 20% to n8n (5–10 days)

Set up n8n first. Self-hosted on Hetzner is our default for SMB workloads — see our Hetzner setup guide for the canonical 30-minute install. If you want zero ops overhead, n8n Cloud at US$50/month covers 20K executions and integrates with the same Zaps-replacement workflow.

For each Zap you're porting, recreate it node-by-node. Resist the urge to "improve" the workflow while migrating. Match Zapier's behaviour exactly, even where it's wrong, so the shadow-mode comparison in step 4 is meaningful. Improvements come after cutover, not during.

Three things to set explicitly that Zapier did implicitly:

• Retries. Zapier retries failed steps automatically with an opaque schedule. n8n's default is no retry. Add a retry-on-error config to every external-call node — we typically use 3 retries at 5s, 30s, and 120s.
• Credentials. n8n stores credentials encrypted with the N8N_ENCRYPTION_KEY environment variable. Set this once and back it up to a password manager. Re-authenticate every OAuth connection during the migration — Zapier tokens don't transfer.
• Audit logging. Add a final Postgres-insert node to every critical workflow that logs workflow_id, started_at, finished_at, status, input_hash, output_hash. Zapier's task history gives you this for free, but only for 30 days; your audit log gives it to you forever.

Step 4 — run shadow mode for 14 days (2 weeks elapsed, 1–2 hrs work)

Both the Zap and the n8n workflow are live simultaneously. They process the same inputs but write to different output destinations (typically a "_test" suffixed table or Slack channel). Daily, you compare what each system produced for the same input. A shared Google Sheet with one row per execution and a "delta" column is sufficient — no fancy tooling required.

In the 23 migrations we've run, the median 14-day shadow-mode period surfaces two real bugs in the n8n port that wouldn't have been visible in unit testing — usually around edge cases in date parsing, null handling on optional fields, or a Zapier "skip on missing" default that wasn't carried over. Fixing these in shadow mode is cheap. Fixing them after cutover is panic.

Step 5 — cut over and decommission (2–3 days)

Cut over one Zap at a time, on a Tuesday or Wednesday morning (not Friday). For each cutover:

1. Re-point any inbound webhooks from Zapier's URL to the n8n webhook URL.
2. Disable the Zap in Zapier but don't delete it (you might need to read its configuration later).
3. Watch the n8n workflow for 24 hours. Compare execution rate and error rate to the previous day's shadow data.
4. Move to the next Zap.

Once all top-20% Zaps have been cut over for 7 days without incident, downgrade the Zapier plan. Don't cancel — keep the Starter tier alive for the long-tail Zaps and as a contingency.

The four traps that catch first-time migrators

1 · "Improving" workflows during the port

Migration and improvement are different projects. Combining them means you can't tell whether a discrepancy in shadow mode is a port bug or an intentional change, and you'll spend hours debugging your own additions. Port first, ship, then iterate.

2 · Skipping the credential setup discipline

First-time n8n users often store credentials inline in HTTP nodes "for now" and never come back. Six months later, rotating a Stripe key means hunting through 17 workflows. Use n8n's Credentials feature from day one — every API key, every OAuth token. Future-you will pay for the wine.

3 · Ignoring the webhook URL change

Anything that POSTs into Zapier — third-party services, form builders, marketing tools — has the Zapier webhook URL baked in. n8n's webhook URL is different. Make a list during step 1; the cutover is incomplete until every external caller is repointed.

4 · No backup discipline on n8n

Zapier backs up everything for you. n8n self-hosted does not. Set up daily encrypted backups of your Postgres database (n8n's workflow definitions and credentials live there) on day one of the migration, not on day one of the post-cutover incident. Our Hetzner guide covers the exact cron and age-encryption pattern we ship on every install.