Zapier / Make to n8n

Zapier to n8n migration without breaking what already works

A Zapier to n8n migration moves the automations a company runs on Zapier (or Make) onto n8n, an open-source workflow platform that can run on infrastructure you control, without interrupting the processes that depend on them. It is for companies whose Zapier bill grew with task volume, who hit limits such as no code steps, no loops or data residency rules, or who have a hundred zaps nobody documented. I am an independent AI systems engineer and Sr DevOps Engineer with ten years of production infrastructure, and I run n8n in my own operation every day. The method is the same every time: inventory every zap, classify by criticality, map each to an n8n equivalent, rebuild in batches, run both platforms in parallel, then cut over with a rollback plan. A single fixed price agreed after a discovery call, a 60-day operational guarantee, and 100% ownership of the workflows on your side.

When does migrating from Zapier to n8n make sense, and when does it not?

Migrating is worth it when one of four things is true. The bill scales with task volume and each new automation now costs more than it saves. You need something Zapier cannot do cleanly: a real code step, a loop over hundreds of records, a multi-branch decision with error paths, or a workflow that must run inside your own cloud for data residency or client contracts. You have more zaps than anyone can explain, built by three people over four years, and nobody knows which ones are load-bearing. Or you want AI steps and agents over your own documents, on infrastructure you own rather than a per-task connector.

Migrating is not worth it when you run a handful of simple zaps: a form to a spreadsheet, a new deal to a Slack message, a calendar event to an email. Zapier is excellent at that, the cost is negligible, and a migration would be an engineering project with no payoff. I say this on the first call when it applies. The same goes for a company with nobody to own the n8n instance: self-hosting means someone is responsible for upgrades and backups, and if that someone does not exist, n8n Cloud or staying put is the honest recommendation.

Migrate: the bill grows with volume, you need code, loops, branching or data residency, or you have 100+ undocumented zaps
Migrate: you want LLM steps and agents on infrastructure you control
Stay: fewer than a dozen simple zaps and a bill you do not notice
Partial: keep the trivial zaps in Zapier, move the heavy and the sensitive ones

What is the method for a Zapier to n8n migration?

Every migration follows the same six steps, because the risk is never in building the n8n workflow. It is in forgetting a zap that quietly moved money, or cutting over on a Friday with no way back. First, inventory: export every zap and Make scenario, including the paused ones, with trigger, apps, actions, owner, last run and monthly task count. Second, classify: each automation is tagged critical (touches revenue, customers or invoicing), important (internal operations) or disposable (nobody has needed it in six months). Roughly a third of the inventory usually lands in the last bucket and is deleted, not migrated.

Third, map: each surviving zap gets a written n8n equivalent, node by node, with the pieces that do not translate 1:1 called out. Fourth, rebuild in batches, low stakes first, so the team learns the platform before the critical flows move. Fifth, parallel run: for critical automations both platforms run at the same time for one to two weeks, n8n in shadow mode writing to a log instead of the live system, and the outputs are compared record by record. Sixth, cut over one batch at a time with the Zapier zap paused but not deleted, so rollback is a single click for 30 days.

Which Zapier and Make features do not map 1:1 to n8n?

Most zaps translate directly: a trigger node, a few app nodes, done. The work is in the pieces that do not. Zapier Paths become n8n IF and Switch nodes, more flexible but the branch logic has to be written down instead of clicked. Formatter steps (date math, text splitting, lookup tables) become n8n expressions, or a small Code node in JavaScript or Python when the formatter chain was five steps long. Zapier Tables and Storage become a real database, usually Postgres, which is a gain in power and a change in how the team looks at the data.

Sub-zaps become sub-workflows through the Execute Workflow node, a better model that needs a naming convention. Delays deserve care: Zapier holds the state of a Delay for you, while the n8n Wait node holds it in the database, so an instance with many long waits needs the database sized for it. Make iterators and aggregators map closely to Split Out and Aggregate; Make routers map to Switch; Make error handlers become n8n error workflows plus per-node retries. Webhook URLs change on both moves, so every external system posting to a Zapier catch hook has to be repointed, and that list is part of the inventory.

Self-hosted n8n or n8n Cloud: how does the cost math work?

I will not quote prices here because Zapier, Make and n8n all change their pricing, and any number on this page would be wrong within a year. Check current pricing on each vendor site. What does not change is the structure, and the structure decides the math. Zapier bills per task: every action in every zap counts, so a six-step zap that runs a thousand times a month is six thousand tasks. Make bills per operation with a similar shape. n8n Cloud bills per workflow execution: one run counts once regardless of how many nodes it has, so multi-step workflows are far cheaper at volume. Self-hosted n8n bills nothing per execution; you pay for the compute, usually a small server plus a managed Postgres, and the marginal cost of one more workflow is zero.

The honest way to decide: take the inventory, multiply the monthly runs of each zap by its step count, and you have your Zapier task volume. Compare it against the same runs counted once for n8n Cloud, and against a fixed monthly compute bill for self-hosted, plus the cost of someone owning that instance. For a company with a few simple zaps the answer is to stay. Past a few thousand multi-step executions a month the answer is usually self-hosted, with n8n Cloud as the middle ground when there is nobody to own the infrastructure. I set up either one properly, and I say which one fits after seeing the inventory, not before.

What does a real Zapier to n8n migration look like?

A representative migration, described in plain words. The company runs around 120 zaps built over four years; sales, ops and finance each built their own. The bill has tripled, three zaps fail every week in ways nobody understands, and leadership wants AI drafting quotes, which does not fit inside Zapier.

