How to migrate from Zapier to Make or n8n

I migrated 47 Zaps last year. Took me three weeks, about 40 hours of actual work, and I broke two production workflows along the way. One was a Stripe webhook that silently stopped firing for 36 hours before anyone noticed. The other was a date format mismatch that sent welcome emails at 3am instead of 9am.

I've been building automations for clients since Integromat was still called Integromat. Make scenarios for e-commerce shops, n8n workflows for SaaS companies, more Zapier Zaps than I can count. The migration from Zapier to something cheaper is one of my most common client requests.

Also the most underestimated.

Here's what I learned: the rebuild isn't hard. The gotchas are.

Audit what you have

Before I touch anything on a client migration, I need the full Zap list. This is where the first surprise hits.

Zapier only lets Team and Enterprise accounts export Zaps. If the client is on a Free or Professional plan, the "Download my Zaps" button in Settings is unavailable. Zapier's own help article title says it plainly: "Import and export Zaps in your Team or Enterprise account.

For individual accounts, the only way to get Zap definitions out is a GDPR data subject access request. You email Zapier support asking for a copy of all your personal data under GDPR Article 15. They send back a JSON file containing your complete Zap configurations: every node, every parameter, every connection mapping. The format includes internal IDs and raw node structures rather than clean importable JSON, but it's enough to audit what you have and plan the rebuild.

The catch: GDPR requests can take up to 30 days. Start it before you do anything else.

Once you have the export, open it and sort by three things.

Volume. Which Zaps fire the most? A Zap that runs 50 times a day eats 1,500 tasks a month (assuming one billable action per run). Most real Zaps have 3 to 8 action steps, so that 50-run Zap with 6 actions burns through 9,000 tasks monthly, which is where most of your Zapier bill actually hides. I find these first.

That's where the savings hide.

Complexity. I count the steps in each Zap. My rules: a 3-step Zap rebuilds in 30 to 60 minutes, while a multi-path Zap with filters, code steps, and conditional branches takes 2 to 4 hours. I tag each one as simple, medium, or complex.

Dependency. Some Zaps feed other Zaps. A webhook on Zap A triggers Zap B, which posts to Slack and updates a sheet that Zap C monitors. Kill Zap A first: the whole chain breaks.

Map the dependencies before touching anything.

I keep a spreadsheet with four columns: Zap name, monthly runs, step count, and dependency group. That spreadsheet becomes my migration checklist.

My approach: pick the highest-cost, lowest-complexity Zaps first. Quick wins that immediately reduce your Zapier bill while you learn the quirks of the new platform.

Map the concepts

The terminology changes between platforms. Here's what I tell clients: the concepts are the same, the names are different, and the billing model is where the real difference hides.

Zapier to n8n:

Zapier to Make:

The billing difference matters more than anything else on these tables. Here's the core distinction: Zapier counts each action step as a task, n8n counts the entire workflow run as one execution, and Make counts each module as an operation but starts you at 10,000 on the Core plan ($10.59 per month) versus Zapier's 750 tasks on Professional ($19.99 per month).

I put it this way: a 6-step workflow running 1,000 times per month costs 6,000 tasks on Zapier, 6,000 operations on Make, 1,000 executions on n8n.

Same work. Different math.

Rebuild and test

I start with a single workflow. Never migrate everything at once.

Step 1: Recreate the trigger. Here's the thing people forget: if the Zap uses a webhook trigger, your new workflow gets a new URL. Write that URL down immediately. Every external system pointing to the old Zapier webhook URL needs updating later.

Step 2: Add each action as a node (n8n) or module (Make). I connect them in the same order as the Zap. Popular apps have native nodes on both platforms: Slack, Google Sheets, HubSpot, Stripe, Notion. For apps without a native node: use the HTTP Request node and call the API directly.

Step 3: Map the data fields. This is where my time actually goes. Zapier auto-maps field names between steps, which means you never think about data structure until it breaks. n8n and Make require explicit mapping for each field using expressions or drag-and-drop. In n8n, I reference previous node output with expressions like {{ $json.email }}. In Make, I click the field and select from a structured data panel.

Step 4: Handle data format differences. Zapier's Formatter does quiet work behind the scenes: parsing dates, trimming whitespace, converting types. In n8n, I handle this in Set nodes or Code nodes. In Make, built-in functions cover most cases.

