Migrating from Zapier to n8n: Cost, Process, and What Breaks

1. The task-cost maths

The two platforms count different things. Zapier counts tasks: each successful action step uses one, while triggers and built-in tools like Filter, Formatter, and Paths do not. n8n Cloud counts executions: one run of a whole workflow is one execution, "regardless of how many steps are in the workflow or how much data it processes" (n8n pricing).

Current list prices: Zapier Professional is $19.99 a month billed annually ($29.99 monthly) for 750 tasks, $129 annually ($193.50 monthly) for 10,000 tasks, $189 ($283.50) for 20,000, and $489 ($733.50) for 100,000. Past your tier, pay-per-task billing keeps Zaps running at a higher per-task rate, or stops them if you have it switched off (Zapier pricing). n8n Cloud Starter is €20 a month for 2,500 executions and Pro is €50 for 10,000, both billed annually. Self-hosted Community Edition is free software; you pay for the server and the upkeep.

Two illustrations, using annual prices:

The payback formula is simple: migration cost ÷ (monthly Zapier bill − monthly n8n cost − monthly maintenance). Be honest about the last term. On self-hosted n8n somebody has to run updates, backups, and monitoring, and that time is the real cost; I break it down in what self-hosting n8n really costs. To run your own numbers across Zapier, Make, n8n Cloud, and self-hosted n8n, use the automation platform cost calculator.

Cost is not the only reason to move. Teams also migrate because a workflow needs real code, an AI agent in the middle, data that must stay on their own infrastructure, or proper error handling across dozens of automations. If those apply, the payback period matters less.

2. The migration checklist

1. Inventory every Zap. Name, owner, trigger, apps, steps, monthly task use, and the last time it ran. Zapier's usage page shows which Zaps drive the bill.
2. Sort into keep, merge, and kill. In most workspaces a share of Zaps are dead, duplicated, or doing half of what another Zap does. Kill those first; it costs nothing and lowers the bill immediately.
3. Rank by task use. The top few Zaps usually account for most of the tasks. Migrate those; leaving small Zaps on a lower Zapier tier is a valid end state.
4. Map apps to nodes. Most popular apps have n8n nodes. Where one does not, the HTTP Request node calls the API directly, which takes longer to build. Note these early; they drive the estimate.
5. Document what each Zap really does. Including the exceptions people fix by hand afterwards. The Zap shows the happy path; the team knows the rest.
6. Set up n8n properly. An instance your company owns, credentials under a service account, an error workflow, and workflows in version control. See making n8n workflows production-ready.
7. Rebuild, do not copy. Add a dedupe key, retries on flaky APIs, and a failure alert to every workflow.
8. Test in parallel, then cut over (section 4).
9. Downgrade Zapier at the renewal, not before every workflow has run cleanly for a full business cycle.

3. What breaks in translation

These are the places I see Zap-to-n8n rebuilds go wrong. None of them are hard once you know to look:

Two more that do not fit in a table. Task history does not move: keep the Zapier account readable for a while if anyone audits past runs. And the people who edited Zaps themselves may not be comfortable in n8n. Decide up front who owns changes after the migration, and write that down.

4. Testing and cutover

The goal of cutover is boring: no record processed twice, none skipped. This is the sequence I follow for each workflow:

1. Shadow run. Point the n8n workflow at the same trigger, but write to a test destination (a copy of the sheet, a sandbox CRM, a Slack test channel). Leave the Zap live.
2. Compare outputs for a few days or a full business cycle, including month-end if the workflow touches billing. Every difference is either a bug or an undocumented rule in the Zap.
3. Pick a cut point. A timestamp or record ID after which n8n owns processing, so the new trigger does not pick up records the Zap already handled.
4. Switch. Turn the Zap off, point n8n at the real destination, repoint any webhook URLs, and watch the first live runs.
5. Keep the Zap, turned off, for 30 days. If something is wrong, you can switch back in a minute.

Move one workflow family at a time. A problem in one is then a small problem, and the team builds confidence as each one lands.

5. What a migration costs with me

Pricing is on the pricing page. It starts with a free 30-minute audit call where we look at your Zapier usage together. For larger workspaces, an Automation Roadmap ($500 fixed, credited to the build) produces the inventory, the keep-merge-kill list, and the payback estimate before you commit. Migrations are fixed-scope builds from $2,500; most land between $3K and $8K, depending on how many Zaps are worth moving and how many apps lack an n8n node. They take two to four weeks including the parallel run, with a 30-day fix guarantee. After launch, care plans cover monitoring and fixes at $600 a month (Monitor) or $1,800 a month (Partner). If you already migrated and something is misbehaving, a workflow rescue is $400.

If the maths says stay on Zapier, I will say so. Trimming dead Zaps and moving to the right tier is sometimes the whole answer.

The takeaway

A Zapier-to-n8n migration pays off when a handful of long, high-volume Zaps drive the bill, or when you need what n8n does better: code, AI steps, self-hosting, and error handling across many workflows. Do the maths first, migrate the expensive Zaps, rebuild rather than copy, and cut over with a parallel run. Done that way, the only thing your team notices is the smaller invoice.

For help planning or running one, see my n8n automation service.

Frequently asked questions