Migrate Zapier to n8n Without a Big-Bang Cutover

Migrating from Zapier to n8n without breaking production is a cutover problem, not a feature-matrix problem. You rebuild the workflow by hand, dual-run the critical path, remap webhook URLs and credentials, then flip with a documented rollback. As of mid-2026 there is still no first-party Zapier→n8n importer — n8n’s export and import path is n8n JSON and n8n packages, not Zapier Zaps.

Whether you should switch at all is owned by n8n vs Make vs Zapier 2026. This post assumes you already decided n8n wins for a subset of paths. The production spine stays the handbook.

The short answer

• No safe big-bang. Rebuild, dual-run, then flip the vendor webhook or deactivate the Zap last.
• No official importer you should bet production on. Treat Zapier exports as a spec.
• What breaks first: webhook URLs, OAuth remaps, Paths/Formatter assumptions, task-vs-execution math.
• Rollback is “Zap still on, n8n off” until you delete the Zap. Keep that door open.
• Stay on Zapier when the Zap is simple, stable, and the rebuild cost exceeds the bill pain.

Is there an official Zapier to n8n importer?

No. Not a first-party path you should trust for production as of August 2026.

n8n can download a workflow as JSON, import from file, or import from URL. Those files are n8n graphs. Zapier can export Zap workflows as JSON from Security and data — useful as an inventory and a field map. The two JSON shapes are not interchangeable.

Artifact	What it is	What it is not
Zapier Zap export (JSON)	A spec of triggers, actions, Filters, Paths	An n8n import file
Zapier account-data zip	History and product dumps for compliance	A migration pack
n8n workflow JSON / .n8np package	Move between n8n instances	A Zapier converter
Community “Zapier → n8n” gist or SaaS	Unverified marketing until you test it	A production importer

Decision list:

1. Export the Zap list if your plan allows. Use it to fill the inventory table below.
2. Rebuild the n8n workflow from that spec, node by node.
3. If someone sends you a converter, run it on a non-critical notify Zap first. Compare every field.
4. Do not load a converted graph onto a money path because the canvas looked complete.

A converter that “mostly works” is how you get a silent Filter mismatch and a week of missing leads.

When is the rebuild cheaper than staying on Zapier?

Migrate a path when two or more of these are true. One tweet about n8n being “more pro” is not a reason.

Signal	Why it matters	Counter-signal (stay)
Task bill climbing with branching you can collapse in n8n	Economics	Two-step Zap, cheap, stable for months
Need self-host or network placement	Constraint Zapier cannot meet	Legal already accepted Zapier as SaaS
Complex Paths, sub-Zaps, or code you already maintain	Fit	Niche app is Zapier-only and HTTP is worse
Named owner will run n8n ops	Without this you trade invoices for incidents	Nobody will own Error Workflows or upgrades

Zapier still meters successful action steps as tasks. Triggers, Filters, Paths, and Formatter do not count on current plans. That is why a “simple” Zap can stay cheap even when it looks busy. n8n bills and executes differently — Cloud is plan-dependent; self-hosted is infra. Recalculate cost per successful lead on n8n executions. Do not pretend one Zapier task equals one n8n run.

Rebuild cost is hours and risk, not the n8n invoice. Price the week you will actually spend:

Cost you will pay	Typical shape	Stay on Zapier when
Inventory + spec	Half a day per messy Zap	You cannot name the owner
Rebuild + fixtures	One to three days for a branched lead path	The Zap is two steps and cheap
Dual-run watch	One to two business weeks of daily diffs	Volume is so low you will never see a miss
Flip + rollback drill	An hour with two people on the vendor UI	You cannot get a second pair of hands
Ongoing n8n ops	Error Workflow, upgrades, credential rotation	Nobody will do this after week two

Do not migrate because a thread said n8n is the grown-up tool. If nobody will own credentials, upgrades, and a shared Error Workflow, stay put or hire ownership.