My rule: test with real data, not sample data.

I learned this the hard way with that 3am email incident.

Step 5: Run in parallel. Keep both the Zapier Zap and the new workflow active for 7 to 14 days. Point your webhooks to both systems simultaneously (most webhook senders accept multiple URLs, or use a simple forking proxy). Compare outputs. Only kill the Zap after the new workflow matches it exactly.

A full migration of 20 to 50 workflows: 2 to 4 weeks with a few hours per day.

The gotchas nobody warns about

I've done enough of these migrations to have a list. Here's what I tell every client before we start.

You might not be able to export your Zaps. Zapier's Zap export only works on Team and Enterprise plans. If you're on Free or Professional, there is no download button. Your option is a GDPR data subject access request, which can take up to 30 days. The GDPR export includes full Zap definitions with node configs and parameters, but the format differs from the native Team export. Budget this delay before you start the migration clock.

Webhook URLs are not portable. Every Zapier webhook URL dies when the Zap gets deleted. Every form, payment processor, CRM, and third-party service that posts to those URLs needs manual updating. For a business with 30 webhook-triggered Zaps: that means editing settings in 30 different tools.

Miss one, and data stops flowing silently.

No error. No alert. Just silence.

Premium app gaps. Zapier connects to 8,000 apps. n8n: about 400 natively (plus 2,000 community nodes). Make: around 2,000. I always check the availability of native integration before committing to your migration target. The HTTP Request node serves as a fallback, but the trade-off is real: reading the API docs and building the connection from scratch. I budget an extra hour per custom API connection.

Error handling works differently. Zapier retries failed steps automatically and sends an email when something breaks. n8n gives me an Error Trigger node: I catch failures and build custom error workflows (send to Slack, log to a sheet, retry with different parameters). Make has an error handler module that I attach to any scenario.

Both platforms offer more power than Zapier's approach.

Both require setup.

Skip the error handling config, and failures disappear into the void.

Execution counting surprises on Make. Make count operations, not executions. A router that splits into three branches, each with two modules, consumes 7 operations per run (1 trigger + 6 action modules). That's closer to Zapier's task math than most people expect. Still cheaper at scale: Make's base allotment (10,000 operations) is 13 times Zapier's (750 tasks). But don't assume Make bills "per workflow" like n8n.

It doesn't.

Date and timezone handling. Zapier normalizes dates and time zones behind the scenes. n8n and Make expose the raw data from each API. If your source sends UTC and the destination expects Eastern, handle the conversion explicitly. This is the single most common cause of "it worked in testing but broke in production" that I see, and it will bite your migration if you skip it.

Honest math on whether it's worth it

Here's the cost comparison I show my clients. We've run these numbers across dozens of migrations at this point.

A business on Zapier's Team plan, paying $separate walkthrough of that setup process9 per month, can drop to Make at $10.59 or n8n Cloud at roughly $24. Self-hosted n8n on a $5 VPS is the cheapest option, but it means managing a server: backups, updates, and SSL. I wrote a full walkthrough of that setup process separately.

The migration itself costs time. My estimates: 30 to 60 minutes per simple workflow, 2 to 4 hours per complex one. For a business with 30 Zaps, that's roughly 40 to 60 hours of total work over 2 to 4 weeks.

At $50 per hour for a freelancer: $2,000 to $3,000 as a one-time cost.

But here's the math that matters: if your Zapier bill runs $200 per month and n8n would cost $24, the migration pays for itself in 5 to 7 months. If the Zapier bill runs $500 per month, the payback period drops to under 2 months. We've seen this pattern repeat across every migration we've tracked.

I've done this enough times to know the truth: the migration is tedious but not technically hard. The risk isn't rebuilding your workflows. The risk is the stuff that gets forgotten: webhooks, error handling, timezone logic.

All of it fails silently after cutover.

Go slow. Run in parallel. Don't cancel Zapier until every workflow has run clean for at least a week.

The savings are real. The work is real, too.

Cost and pricing data verified March 2026 from official Zapier, Make, and n8n pricing pages.
Crux helps businesses find the right automation platform for their specific problem. We don't sell automation tools. We help you pick the right one.