Should I Use n8n, Make or Zapier?

We run a few dozen Zaps, and the bill keeps climbing with our order volume. Someone suggested moving everything to n8n. Is it worth switching, and what would we lose?

Keep what works and move what costs. New flows go on n8n, self-hosted with no per-task fee, or on plain code when nobody needs to edit them.

Moving everything at once is the part I'd skip. It trades a known bill for a rebuild of flows that already work.

What the business would lose is mostly convenience: a managed cloud and a ready-made app for every tool. Both have answers, and both cost something.

Automate the Work With Clear Rules

A job earns a flow with high volume, low judgment and clear rules. Every flow has the same shape: a trigger, the steps, the result.

A trigger starts it: a new order, a payment, a form or a schedule. The steps move the data between tools, so an order becomes a label, an invoice and a row in a sheet. When a step fails, the flow sends an alert.

The jobs that pass all three tests are the usual ones: orders, bookings, leads, payments and weekly reports. Which workflows are worth automating has the longer version.

Invoices are the classic job with clear rules, and they run both ways. In one setup I worked on, an order marked packed emailed the client its delivery document and invoice. Incoming, a flow collects bills into one monthly folder, and a person checks the totals.

A job that needs judgment gets semi-automated: the flow drafts, a person approves. A job done twice a month stays manual.

A flow that fires into a sheet nobody opens gets removed. Observe and Improve is how to spot one.

That last group matters before any migration. Some of those Zaps may not need to exist on any tool.

Once the business knows which jobs earn a flow, the tool question gets narrower.

Billing, Editors and Hosting Pick the Tool

Three questions decide between n8n, Zapier and Make: who pays per run, who edits the flow later, and where it runs.

For a small business, the field is five tools: Zapier, Make, n8n, the CRM's own automations and plain code. The CRM's automations are enough when the whole job stays inside the CRM.

Plain code has no tool ceiling, and it can be versioned and tested. It fits when nobody needs to edit the flow. A shipping app built that way cut a package from 10 minutes to under one, for $3 a month.

n8n fits when the team wants to open a flow and change it itself. Zapier and Make are where flows that already work can stay, not where new ones should start.

Where it runs settles where the data lives. Zapier and Make run in their own cloud, while n8n can run on the business's own server. For an EU business, that alone can be a reason to move.

So for this business the answer splits. The Zaps that work stay on Zapier, new builds go on n8n, and the bill shows which old ones move.

Moving off usage pricing has its own cost, though: the server becomes someone's job.

Self-Hosted n8n Has to Run Like Production

Cloud is the easier start. Self-hosted is cheaper at volume, when it has backups, updates and alerts.

On n8n Cloud, n8n runs the server. Self-hosted is the business's own server, with the data where they put it. On the free Community edition, it has no per-execution fee. The cost moves to upkeep: someone owns the upgrades and the backups.

There's a licensing line too. Under n8n's license, a developer may run a client's flows on the developer's own instance only while the client can't edit them. A team that wants to edit its flows runs them on its own instance. Its credentials are the client's from day one.

Is n8n safe for production? Yes, when it runs like production. Three habits do most of the work:

• Scoped credentials: each flow gets a key that does its job and nothing more, in the company's name.
• Error alerts: one on every flow, set up on day one.
• Careful upgrades: each one read before it's applied. I once saved an IF node the editor accepted and the instance couldn't run, and the error explained nothing.

The other thing the business would miss is a ready-made app.

A Missing Node Has Three Fixes

An HTTP request first, then a code step, then a custom node.

Some of the business's Zaps may use an app n8n has no node for. That's a reason to plan the fix, not to stay. Each fix is heavier than the last:

1. An HTTP Request node calls the app's API directly, with its address and a key. That covers most gaps.
2. A Code node runs JavaScript inside the flow, for the logic a plain request can't do. It works on Cloud too.
3. A custom node wraps the API as a TypeScript package. A private one needs self-hosted n8n.

Past those three, heavy logic moves to a small Node.js service, and the team keeps editing the rest in n8n. Each step up is one more thing that can fail.

Every Flow Needs an Alert

Tools drift, so each flow tells someone when it fails.

A vendor changes an API, a login expires, a payload changes shape. Without an alert, the first to notice is a customer.

When an alert fires, the fix comes in two phases, as in Incident Response. First the smallest fix that gets orders moving, then the root cause.

A Zap that breaks now and then is no reason to move it. A Zap that breaks and costs too much is the first in line.

Zapier Pricing Grows With Every Order

Zapier and Make bill by usage, so every order a flow touches adds to the bill. In October 2026, the pricing pages showed each tool counting something different:

• Zapier counts a task for every action it completes; triggers and its built-in tools don't count. Its Professional plan starts at $19.99 a month, billed yearly, for 750 tasks.
• Make bills in credits, and most actions cost one.
• n8n Cloud counts executions, one per run of a flow "regardless of complexity". Its Starter plan is €20 a month, billed yearly, for 2,500 of them. The free self-hosted Community edition has no execution fee.

So a Zap with five action steps uses 5,000 tasks on 1,000 orders. The same flow on n8n Cloud uses 1,000 executions.

Is Zapier too expensive, then? Compare the plan's task count with what the flows really use. If the bill outgrows the job, the flow's logic moves to n8n or Node.js. If not, the flow gets fixed and stays.

Automation has two bills. Running is the tool plan or the server, plus every API a flow calls, all on the business's own accounts. Building has market rates of its own.

The migration market follows that math. When I researched it in September, most moves ran from Zapier and Make to n8n. The goal was to end usage fees that grew with the business.

How I Move Flows to n8n

I build on two runtimes: Node.js first, versioned and tested, and n8n when the team wants to edit its flows. Zapier and Make I run where a business already has them. I fix the flows there, handle most changes and move the costly ones. A new flow goes on n8n by default, or on Zapier or Make when the business stays there.

A move runs one flow per task, in the order below. I build on the client's instance, and on a self-hosted one its upgrades and backups are on me.

Every flow I build reports a failed step from its first run. The alert reaches me, or the client reports the break, and the fix skips the queue. The same holds for work an agency resells.

Building is one weekly price, shown on the homepage. A small business starts with a one-week audit of what runs. A team hands its flows to n8n development.

What the Business Should Do Now

Move the costliest flow first, run it side by side until it matches, then the next.

The bill shows which flow costs most. That flow gets rebuilt in n8n and runs beside the Zap on the same orders. When the two agree, the Zap goes off and the next flow starts.

One flow at a time means nothing moves all at once, and nothing breaks all at once either.

Not every Zap has to move. The cheap ones that work can stay on Zapier. Moved this way, the business loses no working flow, only the per-task fee on the ones that moved.