What should you inventory before you rebuild a single Zap?

You cannot dual-run what you have not named. Export is a spec. The inventory is the work.

Column	What you write	Why it exists
Zap name + owner	Human, not “Marketing Zap 7”	Rollback needs a person
Trigger type	Instant (webhook) vs polling	Dual-run pattern depends on this
Vendor webhook URL	Catch Hook or app-native endpoint	Remap checklist
Irreversible steps	Yes/no — money, customer email, deletes	Shadow vs live writes
Monthly task estimate	From Zapier usage, not vibes	Rebuild-cost test
n8n equivalent known?	Node names or “HTTP + Code”	Scope, not hope
Dual-run candidate	Yes/no	Skip only for missed Slack
Rollback owner	Named human with both rails	“Engineering” is not a name

Checklist before the first rebuild:

• Zap name, folder, and owner recorded
• Trigger type and poll interval (if any) written down
• Every app connection listed — including Formatter, Storage, and Sub-Zaps
• Irreversible steps flagged
• Sample payloads saved from three real runs (happy, empty, ugly)
• Destination ids you will use as idempotency keys identified
• Vendor webhook UI path documented with a screenshot in the runbook, not in Slack

Zapier’s account-data export is a compliance dump. Useful for history. Useless as an n8n load file. Team and Enterprise Zap-workflow export is the spec you actually rebuild from.

What do you migrate first — and what do you leave alone?

Order by blast radius and learning speed. You do not owe n8n the whole Zapier account on day one.

1. Internal notify / enrichment — low irreversible risk; proves credential naming and alerts.
2. Lead capture with an idempotency key — high value; this is where you practice dual-run.
3. Ops / invoice adjacent — only after a dead-letter path and an approval habit exist.
4. Leave alone: ancient Zaps that fire rarely and just work.

Keep on Zapier (for now)	Move to n8n first
Stable two-step Slack or email notify	High-volume or highly branched logic
Niche apps with no clean HTTP API	Paths that need self-host or custom code
Owner-absent legacy Zaps you will kill later	New builds that need a DLQ and approvals
Cheap Zaps whose rebuild is a week of founder time	Zaps whose task bill is the actual pain

A hybrid estate is fine if the runbook says which rail owns which event. The failure mode is “which system created this HubSpot contact?” Fix naming and source tags, not ideology.

Never flip three revenue Zaps in the same afternoon unless you like correlating incidents.

How do you dual-run without double-writing?

Dual-run means both rails see the event — or n8n shadows from a copy — while Zapier remains the system of record for side effects until parity is boring.

Pattern	How	Use when
Dual webhook fan-out	Vendor supports two endpoints, or a tiny proxy POSTs to both	Instant triggers; vendor UI allows a second URL
Zapier continues; n8n polls / reconciles	Schedule compares source → destination	Polling Zaps; vendor has one hook slot
Shadow mode	n8n runs log-only / dry-run; no CRM write	Writes are dangerous (money, email, deletes)
Shared idempotency key	Same source id claimed before either write	You will overlap during the flip window

Zapier’s Catch Hook gives you a unique hooks.zapier.com URL. Combining two Zapier Catch Hook suffixes is a Zapier-to-Zapier trick. It does not send a copy to n8n. For Zapier plus n8n you need a second vendor endpoint, a proxy, or a reconcile poll.

Rules for dual-run:

1. Idempotency keys shared or compatible so a flip does not double-create.
2. Compare counts daily — source created vs each rail processed.
3. Diff a sample of payloads at field level, not “it felt the same.”
4. Keep Zapier on until the comparison window passes without surprise.
5. Timebox the window. Commonly one to two business weeks for critical paths; longer if volume is low.

