On this page 11 sections
Nothing exports. Every Zap is rebuilt by hand, credentials are re-created from scratch, and the multi-step logic that Zapier expresses as a linear path often needs restructuring. Budget half a day to a day per non-trivial Zap. The things that break most are polling behaviour, built-in formatters, and the assumption that someone still has the vendor logins.
Migration is usually the right call above a certain volume. It is not a weekend, and treating it as one is how a business ends up with half its automations moved and no clear picture of which half.
Key takeaways
- There is no export or import path. Rebuilding is the migration.
- Zapier’s polling triggers hide latency behaviour you now have to choose explicitly.
- Built-in formatter steps have no direct equivalent and become expressions or code.
- Run both systems in parallel before cutting over, with the new one writing nowhere.
- The unmaintained Zaps you find during the audit are often the best outcome of the project.
Who this applies to
You are on Zapier, hitting task limits or per-task cost at volume, and considering n8n. Anywhere from a dozen to a couple of hundred Zaps.
If you have five Zaps and they work, stay. The migration cost will not be recovered.
Why people move
Three reasons, roughly in order of how often they are the real one.
Cost at volume. Zapier bills per task, and a task is roughly a step execution. Multi-step Zaps running at volume get expensive quickly. n8n Cloud bills per execution, and self-hosted has no per-run charge at all - see n8n vs Make for how the pricing shapes differ.
Data residency or reach. You need to keep payloads in your own infrastructure, or reach a system with no public endpoint. Zapier cannot do either. This is the one reason that is not negotiable - see self-hosted n8n.
Logic that Zapier resists. Loops over collections, real branching, transformations that need code. Zapier has added capability here, but a Zap that has grown fifteen steps with Paths and a Code step is usually easier to express as an n8n graph.
What actually breaks
Triggers, and the latency you were not choosing
Zapier’s polling triggers check on an interval tied to your plan. You inherited that behaviour rather than choosing it, and most people do not know their real trigger latency.
In n8n you choose explicitly: a webhook if the source supports one, or a schedule trigger with an interval you set. This is an improvement and it is also a decision you now have to make per workflow, and one that changes behaviour. A Zap that effectively ran every two minutes becomes a workflow that runs on the schedule you set, and if you set fifteen minutes to save resources, something downstream may notice.
Check which of your Zaps use instant triggers and which poll, before assuming a schedule is equivalent.
Formatter steps
Zapier’s Formatter - dates, text manipulation, number formatting, line-item handling - is used far more heavily than people remember. There is no single equivalent.
Most become n8n expressions; a few become Code nodes. Neither is hard, but each one is a small piece of work, and date-and-timezone formatters in particular are where behaviour quietly changes. Test those against real values rather than assuming.
Line items
Zapier’s line-item model is idiosyncratic. n8n’s model is items flowing through nodes, which is more consistent and does not map one-to-one.
Anything doing multi-line invoice or order processing needs rethinking rather than translating. This is where the “half a day per Zap” estimate goes wrong if you assumed a straight port.
Credentials
None of them transfer. Every connection is re-authorised.
The problem is rarely technical. It is that some connections were authorised years ago by someone who has left, against an account nobody can now access, and the migration is the moment you discover it. Audit which accounts your Zaps authenticate as before you start, not during.
Built-in error behaviour
Zapier auto-replays some failures and emails the owner. n8n does neither by default - see n8n error handling.
This is the most common regression in a migration: workflows move successfully, and the safety net does not come with them. Build the error workflow and dead-letter pattern as part of the migration, not after.
What it costs
| Zap complexity | Rebuild time |
|---|---|
| Two or three steps, standard apps | 1-2 hours |
| Multi-step with Paths and a formatter | Half a day |
| Line items, loops, custom code | A day or more |
| Anything nobody understands any more | Decide whether to rebuild it at all |
For thirty Zaps of mixed complexity, plan two to three weeks of part-time work including testing, not a sprint. Add the error-handling work, which is new rather than migrated.
The order that keeps the business running
- Audit first. List every Zap, when it last ran successfully, who owns it, and what breaks if it stops for a day. This step alone usually retires a fifth of them.
- Rank by blast radius, migrate the low-risk ones first. You want the first five rebuilt while the stakes are low, because that is where you learn how the two tools differ.
- Build in parallel with writes disabled. Rebuild in n8n pointed at the same triggers, but with the final write step disabled or routed to a test destination. Compare what each system would have done.
- Run both for a week on the workflows that matter. Compare counts. A discrepancy is nearly always a trigger-latency or filter difference, and finding it now is much cheaper.
- Cut over one workflow at a time, disabling the Zap rather than deleting it. Keep the Zapier account alive for a billing cycle after the last cutover.
- Then delete, once you have gone a full cycle - including whatever monthly process only runs on the 28th - without needing it.
The step people skip is four. It is the one that catches the migration’s real defects.
The audit is the valuable part
Most migrations of this kind find that a meaningful share of Zaps are dead: built for a campaign that ended, pointing at a tool nobody uses, or silently failing for months without anyone noticing because the output was never checked.
That is not a reason to feel bad about the Zapier bill. It is the most useful output of the project, and it is worth doing the audit even if you decide not to migrate.
While you are there, look for the Zaps that succeed while doing nothing - the ones where a filter stopped matching and every run reports success with zero records. Those are invisible on any dashboard. See why automations fail silently.
What we do, and when we advise against it
We run these migrations, and the first deliverable is always the audit rather than a rebuilt workflow. It is a fixed, small piece of work and it frequently changes the scope of everything after it - usually downward, because a third of the inventory turns out to be retired or unnecessary.
We also decline these. If a business has fifteen Zaps that work, no residency requirement, and a bill that is annoying rather than material, migrating is a project that spends real money to save less. The honest recommendation is to consolidate a few multi-step Zaps and stay, and we would rather say that on the first call than take a migration that will not pay back.
The opinion that is least popular: we will not migrate a Zap nobody can explain. If no one knows what a workflow is for or who depends on it, rebuilding it faithfully just relocates an unknown. The correct move is to turn it off and see who complains, which is uncomfortable and much cheaper than maintaining it forever.
When not to migrate
Low volume and no residency requirement. The cost does not come back.
Mid-quarter for anything financial. Do not move revenue-adjacent automation during a close.
Without somewhere for the workflows to run. Decide hosted or self-hosted first; that choice changes the plan.
When nobody will own n8n afterwards. Zapier is managed; n8n, especially self-hosted, is not. Moving to a tool with no owner is a downgrade dressed as a saving.
Frequently asked questions
Is there any automated migration tool?
No reliable one. The data models differ enough that a converter would produce workflows you would have to verify line by line, which is most of the work anyway.
How long for thirty Zaps?
Two to three weeks part-time including testing and parallel running. Faster if many are simple, slower if line items are involved.
Will it definitely be cheaper?
At volume, usually - especially self-hosted. Include infrastructure and the operational time in the comparison, not just the licence. At low volume it often is not.
Can we run both permanently?
Yes, and some businesses should - keep the handful of Zaps that use connectors n8n lacks, move the volume. Partial migration is a legitimate outcome, not a failure.
What is the single most common regression?
Losing the error notification. Zapier tells you when a Zap breaks; n8n does not unless you build it.
Next step
If you want the audit before committing to anything, that is the right first step and it is small. The n8n and Make engagement starts there - including the version where the recommendation is to stay where you are.
And if you have not settled on the destination yet, the three side by side are in Zapier, Make or n8n.
Related: n8n vs Make · n8n error handling · Why automations fail silently · Business process automation