Migrating From Zapier to n8n: A Zero-Downtime Cutover Playbook

Executive verdict

Migrate with a parallel run, not a big-bang switch: rebuild each Zap in n8n, run it in shadow mode against live traffic for at least 7 days, and only cut over once the outputs match — with the Zap turned off, not deleted, for a 14-day rollback window.

A big-bang switch looks faster and is where migrations lose data. The failure is rarely a crash. It is a workflow that runs perfectly and writes slightly different data — a timezone shifted, a line item duplicated — and nobody notices for three weeks. Shadow mode catches that before customers do.

If you haven’t decided whether to move at all, start with the numbers: Self-Hosted n8n vs Zapier: Where the Break-Even Actually Is.

Tool / Approach	Best For	Pricing / Self-Host Cost	Setup Effort	Critical Dealbreaker	Action CTA
Parallel run on n8n Cloud	Most teams, 2k–10k runs/month	€50/mo (Pro, 10k executions) plus one month of overlap with Zapier	1–2 weeks elapsed	You pay both platforms during the overlap	Try n8n Cloud →
Parallel run on self-hosted n8n	Above 10k runs/month, or data-residency needs	VPS from $14.99/mo (renewal price) plus the same overlap	1–2 days of infra, then the same 1–2 weeks	You own uptime, upgrades and backups	Get a VPS →
Big-bang switch	Fewer than ~5 simple Zaps with no money or customer data	No overlap cost	Hours	No fallback: a mapping error goes straight to production	—
Stay on Zapier	Under ~2,000 runs/month, non-technical owners	Per task tier — $89/mo for 5k tasks (annual)	None	Cost grows with every step you add	Try Zapier →

Prices checked September 19, 2026. n8n prices are listed in EUR.

Architecture and data flow

During the parallel run, every live event reaches both platforms. Zapier keeps doing the real work; n8n does the same work but writes to a comparison log instead of production.

                          ┌──────────────────────── ZAPIER (live) ───────────────────────┐
                          │  filter -> format -> actions -> CRM / Slack / email          │
[ Trigger / Webhook ] ────┤                                                              │
   source sends to both   │  ┌───────────────────── n8n (shadow) ──────────────────────┐ │
                          └─►│ [ Parse & Filter ] -> [ AI / LLM Node ] -> [ Storage ]  │ │
                             │   validate, dedupe      same logic         shadow log   │ │
                             │                                   ▼                     │ │
                             │                     [ Error Fallback / Alert ]          │ │
                             └─────────────────────────────────────────────────────────┘ │
                                        ▼  daily diff: n8n shadow log vs Zapier output ◄─┘

What moves through each stage:

1. Trigger / Webhook — the source system sends each event to both endpoints, tagged with an idempotency key.
2. Parse & Filter — n8n validates the payload and drops duplicates, exactly as it will in production.
3. AI / LLM node — identical prompts and model to the Zap, so outputs are comparable.
4. Storage — in shadow mode, n8n writes the record it would have created into a comparison table, not the CRM.
5. Error fallback — the error workflow is already live, so you learn how n8n fails before it matters.

Production implementation blueprint

1. Inventory every Zap and rank by cost

Build one row per Zap. On Team and Enterprise plans, admins can export a CSV of task usage per account member, which gives you volume without guessing. The step count is what matters: a 6-step Zap costs six times what a 1-step Zap does at the same volume.

zap_name,trigger_app,trigger_type,actions,uses_paths,uses_ai_step,runs_per_month,tasks_per_month,owner,notes
Lead routing,Typeform,webhook,5,no,yes,4200,21000,ops,rep assignment rules in Paths
Invoice sync,Stripe,webhook,3,no,no,1800,5400,finance,retries matter - money
Weekly report,Schedule,schedule,4,no,no,4,16,ops,safe first candidate

Migrate in this order: one low-risk Zap first (to learn the tooling), then the highest tasks_per_month, and anything that moves money last.

2. Map Zapier building blocks to n8n nodes

Zapier	n8n equivalent	Watch for
App trigger (polling)	The app’s trigger node, or Schedule Trigger + HTTP Request	The new trigger has no memory of what Zapier already processed
Webhooks by Zapier (catch hook)	Webhook node	New URL — every sender must be repointed
Filter by Zapier	Filter or IF node	Empty-field handling differs
Paths by Zapier	Switch node	Make the fallback branch explicit
Formatter by Zapier	Edit Fields (Set) or Code node	Date and number formats — set the timezone explicitly
Delay by Zapier	Wait node	Long waits hold an execution open
Looping by Zapier	Loop Over Items, or n8n’s native per-item processing	n8n runs each node once per item — see failure mode 2

3. Rebuild with an authenticated webhook

