The Zapier to n8n migration stalls at the audit, not the build.

Our verdict: migrate only if your Zapier bill is being driven by task volume rather than workflow count, and only if someone on your side can own a self-hosted or cloud n8n instance after handover. Otherwise stay on Zapier. That is a narrower recommendation than most migration guides give, and we make it deliberately.

Here is the reasoning, because a verdict without one is just an opinion:

• The cost case is real, but only above a threshold. Zapier bills per task, so a workflow with fifteen steps costs roughly fifteen times a workflow with one. n8n bills per workflow execution, so step count is close to free. Teams running high-step, high-volume automations see the gap widen fast. Teams running twenty simple two-step Zaps will not notice it at all. We covered the underlying billing math in execution-based vs task-based automation pricing.
• The capability case is stronger than the cost case. The teams who are happiest after migrating did not move to save money. They moved because they hit something Zapier would not let them do: custom code in the middle of a flow, a self-hosted instance for data that cannot leave their infrastructure, branching logic that got ugly in Paths, or an AI step they wanted to control properly.
• The ownership case is the one that kills migrations. n8n hands you more control and hands you the maintenance with it. If nobody on your team wants to own that, you have not saved money. You have moved a subscription cost into a people cost and made it invisible.

None of that is the reason migrations fail, though. Migrations fail earlier and more mundanely: the team opens n8n before it has any idea what it is actually migrating. That is the whole subject of the next section, and it is the single highest-leverage thing in this guide.

Export your Zap list and capture these for every single one, including the ones you are sure are dead:

1. What it actually does, written in one plain sentence a non-technical colleague would understand. If you cannot write that sentence, you do not understand the Zap well enough to rebuild it.
2. Trigger and run frequency. Instant, scheduled, or manual, and roughly how often it fires. This is what tells you whether it is alive.
3. Task consumption. Zapier reports task usage per Zap. This is the column that identifies your expensive workflows, and those are the ones worth migrating first.
4. Every app and account it touches. Not just the app, the specific account, because reauthorising connections in n8n is the tedious part nobody budgets for.
5. Business owner. A named person who cares if it stops. Any Zap with no owner is a candidate for deletion, not migration.
6. Dependencies. Does anything downstream read what this Zap writes? Sheets, CRM fields, and Slack channels are the usual culprits.
7. Keep, kill, or merge. The decision column, filled in last, once you can see the whole list.

That last column is where the value is. Every migration we have been close to has produced the same surprise: a meaningful share of Zaps get killed rather than rebuilt, because seeing all of them in one table makes the redundancy obvious for the first time. Several near-identical Zaps built by different people usually collapse into one better workflow.

This is also the moment to be honest about what you are really buying. Rebuilding your automations somewhere cheaper does not fix automations that were badly designed in the first place. If your processes upstream are messy, migrating them just relocates the mess. That is the argument for fixing the Foundation before the plumbing.

Two rows deserve emphasis. Credentials are where migration timelines slip, because reauthorising thirty connections across accounts you may not control is slow, boring work that cannot be parallelised or automated. Error handling is where migrations get embarrassing, because Zapier's failure emails have quietly been your monitoring system for years, and n8n gives you nothing until you build it.

The formatter row is the subtle one. Zapier's Formatter steps encode a lot of small decisions about dates, currencies, and text casing that nobody wrote down. Rebuilding them from memory is how outputs drift, and it is exactly what step four in the sequence above is designed to catch.