Migrating from Zapier to n8n without downtime: in waves, running both, with a way back

Before you move a single Zap: the inventory that decides the order

Almost everyone looking up how to migrate from Zapier to n8n starts the same way: open n8n, build the first workflow. Wrong order. Building isn't first. Knowing what you have running, what calls what, and in which order you can switch something off without something else falling over behind it — that's first.

You've already decided. If you're still on «do I switch or not», that's settled in alternatives to Zapier for business and in n8n vs Make vs Zapier. This guide starts where those end: you know where you're going, now you have to get there without turning the lights off.

The inventory isn't a list of Zap names. It's a short sheet per flow, six facts and not one more:

• What triggers it. A webhook, a schedule or a change in an app. The webhook ones hurt most, and in a moment you'll see why.
• Which apps it touches, splitting what it reads from what it writes. What it writes is what scrambles a real system if both flows run at once.
• Who calls it from outside. A form, another vendor's dashboard, somebody's script. This is the column nobody fills in and the one that produces the scare.
• What happens if it's down for an hour. «It's important» doesn't count: what's lost and who notices.
• Which account it connects with for each app, and whose account that is.
• Who understands it, by name. If the answer is «nobody», that flow doesn't get migrated yet: first it gets decoded.

The first obstacle is a plan one. Zapier lets you export your Zaps to JSON from account settings, in the security and data section, but only on Team and Enterprise: on Free and Professional there's no button. If you're on Professional — where a lot of mid-sized companies live — the inventory is done by hand, Zap by Zap, and that afternoon goes into the estimate.

With the inventory in front of you, the order writes itself. You don't migrate from easy to hard: you migrate from reversible to irreversible. An internal notification can be migrated badly and fixed in ten minutes. A flow that issues an invoice or emails a customer doesn't accept «we'll fix it tomorrow».

In waves, not all at once: chunks you can undo

The most expensive mistake in a migration isn't technical, it's about size. Moving all forty flows over one weekend means that when something fails on Monday, you'll be debugging forty things at once. Migrating in waves isn't going slow: it's being able to point at the cause.

A wave is a group of flows migrated, watched and signed off together — and that can be handed back to Zapier together. Four usually do it:

1. Wave zero: the plumbing. No business flow at all. You stand up n8n, connect the credentials for the apps that show up everywhere, and build the error workflow. Skipping it means running the next three blind.
2. Wave one: the reversible stuff. Internal notifications, reports, syncs you can re-run. You learn the tool with the cost of being wrong near zero.
3. Wave two: the volume. The long, high-traffic flows — the ones that justified the migration in the first place.
4. Wave three: customers and money. Invoicing, contracts, emails that go outside, writes to the ERP. Last, with a long parallel run and somebody watching.

And a wave isn't over when the new flow works. It's over when four things are true: it's spent an agreed period producing the same result as the old one, its alerts are built and tested, someone who didn't build it can read it, and the original Zap is switched off but not deleted. Until all four hold, the next wave doesn't start.

What you don't copy: the thirty-step linear Zap gets redesigned

Here's the temptation that ruins migrations that were going fine: open the Zap, count its steps and reproduce the same thirty nodes one by one in n8n. You get a flow that works on day one and that nobody can maintain by month six: you've literally translated a structure that only existed because of a limitation in the tool you're leaving.

Zapier is a chain: one trigger and a row of steps. When you need two paths, the usual move is to split the process into several Zaps chained by an intermediate field. n8n is a canvas with branches, loops and sub-workflows, and that collection of Zaps held together with tape usually collapses into a single flow with two branches. That's the difference between being able to change something a year from now and not daring to touch it.

Careful, though — not everything gets redesigned. The two-step flow that does one thing and does it well gets copied over as is. The rule fits on one line: if it explains itself in one sentence, copy it; if you need a paragraph and an «except when», redesign it.

Automatic converters: a starting point, never a deliverable

Neither Zapier nor n8n offers an official bridge between the two platforms. What exists are third-party converters that read the exported JSON and hand back an approximate n8n workflow. They're useful and they take care of the mechanical part: field mapping, names, general shape. Use them.