Dual-run metric	Pass	Fail (do not flip)
Event count / day	n8n within an agreed band of Zapier	Persistent miss or extra
Field diff on sample	Zero unexpected nulls / type changes	Phone, date, or id mangled
Error rate	Understood, owned, replayable	New 401 / 404 / silent Filter drop
Irreversible writes	Still Zapier-only, or keyed upserts	Two CRM rows for one source id

A week that usually works on a lead path:

Day	Zapier	n8n	What you compare
Mon–Tue	Live writes	Shadow / log-only	Payload shape, Filter vs IF counts
Wed–Thu	Live writes	Keyed upserts if shadow was clean	Source id collisions, field diffs
Fri	Live writes	Same	Error Workflow fired on a forced fail
Next Mon	Still live	Ready to flip	A full business week of volume, including one ugly payload

Skip dual-run only for workflows whose worst case is a missed Slack message. Lead intake is not that.

Stripe is the teaching case: live webhook retries run up to three days. If you swap the endpoint URL mid-window, retries go to wherever Stripe now has registered. During dual-run, add a second endpoint. Do not edit the live one until n8n has been boring.

How do you remap webhook URLs without a silent 404?

n8n generates two webhook URLs per Webhook node: a Test URL and a Production URL. The test listener stays up for 120 seconds after you click Listen. Point a vendor at the test URL and the integration dies when the editor session ends. That is the most common “n8n is broken” ticket on flip day.

URL	When it listens	Shown in editor?	Safe in a vendor UI?
n8n Test (/webhook-test/...)	Listen / Execute, ~120 seconds	Yes	Never for production
n8n Production (/webhook/...)	After you publish the workflow	No — use Executions	Yes, after publish
Zapier Catch Hook	While the Zap is on	Zap history	Yes, until you flip

Procedure:

1. Publish the n8n workflow. Copy the Production URL from the Webhook node.
2. curl that URL from your laptop with a fixture payload. Confirm a 2xx and an execution row.
3. If the vendor signs the body, verify the signature in n8n before any write — same habit as webhook security for automations.
4. Screenshot the vendor’s current Zapier URL into the runbook.
5. Add n8n as a second endpoint if the vendor allows it. If not, keep Zapier live and reconcile from a schedule until flip.
6. On flip: change the vendor URL or disable Zapier’s catch — one direction, written down.
7. curl again. Confirm the vendor delivery log matches n8n Executions.

Self-hosted gotcha: behind a reverse proxy, set N8N_WEBHOOK_URL to the public HTTPS origin. If you skip it, the editor shows http://localhost:5678/webhook/... and you will paste that into Typeform. The vendor cannot reach localhost. You will call it a cutover failure. It is a base-URL failure.

n8n’s common-issues table is the same split: test URL in the vendor, or debugging against the production URL and wondering why the canvas is empty.

How do you remap credentials without leaking secrets?

Bad migration hygiene is a zip of client secrets in a DM. n8n stores credentials separately from the graph and tests them on save. Importing an n8n JSON does not bring usable secrets with it. You remap every credential in the target environment.

Step	Do this	Do not do this
1	List every app connection the Zap uses	Assume “HubSpot” is one secret
2	Create n8n credentials with names (prod-hubspot, prod-slack)	Leave the default “HubSpot account”
3	Prefer service accounts / shared ops users	Personal OAuth for production writes
4	Hand off via a password manager	Screenshot refresh tokens into Slack
5	Record a rotation owner in the inventory	Store the owner in a founder’s head
6	Revoke Zapier access after the rollback window	Revoke on flip morning

OAuth redirect URLs change when the rail changes. n8n’s Google OAuth setup needs the n8n callback in the Google Cloud client — the path is /rest/oauth2-credential/callback on your n8n origin, not Zapier’s. A credential that “worked in Zapier” will 401 in n8n until that client is updated.

Self-hosted: every main and worker must share N8N_ENCRYPTION_KEY. Lose the key and the SQL dump is not a restore. It is a locked box.

If a credential only lives in one employee’s Google login, fix that before migration day. Migration will surface the bus factor whether you like it or not.

