n8n + Zapier: A Migration Guide for Shopify Teams

Who this is for

n8n + Zapier decisions come up at a specific point: a Shopify Plus or subscription-platform brand doing $3M–$30M a year has outgrown a handful of simple Zaps, is paying for task volume it didn’t expect, and wants to know whether moving that automation to n8n is worth the engineering time. If you’re running fewer than a dozen Zaps and none of them touch more than a few hundred records a month, the migration cost in this article will exceed what you’re spending on Zapier; stay put instead. This is written for teams where automation already touches order flow, fulfilment, or customer data at a volume where the platform bill or the platform’s limits have become a real line item.

What n8n and Zapier are each built for

Zapier is built to get a non-developer from “I want X to trigger Y” to a working automation in minutes, hosted entirely on Zapier’s infrastructure, billed per completed action. n8n is a workflow engine you can run on Zapier’s cloud or on your own server, built for people comfortable editing JSON and reading API documentation, with a Code node for logic that Zapier would push into a separate paid step. The tools differ in their strengths: Zapier wins on time-to-first-automation and vendor-managed reliability; n8n wins on cost at volume, data ownership, and the ability to write arbitrary logic a point-and-click builder can’t express.

The practical dividing line is workflow complexity and execution volume, not company size. A five-person brand running a single high-volume, revenue-critical sync (say, order data into a warehouse system every few minutes) can justify n8n before a fifty-person brand running a handful of low-volume marketing Zaps ever needs to.

Prerequisites before you touch a single Zap

Before rebuilding anything, get four things in place:

• A place to run n8n. Self-hosted (your own VPS or container) or n8n Cloud. Self-hosting is what gives you unlimited executions and full data ownership; n8n Cloud trades that for a hosted setup closer to Zapier’s.
• Admin access to every app your Zaps touch. You’ll be re-authenticating Shopify, Klaviyo, Recharge, your helpdesk, and anything else — n8n credentials are separate from Zapier’s, even for the same app.
• A staging or test resource for anything that writes data — a test Shopify order, a test customer record — so running the new and old automation side by side doesn’t touch live customers.
• A list of who gets notified when something breaks. Zapier emails the Zap owner by default; n8n does not notify anyone unless you build an error workflow yourself — a required setting, covered next in this method.

Inventory every Zap you actually run

Open Zapier’s dashboard and list every active Zap, not just the ones you remember building. For each one, record: the trigger app and event, every action step in order, the monthly task count (Zapier’s Usage page shows this per Zap), and what breaks downstream if it stops running. A Zap that’s fired twice in the last quarter is a low-priority migration candidate regardless of how important it sounds; a Zap burning thousands of tasks a month on a five-step chain is a high-priority one even if nobody thinks about it day to day.

This inventory is also where you catch Zaps nobody remembers the purpose of. Turn those off before migrating anything — don’t carry dead automation into the new platform.

Rebuild the trigger first

Start each migration with the trigger alone, and confirm it fires correctly before adding a single action. Two trigger types cover most Shopify automation:

• Webhook-based triggers (new order, new customer, cart update): n8n’s Webhook node gives you a URL to register directly with Shopify, or n8n’s dedicated Shopify Trigger node, which subscribes to Shopify’s webhook topics using the same store credentials Zapier’s Shopify trigger asked for.
• Polling-based triggers (checking an app on a schedule because it has no webhook): n8n’s Schedule Trigger node replaces Zapier’s polling interval — set the interval explicitly; n8n doesn’t infer one from your plan tier the way Zapier does.

Test the trigger in isolation. Send a test order, watch it land in n8n’s execution log, and confirm the payload has the fields the next step needs before building anything downstream.

Rebuild each action, one node at a time

Rebuild the Zap’s action steps as n8n nodes in the same order, testing after each one rather than wiring the whole chain and debugging it as a block. Most common Zapier actions have a direct n8n equivalent (HTTP Request node for anything without a dedicated app node, plus dedicated nodes for Shopify, Klaviyo, Slack, Google Sheets, and most major SaaS tools). Where Zapier used a Filter step, n8n’s IF node does the same job; where Zapier used Paths for conditional branching, n8n’s Switch node covers it.

The step people skip: checking whether an app node in n8n actually supports the same API version and fields the Zap relied on. Some Zapier app integrations are more complete than their n8n equivalent, or vice versa — verify the specific fields you need exist in the n8n node before assuming parity, rather than after the workflow is live.

Add the error handling Zapier gave you for free

Error handling is the step most teams get wrong, and it’s the reason a migration that looked clean in testing produces a silent failure in production. Zapier emails the Zap owner automatically when a Zap errors out. A self-hosted n8n workflow does none of that unless you build it, and the default behaviour on failure is to stop and log an error nobody sees until they go looking.

Three settings, all in the workflow’s own configuration, close that gap:

• Error Workflow (Workflow Settings → Error Workflow): point every production workflow at a separate “on error” workflow that sends a Slack message or email with the failed execution’s ID. Without this set, a failed execution produces nothing but a log entry.
• Retry On Fail (on the individual node, typically HTTP Request or an app node calling an external API): turn it on, set Max Tries to 3 and Wait Between Tries to around 5000ms for most Shopify and app-API calls. Zapier’s built-in retry logic did this invisibly; on n8n it’s a setting you have to turn on yourself.
• Save Manual Executions and Save execution progress (Workflow Settings): keep both on for any workflow handling orders, refunds, or customer data, so a failed run leaves a record you can replay rather than one that vanishes.