Then treat them as what they are: a draft. A converter translates the structure, and the structure is exactly what you'd decided not to copy. It brings no credentials, it builds no error handling, and it can't see that those three Zaps are really one process. Shipping a converter's output is shipping the problem, translated.

Credentials and OAuth: this is where the real work is

Ask anyone who has done this migration what ate the hours and they won't say the logic: they'll say access. An export carries the structure of the flow, never the key to get into the apps. That's not a shortcoming of the converters: credentials live in the connection, not in the step.

Zapier's own documentation makes it plain even for the easiest case, importing Zaps into Zapier: afterwards you have to turn them on and test the app connections, reconnecting any that are no longer active. Between two different platforms, everything gets re-authenticated, one by one, by hand. Three traps turn that afternoon into a week:

• The personal account. Half a dozen connections are usually made with one specific person's account. The migration is your only cheap opportunity to move everything to service accounts; repeat the pattern and you've just moved the debt.
• OAuth permissions. Authorising a new application against Google Workspace, Microsoft 365 or Salesforce isn't always something the flow builder can do: in many companies an administrator approves it. That's not a click, it's a ticket with a lead time you don't control. Raise it in wave zero.
• Webhook URLs. A webhook-triggered Zap has a URL pasted into places you don't control. It changes when you migrate. If nobody updates the source, the new flow doesn't fail — it simply receives nothing.

Parallel running: both live until switching off is boring

Parallel running is the period where the old flow and the new one process the same thing at the same time and you compare their outputs before switching either off. It turns the cutover — the scary moment — into a formality: when you switch the Zap off you already know, with data in front of you, that the n8n flow does the same job.

There's one trap to solve before you start: if both write to the same place, you've just duplicated every order and every invoice. So the new flow runs in shadow mode: it reads from the real source and writes to a parallel destination. It only gets the real destination when the comparison stops producing surprises. And comparing isn't «looks fine to me». It's four things:

1. The count. Did the same cases enter both? If the new one processed fewer, you have a badly wired trigger or one filter too many.
2. The content, field by field, over a real sample. This is where date formats, decimals and the field that arrives empty because it was named differently show up.
3. The odd cases, deliberately. The order with no customer, the email with no subject, the zero amount. The happy path always matches; migrations break on the handful that doesn't fit.
4. The calendar. Let month-end or the invoicing cycle go by — whatever only happens on the first of the month.

How long parallel running lasts isn't measured in days: it's measured in cases seen. A flow that fires a thousand times a day exhausts its variety in a week. One that fires when a tender comes in waits for a tender to come in. Putting a fixed date on the cutover is the elegant way to cut too early.

Alerts and rollback: built before the cutover, not after

A migrated flow isn't finished when it works. It's finished when you'll find out it has stopped working and you can go back without improvising. Both get built before you switch anything off, because afterwards nobody builds them: the moment the new flow runs, attention leaves with the next wave.

In n8n that has a specific name. You create a separate workflow starting with the Error Trigger node and select it as the error workflow in the settings of every important flow. And watch out for a detail from n8n's own documentation that catches a lot of people: that error workflow can't be tested with a manual run, because the Error Trigger only fires when an automatic execution fails. Test it by causing a real failure, or you'll find out it never worked on the day you needed it.

That covers what fails loudly. What dies quietly — the flow that stopped receiving because nobody updated the webhook URL — no alert catches, because there's no error: there's nothing. Watching for absence is the other half of the job and it's covered in spotting broken automations.

The rollback plan is the cheapest thing to write and the one nobody writes. Per wave, three sentences: which Zap gets switched back on, which n8n flow gets switched off, and where the webhook URL has to be put back. If that can't be executed in five minutes without asking anyone, you don't have a plan: you have an intention.

When the last wave closes, what you have isn't «the same thing but in n8n»: it's new flows that from tomorrow have to be operated. That's where the work of keeping them alive and governing what they do begins. Setting up n8n so it holds up in a real company is in n8n for business; the full map is in the guide to automating with AI.