What is the cutover sequence for a critical path?

Write this as a release, not as a Friday experiment.

1. Freeze non-essential edits on the Zap.
2. Finalize the n8n workflow in a staging project with separate credentials.
3. Attach an Error Workflow that starts with an Error Trigger. Prove a deliberate failure with Stop And Error. Manual runs do not fire it.
4. Enable dual-run or shadow. Watch the metrics table above.
5. Flip: point the vendor webhook to n8n or turn on the n8n webhook and disable Zapier’s catch — one direction, documented.
6. Keep the Zap off but not deleted for the rollback window.
7. Only then archive or delete the Zap.
8. Update runbook URLs, credential inventory, and the “which rail owns this event” line.

Day	Zapier	n8n	Vendor webhook
Build	On, system of record	Staging, unpublished	Still Zapier
Dual-run	On, still writes	Published, shadow or keyed upsert	Both, or Zapier + n8n poll
Flip	Off, not deleted	Production writes	n8n Production URL
Rollback window	Ready to re-enable	Ready to unpublish	URL documented both ways
Burn the bridge	Archived	Sole owner	n8n only

n8n’s Error Trigger does not run on manual executions. If you “tested the alert” by clicking Execute, you tested nothing. Force an automatic failure before flip day.

What usually breaks on flip day?

These are the failures we see after 500+ automations. None of them are mysterious once you look.

Breakage	Symptom	Fix
Test URL in the vendor	Works in the editor, dies after 120s	Production URL + published workflow
Vendor still posts to Zapier	n8n silent; Zapier still creating rows	Vendor UI screenshot + curl verify
Credential remap	401 / empty nodes after “import”	Remap every credential; no chat-pasted secrets
OAuth redirect still Zapier’s	Connect button fails in n8n	New callback on the OAuth client
Paths / Formatter assumptions	Wrong branch, mangled phone or date	Explicit IF / Switch + DateTime / Code with fixtures
Filter vs IF mismatch	Silent drops	Log filtered counts in dual-run
Task-vs-execution thinking	Invoice surprise or missing steps	Re-count cost per successful lead
Hard-coded Zapier Storage	State missing after flip	Move state to a DB / Airtable / static data on purpose
N8N_WEBHOOK_URL unset	Localhost URL in the vendor	Set the public HTTPS origin

Zapier Paths are first-class branches with Custom / Always run / Fallback rules. n8n’s IF and Switch nodes do the same job with different fall-through. Rebuild the fallback as an explicit branch you log. A missing fallback in n8n is a silent drop, not a Zapier-style safety net.

Formatter steps do not count as Zapier tasks. In n8n they become DateTime, Set, or a small Code node — and they do run inside the execution. Unit-test the ugly phone and date cases on fixtures you saved in the inventory. Do not discover timezone drift on a live lead.

Built-in Zapier state does not travel. Inventory these before you call the rebuild “done”:

Zapier piece	What it held	n8n replacement you must choose
Storage by Zapier	Cross-run keys, counters	Postgres / Airtable / static data — pick one
Zapier Tables	Rows the Zap treated as a database	Same: a real table, not execution memory
Sub-Zap	Shared logic + extra task steps	Sub-workflow / Execute Workflow
Digest / Delay	Batching and waits	Wait node or a real queue
Zapier Manager	Pause / on-off from inside a Zap	You, plus workflow settings

If the Zap incremented a Storage key to dedupe, that key dies on flip unless you copy the current value into the new store. Dual-run with an empty store looks like “n8n is creating duplicates.” It is. You left the cursor behind.

How do you write a rollback you can actually execute?

Write this before flip day. Rollback that requires “rebuild the Zap from memory” is not rollback.