A workflow with no Error Workflow attached and Retry On Fail left off will run correctly in testing and then fail invisibly in production the first time an app has a slow response or a brief outage — exactly the kind of failure Zapier’s defaults hid from you.

Run both in parallel before you cut over

Once the n8n workflow passes its own tests, don’t turn off the Zap yet. Leave the Zap live and running, disable or redirect the n8n workflow’s write actions to a test resource, and let both process the same live triggers for a defined window: long enough to see your normal volume pattern, not just a quiet day. Compare the outputs: same order data reaching the same destination, same fields populated, same timing. Where n8n produces a different result (a missing field, a different date format, a failed retry Zapier’s defaults would have absorbed), fix it before either platform runs alone.

The point of this step is that a broken Zapier-to-n8n migration doesn’t announce itself. It produces a smaller number of correct orders, or a slightly different field format a downstream system silently mishandles, and nobody notices until a customer or a report does.

Cut over and decommission the Zap

Once outputs have matched for the full parallel-run window, switch the n8n workflow’s write actions to live, turn the Zap off (don’t just pause it; paused Zaps still count toward task limits on some plans and are easy to reactivate), and remove any Shopify webhook subscription still pointed at Zapier’s URL. Watch n8n’s execution log closely for the first day of solo running, the same way you’d watch a newly deployed feature.

Keep the Zap’s configuration documented somewhere even after deleting it — if the n8n workflow needs to be rolled back under time pressure, you want the reference, not a rebuild from memory.

n8n vs Zapier: ownership, self-hosting and who holds the workflow

The ownership difference is the real reason teams migrate, more often than the cost difference. A Zap lives on Zapier’s infrastructure; if Zapier raises prices, changes a plan’s limits, or deprecates an app integration, you inherit that decision. A self-hosted n8n workflow lives on infrastructure you control: the workflow definitions, the execution history, and the server itself are yours, and they stay yours if you ever change automation vendors or agencies. Pointerflow builds and runs n8n automations on the client’s own VPS specifically for this reason — unlimited executions on that server, and the workflows are yours to keep if the engagement ends.

Self-hosting isn’t free of tradeoffs. You take on server maintenance, n8n version upgrades, and backup responsibility that a vendor-hosted platform absorbs for you. That tradeoff is worth making at the volume and criticality where ownership and cost matter more than convenience; not before.

n8n vs Zapier: pricing units, hedged

The two platforms don’t just charge different amounts; they charge for different things, and that’s what makes a direct dollar comparison misleading without checking current numbers yourself. Zapier’s published pricing bills per completed task, where each action step in a Zap counts as one task every time the Zap runs. n8n’s cloud pricing and self-hosted licence terms are structured around workflow executions rather than individual action steps, so a workflow with several action nodes that runs once counts differently than the same shape would under Zapier’s model. Make, if you’re weighing a third option, bills per operation under its own separate credit system.

None of those unit definitions are numbers worth repeating here, because platforms change plan structures and thresholds regularly enough that a figure quoted today can be wrong by the time you read it. Check n8n’s own pricing documentation and Zapier’s current pricing page directly before building a cost model, and build that model around your own actual task or execution count, taken from the Zap inventory described in the migration method, not a vendor’s example usage.

What breaks when you migrate

Four failure modes show up repeatedly in Zapier-to-n8n migrations, and all four are avoidable if you know to check for them:

• Silent failures from missing error handling: the most common cause of a migration that looks successful in testing and fails in production, because n8n doesn’t email anyone on failure unless you build that in yourself.
• Rate-limit errors on high-volume API calls: Zapier throttles requests to many apps automatically; n8n sends requests as fast as the workflow allows unless you add a Wait node or configure Retry On Fail with a meaningful wait between tries.
• Date and timezone formatting differences: Zapier’s Formatter step and n8n’s Code node or Date & Time node don’t handle formats identically by default; a field that looked fine in the parallel-run test can still drift on an edge case like a different timezone offset or a locale-specific date string.
• Duplicate webhook deliveries during cutover: if both the old Zapier webhook subscription and the new n8n one are registered against the same Shopify topic at the same time, Shopify sends the event to both, and you get duplicate orders, duplicate emails, or duplicate tickets until one is removed.

How to verify the migration worked

Verification isn’t a single check; confirm three things in order before calling a migrated workflow done. First, that the trigger fires reliably: watch n8n’s execution log across a normal volume day, not just a manual test. Second, that every field the old Zap populated downstream is still populated correctly: check the destination system directly, not just n8n’s execution output, since a field can look correct in n8n and still arrive malformed elsewhere. Third, that a deliberately failed execution (a bad test payload, a temporarily disabled API credential) actually produces the alert your Error Workflow is supposed to send. A migration without its failure path tested isn’t truly verified; it’s merely hoped for.

Moving Zaps to n8n is an agents-and-automation decision as much as a tooling one: the workflow now runs unattended against production data, on infrastructure you’re responsible for keeping correct. Pointerflow builds and runs these automations for Shopify, Klaviyo and Recharge on the client’s own VPS as part of our AI agents and automation work, including the error handling and parallel-run discipline this article describes — worth a look if a Zapier-to-n8n migration is more engineering time than your team has free right now, or if you’re weighing this alongside a broader Shopify Plus automation build.