Week one: the inventory lands as a spreadsheet with 120 rows. 41 are paused or dead and are deleted after the owners sign off; 58 are important and 21 critical (they touch the CRM pipeline, invoicing and customer email). Self-hosted n8n is deployed in the company cloud account with a private network, managed Postgres, secrets manager, nightly backups, uptime alerts and workflows exported to git on every change. Week two: the 58 important zaps are rebuilt in batches of ten, formatter chains become expressions, three sub-zaps become sub-workflows, the website catch hooks are repointed, and the team gets a Loom video per batch. Week three: the 21 critical zaps run in shadow mode for ten days, writing to a comparison table instead of the CRM. Mismatches are fixed; two turn out to be bugs the Zapier version had all along. Cutover happens per batch on a Tuesday morning with the Zapier zaps paused, and the Zapier plan is downgraded after the 30-day rollback window.

Trigger: webhooks from forms and CRM events, plus schedules for reports
Data: managed Postgres in the client cloud, backed up nightly
Model: an LLM node only where a zap needs judgment, with the API key in the client account
Guardrails: error workflow with alerts, retries on every external call, versioned workflows in git
Human approval: quotes and customer emails wait in a queue until someone clicks send
Where it runs and who owns it: the client cloud account, private network, their secret manager, their repository

What does it cost to hire me for a migration?

I do not bill hourly for migrations. After a free discovery call where we look at the zap inventory (or build it together if it does not exist), you get a written proposal with a closed scope, a timeline and a single fixed price. Most migrations run as a three-week sprint; larger inventories with many critical flows take three to five weeks. For reference, the productized systems published on this site with list prices run from USD 4,000 to 6,800 fixed, with an optional monthly for operations; a migration is quoted as a custom scope, but those are the reference points for a build of this size. Hosting, database and any n8n Cloud subscription are billed to you directly, in your name, with a cap declared in the proposal.

The 60-day operational guarantee applies: if a migrated workflow breaks in the 60 days after handoff, I fix it at no cost. Optional monthly support after that covers upgrades, new workflows and the AI layer. I bring in a second engineer for large inventories; either way you work directly with the engineer who builds.

What do you own after the migration?

Everything. The n8n instance runs in your cloud account or your n8n Cloud workspace, billed in your name. Every workflow is exported as JSON to a git repository you control, with a commit per change, so the instance is disposable and the automation is not. Credentials live in your secret manager, the database is yours, and prompts are versioned in the same repository. The handoff includes documentation per workflow, an architecture overview and Loom walkthrough videos, so the system survives the hit-by-a-bus problem, including me being the bus.

There is no lock-in on my side. I am not an n8n certified partner and I do not resell tools, so nothing routes through my accounts. If you later hire someone else or bring it in-house, they start from a documented, versioned system.

What AI becomes possible once you are on n8n?

For many companies the reason to migrate is not the bill; it is that n8n can do things Zapier cannot. Once the workflows are on n8n, adding an LLM step is one node: classify an inbound email, extract fields from an invoice PDF, draft a reply in your tone, summarize a call transcript. Adding an agent is a workflow that can call tools (look up the customer, check inventory, create a draft quote) and decide what to do next, with a human approval step before anything is sent or invoiced. Adding retrieval means Postgres with pgvector holding your documents, so the model answers from your material and not from the internet.

In my own operation this looks like a call-to-proposal pipeline: the meeting is transcribed, an LLM drafts the proposal, and n8n queues it for my approval; it never sends on its own. The same pattern applies to quoting, support triage, lead qualification and document processing, with Claude, OpenAI or Gemini behind it and the API keys in your account, built with the same guardrails as the migration: retries, logging, versioned prompts, and a person in front of anything irreversible.

Frequently asked questions

Can you migrate from Make to n8n as well?

Yes. The method is identical: inventory, classify, map, rebuild, parallel run, cut over. Make scenarios map more closely to n8n than Zapier does, since iterators, aggregators and routers have direct equivalents, so a Make to n8n migration is usually faster per scenario. Error handlers and data stores are the pieces that need the most attention.

How long does a Zapier to n8n migration take?

Most run as a three-week sprint. Inventories with many critical flows, or with many external webhooks to repoint, take three to five weeks, mostly because the parallel run for critical automations needs a window of real traffic before cutover. The timeline is in the proposal and does not move once agreed.

Do we have to turn Zapier off on day one?

No, and you should not. Zaps are paused, not deleted, as each batch cuts over, and the Zapier plan stays active through the rollback window. You downgrade or cancel it once the last batch has run cleanly on n8n for 30 days.

Should we migrate every zap?

No. About a third of most inventories is dead and gets deleted. Of the rest, trivial zaps with negligible cost can stay in Zapier if you prefer; I have no interest in migrating for the sake of it. If your whole inventory is a dozen simple zaps, I will tell you on the discovery call that you do not need a migration, or me.

Are you an n8n certified partner?

No. I am an independent senior engineer who uses n8n daily in my own operation and deploys it for clients, self-hosted and cloud. Not being a partner means I have no incentive to steer you toward n8n Cloud, or toward n8n at all, when something else fits better.

Can our team maintain n8n after the migration?

Yes, that is the goal of the handoff. Each workflow is documented, exported to your repository and walked through on video. For self-hosted instances I leave a written upgrade and backup procedure. If nobody in the company wants to own the instance, n8n Cloud or the optional monthly support are the two ways to cover it.

Do you work with companies outside Chile?

Yes. I work remotely from Chile with companies in the US, Canada and Europe, in English or Spanish, with full overlap with US business hours. Migrations are done entirely remotely, inside your own accounts, and the parallel run and cutover are scheduled around your working hours.

Send me your zap count and I will tell you in 15 minutes whether migrating is worth it.

A free call. I'll tell you straight which processes today's AI can solve and what your infrastructure needs for them to actually run. If it fits, we move forward. If not, I point you the right way, free.