1. Signal: error rate, missing leads, or dual-run divergence past a written threshold.
2. Action: unpublish or deactivate the n8n workflow; re-enable the Zap; restore the vendor webhook URL to the Zapier Catch Hook.
3. Catch-up: replay from the source or the dead-letter path for the gap window.
4. Owner: named human with access to both rails and the vendor UI.
5. Comms: who tells sales or support the rail flipped back.

Rollback input	Where it lives	If missing
Zapier Catch Hook URL	Runbook + vendor screenshot	You cannot put traffic back
n8n Production URL	Runbook + Webhook node	You cannot prove the flip
Credential owners	Inventory	You cannot rotate on the way back
Gap replay method	Source list API or DLQ	You eat the missed events
Named flip owner	Calendar + runbook	Slack archaeology at 2am

Keep the Zap intact until you are willing to burn the bridge. Off is reversible. Deleted is a rebuild.

If the vendor only allows one webhook URL, the rollback action is a URL paste, not a toggle. Practice that paste in staging. Time it. Put the old URL on the first line of the runbook.

Catch-up is its own procedure. The flip window is where events go to the old URL, the new URL, or neither.

1. Note the flip timestamp in the runbook (timezone written out).
2. List source records created or updated in a window around that stamp — overlap one poll interval or the vendor’s retry window.
3. Upsert into the destination by the same idempotency key you used in dual-run.
4. If the vendor retries (Stripe’s three-day live window), expect late POSTs to whichever URL is registered now. That is why the key exists.
5. If you rolled back, run the same list against Zapier’s history so you do not double-create on the way back.

A rollback without catch-up just moves the gap to the other rail.

Why Zapier task math does not travel to n8n?

Zapier trains a mental model: trigger plus actions, one task per successful action step, Paths and Formatter as free logic. Zap limits cap a Zap at 100 steps including Paths. n8n bills and executes as a graph: one incoming event can be one execution with many nodes.

During migration:

1. Re-count “cost per successful lead” on n8n executions, not by pretending one Zapier task equals one n8n run.
2. Rebuild Paths as IF / Switch trees with explicit fall-through logging.
3. Replace Formatter chains with DateTime, Set, or small Code nodes — and test the ugly cases.
4. Do not assume Zapier’s built-in dedupe equals your idempotency key design.
5. Do not assume a Zapier Filter “did not run” looks like an n8n IF that sent zero items. Log both.

Zapier habit	n8n equivalent	Trap
Task = successful action	Execution = the graph ran	Empty success still costs an execution
Filter / Paths / Formatter free	Those nodes still run	“It was free on Zapier” is not a design
Catch Hook URL never changes	Test vs Production URLs	Test URL in the vendor
Storage by Zapier	You pick a store	State vanishes on flip
Replay a Zap run	Retry execution / DLQ replay	Different id, same business key needed

Teams that skip this step “finish migration” and then argue about invoices for a month.

Should you pick n8n Cloud or self-hosted before remapping webhooks?

Yes. Pick hosting before you remap fifty webhook URLs. Cutover complexity plus platform ops is a bad double.

For most migrations: n8n Cloud first unless residency or network placement already forced self-hosted. Cloud means you are not also debugging N8N_WEBHOOK_URL, TLS, and an encryption key on flip week. Self-hosted wins when VPC, fixed egress, or data residency already require it — that decision belongs in the comparison post and the hosting docs, not in the middle of a Catch Hook paste.

Hosting	Remap implication	Pick it when
n8n Cloud	Stable public webhook host; OAuth callbacks on n8n’s domain	You want one change at a time
Self-hosted	You own N8N_WEBHOOK_URL, TLS, and N8N_ENCRYPTION_KEY	Residency / VPC already decided
Mixing both during cutover	Two callback URLs, two secret stores	Almost never on purpose

Do not “try Cloud, then move to Docker next month” with live vendor URLs. Each move is another remap. One hosting decision, then the dual-run.

Does Make to n8n use the same playbook?

Yes. Inventory, rebuild, dual-run, remap webhooks and credentials, keep a documented rollback.

