How to migrate from Zapier to n8n

Moving from Zapier to n8n is a rebuild, not an import. There is no converter between the two, so the work is deciding what to carry across, rebuilding it well, and switching over without losing a run. This guide covers the order we do it in when we migrate a team, and the places it usually goes wrong.

Why teams move from Zapier to n8n

Three reasons come up again and again.

• Cost that tracks volume. Zapier bills by task, so a workflow that loops over a thousand rows costs a thousand tasks. A self-hosted n8n instance costs the machine it runs on and its operation, with no fee per task.
• Where the data goes. Every Zap sends its payload through Zapier’s infrastructure. n8n runs inside your network or in a region you choose, next to the systems it talks to. Internal databases and APIs never need to be exposed to the internet to be automated.
• Logic that outgrew the editor. Paths, Formatter steps and Code by Zapier stacked five deep are hard to read and harder to test. n8n handles branching, loops, sub-workflows and code as ordinary nodes on one canvas.

What you give up is the size of Zapier’s connector catalogue and the fact that someone else runs the platform. The first is usually covered by the HTTP Request node. The second is the part Pilae takes on.

Step 1: export your Zaps and Zap history

Take two exports before you change anything.

1. The Zaps themselves. In Zapier, open Settings, then Security and data, and use Download my Zaps under Data management. On Team and Enterprise accounts you receive a zip file by email containing one JSON file of the account’s Zaps. The account owner or a super admin gets every Zap; other members get only the ones they own.
2. The run history. Export Zap history as CSV for at least the last ninety days. This is the file that tells you what actually runs, how often, and which Zaps fail.

Keep both. The JSON is the specification you rebuild from: every trigger, action, filter and field mapping is in it. The history is how you decide what not to rebuild.

Step 2: build an inventory of what actually runs

Most Zapier accounts carry a long tail of Zaps that are switched on and never fire, or fire and do nothing useful. Sort the history by Zap and by task count, then put every Zap in one of three groups.

• Rebuild. Ran in the last ninety days and someone depends on it.
• Merge. Several Zaps doing variations of one job. In n8n these usually become one workflow with a Switch node.
• Retire. Nothing ran, or nobody can say what it is for. Let it expire with the subscription.

For each Zap you keep, write down four things: the trigger, the apps it touches, the account that owns each connection, and any system that calls it by webhook. Also flag the monthly, quarterly and yearly jobs. They are the ones a two-week parallel run will miss.

Step 3: map Zapier concepts to n8n nodes

The vocabulary differs more than the ideas do.

Items, not single records

The one difference that changes how you design is the data model. A Zap processes one record per run. An n8n node receives a list of items and runs once per item by default. A Zap that needed Looping by Zapier to handle a list is usually a straight line in n8n. The reverse also applies: a node that returns fifty rows will make every node after it run fifty times, which is what you want for writing rows and not what you want for sending one summary email. Use the Aggregate node when you need one output from many items.

Expressions replace most Formatter steps

Date formatting, text splitting and number conversion are Formatter steps in Zapier. In n8n they are usually a one-line expression in the field itself, written in JavaScript between double curly braces. Fewer steps means fewer places for a mapping to break.

Step 4: rebuild and test each workflow

Rebuild in order of risk, starting with a Zap that matters but would not hurt anyone if it misfired for an hour.

1. Recreate the trigger and fire it once with real data. n8n keeps the output so you can build the rest of the workflow against it.
2. Pin the test data. Pinning a node’s output lets you rerun the downstream steps without firing the trigger again or writing to a live system.
3. Rebuild the steps from the JSON export, field by field. Where a mapping looks odd, check the Zap history for what it actually sent.
4. Add error handling. Zapier emails you when a Zap fails. In n8n you set an error workflow, started by the Error Trigger node, that alerts the right people and records the failed input. Set one per workflow or one for the whole instance.
5. Compare outputs. Fire the same input at both systems and diff what each one wrote.

Step 5: re-authorise credentials and move webhooks

Connections do not transfer. Every OAuth connection and API key is created again in n8n, by someone with access to the account on the other side.

• Use service accounts where the target system allows it, rather than a person’s login. It saves a rebuild when that person leaves.
• Credentials are encrypted in the n8n database with an encryption key set when the instance is created. Keep that key in your secrets store and in your backups plan: a database restored without it cannot decrypt a single credential.
• Webhook senders are updated one by one to the new n8n addresses. Keep the Zapier webhook live until the sender has been switched and a run has arrived at n8n.

Step 6: run both in parallel, then cut over

Run the two systems side by side. Where a workflow writes to an external system, let only one of them act: switch the Zapier version to log its input instead of writing, or turn off its final step, so nothing is created twice.

Switch Zaps off in the order you rebuilt them. Cancel the subscription only once every kept workflow has run a full cycle in n8n, including the monthly jobs flagged in step 2. Download the final Zap history before the account closes; it is your record of what ran before the move.

Running n8n in production

A migrated estate needs more than a single container.

• PostgreSQL, not SQLite. SQLite is the default and is fine for trying n8n. Production wants PostgreSQL for concurrent executions and clean restores.
• Queue mode. With real volume, n8n runs a main instance and separate workers connected through Redis, so a long workflow does not hold up the rest.
• Execution data pruning. Every run is stored by default. Set a retention period or the database grows without limit.
• Backups and updates. n8n releases often. Updates want a tested path and a way back.

Pilae operates n8n this way on every plan: PostgreSQL, queue mode where the volume calls for it, daily encrypted backups stored offsite in the country you choose, and a restore test every month recorded in the console. It runs on your premises or on dedicated machines in Pilae Cloud, answering only on your private network. If you are comparing more broadly first, see our page on Zapier alternatives.

Let Pilae run the move

Pilae runs Zapier to n8n migrations at a fixed price: the export and inventory, the rebuild, the credential and webhook moves, the parallel run and the cutover. Then we operate n8n for you under a contract with a 99.9% monthly availability commitment. See migration services for what the fixed price covers, or tell us about your Zapier account and we will scope it.