Same automations.
Different execution model.

Inventory before you rebuild.

Most teams do not know how many zaps they have or which ones still run. Start with a list: every zap or scenario, its trigger app, its action apps, whether it is on, when it last ran, how often, and who asked for it. Zapier’s history and Make’s execution log give the last run and the volume.

Add two columns by hand: what business process it serves, and what happens if it stops for a day. The first tells you what to group. The second tells you the order to migrate in, lowest stakes first.

Expect to retire part of the list. Automations that have not run in months, duplicates built by different people, and workarounds for problems that no longer exist do not need to be rebuilt.

Group by trigger, not by app.

Zapier encourages one zap per outcome, so a single form submission may feed five zaps. n8n encourages one workflow per trigger with branches inside. Group the inventory by trigger event and design one workflow per group.

This is where most of the simplification comes from. Five zaps that each wait for the same form become one workflow with a Switch node. Shared steps run once. A change to the trigger is made in one place.

It also changes the parallel run. When you replace a group, you pause all the zaps in it at once, which is easier to reason about than a mix of migrated and unmigrated zaps reacting to the same event.

Map each concept to its n8n equivalent.

The vocabulary is different but the shapes are close. The table shows the usual translation. The one real difference is the execution model: Zapier runs a zap once per record, while an n8n node receives all the items from the previous node and processes them as a set. Most workflows never notice. Workflows that assumed one record per run do.

Zap or scenario

An n8n workflow. One per trigger group, with branches inside.

Trigger

A trigger node: a Webhook node, a Schedule Trigger, or an app trigger node that polls.

Action step

A node. App nodes where they exist, the HTTP Request node where they do not.

Paths or router

An IF node for two branches, a Switch node for more. Branches can rejoin through a Merge node.

Filter

A Filter node, or an IF node with one unused branch.

Formatter

A Set node for simple reshaping, expressions for inline changes, a Code node for anything else.

Delay

A Wait node, which can pause for a duration, until a time, or until a webhook call arrives.

Looping and iterators

Items are native in n8n. Use Split Out to expand arrays, Aggregate to collect them, Loop Over Items to pace them.

Storage or data store

n8n Data Tables, or a database node.

Webhooks by Zapier and Code steps

The Webhook node and the Code node.

Rebuild credentials deliberately.

Connections do not transfer. Every app the zaps touch needs a credential in n8n, created by someone with the right access and named so the team can tell accounts apart. See the credentials documentation.

Some apps authorize through OAuth. On n8n cloud the vendor often supplies the app registration; on a self hosted instance you may have to register your own application with the provider and supply its details. Check the credential page for each service before you promise a date.

Use this moment to audit access. A zap built by a former employee on a personal login is a liability you are about to replace. Create service accounts where the provider allows it.

Run both until the numbers match.

Do not switch by turning zaps off and workflows on in the same minute. For each group, build the n8n workflow so it receives the same trigger, performs every read, and writes its intended actions to a log table instead of the destination. Leave the zaps running.

After a few days, compare. Every zap run should have a matching n8n execution with the same intended action. Differences reveal date formats, empty field handling, and edge cases the zap handled by accident. Fix them in n8n while nothing is at stake.

When the log matches, switch the n8n workflow to write for real and pause the zaps in that group. Pause, do not delete. Keep them for the rollback window you decided on, then remove them.

Cut over group by group.

Trigger confirmed

The n8n trigger receives the same events the zaps received, verified with the parallel log.

Actions compared

Intended actions from n8n match the zap history for the comparison window, including empty and unusual records.

Credentials owned

Every credential is on a service or company account, named clearly, and known to at least two people.

Errors visible

An error workflow reports failed executions to a channel someone reads.

Duplicates guarded

Any action that must not repeat has a stored key checked before the side effect.

Zaps paused

The group’s zaps are paused, not deleted, with a date for removal.

Rollback rehearsed

Someone has actually turned a zap back on and the workflow off, and knows how long that takes.

Owner named

One person owns the workflow, its credentials, and its documentation.

Know what changes when you self host.

On Zapier the vendor runs everything. On n8n cloud, the same is mostly true. Self hosted n8n moves updates, backups, TLS, and access control to you. The credential store is encrypted with a key you set; lose it and every credential must be recreated. Back it up alongside the database.

Webhook triggers need a public address that stays stable, since every external system will be configured with it. Execution data grows with volume and needs a retention setting so the database does not fill. See the hosting documentation.

None of this is difficult for a team that already runs a server. For a team that does not, cloud is the honest choice, and the migration is still worth doing for the workflow model alone.

Notes for teams leaving Make.

Make scenarios map more directly than zaps, because Make already works in bundles that resemble n8n items. A router becomes a Switch node. An iterator and aggregator pair becomes Split Out and Aggregate. A data store becomes a Data Table.

The main adjustment is error handling. Make’s error handlers per module become the On Error setting and the error output branch on each n8n node, plus an error workflow for the whole instance. Scheduling intervals map to the Schedule Trigger.

Migrate the same way: inventory, group by trigger, parallel run against a log, then cut over. For help with either platform, see n8n automation services.

Questions.