Make’s scenario blueprint is a JSON export for backup and sharing inside Make. Import it into another Make scenario. It is not an n8n import. Treat the blueprint as a spec the same way you treat a Zapier export.

Make artifact	Use it as	Do not
Blueprint .json	Module list, filters, routers	Paste into n8n Import from File
Webhook URL in Make	The thing you will remap	Assume n8n can “take over” the same URL
Connections	A credential inventory	Export secrets into the blueprint

Module names will not paste cleanly. Re-prove filters, routers, and error handlers. Make’s webhook can go 410 Gone if it sits detached — that is a Make-side silence, not an n8n bug. Same dual-run rules: counts, field diffs, Zap-equivalent left on until boring.

When should you stay on Zapier?

Stay when the rebuild cost wins. Tool pride is not an ROI strategy.

Stay when:

• The Zap is two or three steps, stable for months, and cheap on task math
• Nobody on the team will own n8n upgrades, backups, or Error Workflows
• The apps you need are Zapier-only and HTTP workarounds are worse
• Migration week would delay a revenue project that matters more than the subscription line
• The Zap is a rare-fire “just works” path whose worst case is already acceptable

A boring Zap that never wakes you beats a clever n8n canvas with no owner. Across 500+ automations, the graphs that survive are the ones someone will still answer for in six months.

If you are migrating to feel serious, stop. If you are migrating because the task bill, the hosting constraint, or the branching actually hurts — rebuild one path, dual-run it, and keep the rest on Zapier until the next path earns the same treatment.

Migration checklist

• Inventory complete with irreversible flags and sample payloads
• Decision documented against the comparison-post criteria
• Hosting chosen (Cloud vs self-hosted) before any vendor URL changes
• n8n staging project + named credentials ready
• Error Workflow attached; automatic failure proven
• Dual-run metrics defined (counts, field diffs, error rate)
• Webhook remap runbook (forward + rollback) with both URLs
• OAuth callbacks updated on the provider, not only inside n8n
• Credential inventory in a secret manager; rotation owners named
• Idempotency key agreed for the overlap window
• Rollback owner named and scheduled
• Zap retained (off) through the rollback window
• Source tag / “created by” field says which rail wrote the row

If a box is unchecked, you are not ready to flip. You are ready to keep dual-running.

FAQ

Is there an official Zapier to n8n importer?

No first-party path you should trust for production as of mid-2026. n8n imports n8n JSON and n8n packages; Zapier exports Zapier JSON. Rebuild from an inventory. Third-party converters exist in marketing posts — verify on a non-critical Zap before you believe them.

Should I move to n8n Cloud or self-hosted first?

Cloud first for most teams so cutover and platform ops do not land in the same week. Choose self-hosted when residency, VPC, or fixed egress already require it. Pick hosting before you remap vendor webhook URLs.

How long should dual-run last?

Long enough to see real volume and at least one weird week — often one to two business weeks for critical paths, longer if events are rare. End dual-run on counts and field diffs, not on calendar optimism alone.

What about Make to n8n?

Same cutover mechanics: rebuild, dual-run, remap, rollback. A Make blueprint is a spec for another Make scenario, not an n8n import. Re-test filters, routers, and error paths explicitly.

How do I remap OAuth without screenshots in Slack?

Create credentials in n8n using a password manager or secret manager handoff, prefer shared ops accounts, and record rotation owners. Update the provider’s redirect URI to n8n’s callback. Never paste refresh tokens into chat threads.

When should I stay on Zapier?

When the Zap is simple, cheap, and stable — or when nobody will own n8n operations. Migration is optional. Reliability and ownership are not.

CTA

Cut over like a release: dual-run, remap, flip, keep the parachute.

For rail choice read n8n vs Make vs Zapier; for the spine read the handbook. Ready for a migration plan — automation or book a $500 Automation Audit.