Use a Webhook node with Header auth (n8n also offers Basic auth and JWT). While you build, n8n gives you a Test URL that only listens when you click to test. The Production URL is registered only when you publish the workflow — a common reason “it worked in testing” and then receives nothing.

Every event carries an idempotency key and an origin tag, so the two platforms’ outputs can be matched later:

{
  "event": "lead.created",
  "idempotency_key": "lead_2026-09-19_8f21c",
  "origin": "typeform",
  "received_at": "2026-09-19T14:02:11Z",
  "lead": {
    "email": "ops@acme.co",
    "company": "Acme Logistics",
    "employees": 240
  }
}

4. Add a shadow switch at the write stage

Put a Switch node directly before every node that writes to a real system. Route on a single mode value set once at the top of the workflow:

{ "mode": "shadow" }

• shadow → write the would-be record to a comparison table (keyed by idempotency_key)
• live → write to the CRM, send the Slack message, send the email

Flipping one value later is the entire cutover — no rebuild.

5. Send live traffic to both platforms

Prefer configuring the source to send to both endpoints — many apps allow more than one webhook subscription. Avoid adding a “forward to n8n” action to the Zap: it is one more billable Zapier task per run, which can push you into the next task tier for the overlap month (see the economics below).

6. Diff, then cut over

Compare the comparison table against what Zapier actually wrote, joined on idempotency_key. Exit criteria before going live:

• at least 7 days of traffic, so weekly and weekend patterns are covered
• zero unexplained field mismatches
• every Zapier run has exactly one matching n8n record — no misses, no duplicates

Then: flip mode to live, repoint the source at n8n’s production URL only, and turn the Zap off without deleting it. Keep it restorable for 14 days.

7. Wire the error workflow before you flip

Create a workflow starting with an Error Trigger node, and select it under the migrated workflow’s settings as its Error workflow. It receives the failed execution’s ID and URL, the workflow name and the error message. One trap: it does not fire for manual test runs — only for automatic executions — so you must test it with a real production event.

Unit economics and operational bottlenecks

The migration’s cost is the overlap month. Reference case: 10,000 runs a month through a 5-action workflow (50,000 Zapier tasks). Zapier Professional, annual billing.

Line item	During overlap	After cutover
Zapier (source sends to both)	$289/mo — 50k tasks, unchanged	$0 once the plan is cancelled or downgraded
Zapier (Zap forwards to n8n)	60k tasks — over the 50k tier, so the $489 100k tier or overage	$0
n8n Cloud Pro	€50/mo	€50/mo
Rebuild time (assumption: 2 h per simple Zap × 10 Zaps × $75/h)	$1,500 one-off	—

Two conclusions:

• Dual-send from the source, not via the Zap. The forwarding step adds 10,000 tasks and pushes this workload past the 50k tier. On annual self-serve billing, overage is charged at 1.25× the base rate if pay-per-task is enabled; otherwise you’re buying the next tier.
• Payback is fast at this volume. Going from $289/mo to €50/mo, the one-off $1,500 rebuild estimate pays back in roughly six to seven months. At 2 hours per Zap the rebuild dominates — which is why you migrate the high-task Zaps first.

The rebuild hours and rate are assumptions; plug in yours. Model token costs don’t change in a migration — the same prompt costs the same whichever platform sends it.

Failure mode 1: the new trigger reprocesses — or skips — history

Symptom: on first activation, a polling trigger in n8n either picks up items Zapier already handled (duplicate records) or starts from “now” and silently skips everything in between.

Fix: cut over at a low-traffic moment, filter the first run by a start timestamp equal to the Zap’s last successful run, and rely on the idempotency check so any overlap is dropped before a write.

Failure mode 2: one event becomes many writes

Symptom: a Zap that handled an order’s line items as a single payload creates one CRM record; the n8n version creates one per line item.

Fix: n8n executes each node once for every item it receives. Where you need one output per event, aggregate first (merge the items back into one) before the write node. Shadow mode catches this as “one Zapier record, N n8n records” — it’s the most common mismatch in the diff.

Failure mode 3: a forgotten sender keeps posting to Zapier

Symptom: after the Zap is turned off, a secondary system — an old form, a partner integration — is still sending to the Zapier hook URL. Those events vanish.

Fix: before switching off, list every sender for every catch hook, and check the Zap’s history for trigger events from unexpected sources during the shadow week. Keep the Zap restorable for 14 days, and check its history again at day 3 and day 10 after cutover.

30-minute deployment checklist

• Send one real event to the production URL (not the Test URL) and confirm the record lands in the live system exactly once
• Cause a genuine automatic failure (for example, revoke an API key) and confirm the Error workflow alert arrives with the execution URL
• Confirm every migrated Zap is switched off, not deleted, and write down the steps to switch each back on
• Review the first hour of executions for item-count anomalies — any run that wrote more records than it received events