Workflow migration

Zapier to n8n migration: what it actually takes, by workflow type

There is no official importer, so every Zap gets rebuilt by hand. That means you budget per workflow rather than per seat, and the licence fee you stop paying reappears as server time plus a person who watches it.

Teams start pricing this migration for one of two reasons. Either the Zapier bill grew faster than the automation did, because per-task pricing charges for volume rather than value, or a compliance conversation raised the question of which third party is holding customer records in transit. Both are good reasons. Neither survives contact with a plan that assumes the workflows move themselves.

Nothing imports, so the unit of work is the workflow

n8n does not read Zapier's export format, and Zapier does not publish one designed to be read. What you can export is a description of the Zap, useful as a checklist and useless as an input. Every trigger, every filter, every field mapping and every credential gets recreated in the new canvas by a person looking at the old one.

That sounds worse than it is. Rebuilding forces a review, and most estates of any age carry three or four Zaps that nobody has looked at since the person who wrote them left. Migration is the cheapest moment you will ever get to delete those.

The planning bands we budget with

These are the ranges we scope against before touching a canvas. They assume one engineer who already knows n8n, and they exclude credential provisioning, which is usually blocked on somebody else's admin access.

An estate of 40 mixed workflows lands somewhere between two and four weeks of engineering, and the spread inside that range is almost entirely about connectors, not complexity.

The four things that break, every time

1. Authentication, once per service. Zapier holds the OAuth grant. Moving means re-consenting each connection, which needs an admin on every platform involved. On a 12-service estate this is the step that adds a week to a calendar even when the engineering is done.
2. Retry semantics you never configured. Zapier retries failures quietly and holds them for replay. Self-hosted n8n does what you tell it to do and nothing more, so retry, backoff and a dead-letter path become things you design rather than things you inherit.
3. Failure notification. A Zap that starts erroring sends you an email. An n8n workflow with no error workflow attached fails into the execution log where nobody is looking. This is the single most common way a migrated estate goes quiet without anyone noticing.
4. Webhook URLs other systems already call. Every inbound webhook has a new address. Anything pointing at the old one, including a form on a page nobody maintains, needs finding first and repointing second.

The cost moves, it does not disappear

The comparison people run is a monthly Zapier invoice against a monthly server invoice, and the server always wins that arithmetic because it is not the same list of items. A fair comparison adds the parts of the platform you were renting: upgrades, database backups you have tested restoring, TLS certificates, monitoring, and an answer to who gets paged when the queue stops moving at three in the morning.

Add those and self-hosting still wins for most teams past a few thousand tasks a month. It just stops being free. The honest framing for a finance conversation is that you are trading a variable per-task fee for a fixed infrastructure cost plus a few hours of engineering attention a month.

What we run, and what we moved off

Digiton runs its own operations on owned infrastructure with scheduled jobs rather than metered third-party automation, so this is a bill we pay in our own time rather than a position we sell. Two things we learned running it are worth passing on.

The first is that a visual canvas earns its place where a non-engineer needs to read the logic, and stops earning it when the logic is a script wearing 30 nodes. We moved a large share of our own recurring jobs to plain scheduled scripts for exactly that reason. The second is that silent failure is the real operational risk, not downtime. A weekly reporting workflow we run for a US email-marketing agency client failed quietly rather than loudly, and the fix was moving it somewhere that shouts. If you want the detail on why that happens, it is in why self-hosted n8n gets slower as you add workers.

A migration order that keeps you safe

1. Inventory every Zap with its task volume, then delete what nobody can name an owner for.
2. Stand up n8n, wire error handling and alerting first, before a single workflow is rebuilt.
3. Move the highest-volume, lowest-risk workflows first. They pay for the migration while the risky ones are still on Zapier.
4. Run both in parallel for two weeks on the workflows that touch money or customers, comparing outputs rather than trusting the new one.
5. Cut the webhook senders over last, and keep the Zapier plan alive one billing cycle past the final cutover.

When we tell people not to do it

If your total automation spend is under a few hundred a month and nobody on the team wants to own a server, the migration will cost more in attention than it returns in licence fees. The same applies when the driver is a single expensive Zap. Fix that one workflow instead. Data residency is a different argument and often a sufficient one on its own, which is the subject of GDPR-compliant retrieval and where builds break.

Digiton builds and operates automation for clients across 8 countries, from Lisbon. If you want a scoped number rather than a range, the fastest route is to send the workflow inventory.

Frequently asked questions

Related