Make to n8n Migration: When It's Worth It (2026 Guide)

Make bills per operation, and an operation is a single module execution. A five-step scenario running a thousand times a month consumes five thousand operations rather than one thousand. That arithmetic is entirely reasonable at low volume and becomes uncomfortable at scale, and the discomfort arrives without anything about the workflow having changed. The scenario that cost nine dollars a month at ten thousand credits is the same scenario at five hundred thousand credits, where it costs several hundred.

This is worth stating carefully, because it is not a criticism of Make's pricing. Usage-based pricing is honest pricing. The issue is that it converts a fixed cost into a variable one that scales with your success, which is precisely the property that makes teams want to own the thing instead.

The second trigger is a genuine ceiling. Complex branching, deep data transformation, custom retry logic, structured output validation. At some point a workflow needs code, and Make's answer is to call an external service while n8n's answer is a code node in JavaScript or Python inside the workflow itself.

For AI work the gap is wider. Both platforms ship AI nodes and they are at rough parity for simple agents, meaning call a model, call a tool, return a result. For anything requiring memory persistence, custom retries, or validated structured output, n8n lets you write the missing piece in place. On Make you are building a service to fill the hole, which means you now maintain a service in addition to the automation platform you were trying to avoid maintaining.

The reason this migration is worth considering is that self-hosted n8n costs almost nothing to run.

A small virtual server from Hetzner, DigitalOcean, or a comparable provider handles most small-to-medium automation loads comfortably for somewhere between a few dollars and fifteen dollars a month. On that instance executions are unlimited. There is no per-operation counter, no credit pack, and no invoice that grows when the business does.

Set against a Make plan running into the hundreds, the payback period on migration engineering is typically eight to twelve weeks. That number is worth holding onto, because it is the thing that determines whether this is a good idea.

The comparison is not quite that clean, however, because self-hosting carries costs that never appear on an invoice. Docker configuration, a reverse proxy, TLS certificates, automated backups, monitoring, and version upgrades that occasionally break something. Somebody owns all of that. If nobody on the team wants to, n8n Cloud exists and sits between the two options on both cost and effort, though it also removes most of the financial argument for moving in the first place.

This section is missing from most articles on this topic, and the reason is that most articles on this topic are written by people who would like to sell you a migration.

Stay if the bill is under a hundred dollars a month. The engineering time will cost more than a year of savings, and you will have acquired server maintenance in exchange for nothing.

Stay if the team is non-technical. Make's actual product is that somebody in marketing can build and edit an automation without waiting for a developer. n8n does not have that property, and describing it as slightly more technical understates the difference considerably. A migration can create a dependency on your one technical person where none previously existed, which is a real organisational cost that never appears in a cost comparison.

Stay if the workflows are simple notifications and volume is flat. The per-operation model only becomes painful when operations multiply.

Stay if nobody wants to own a server. This is not a minor consideration. Backups, uptime, updates, and the failure at two in the morning are now somebody's responsibility. If the answer to who handles that is a shrug, the migration will quietly decay and you will end up worse off than when you started.

The rule we use is that migration makes sense when the durable cost of Make operations exceeds the cost of a server plus the hours to maintain it, or when a real requirement rather than a preference has hit a wall. Until one of those is true, staying is the correct engineering decision rather than a failure of ambition.

If the decision is made, do it incrementally. The failure mode is a single cutover on a Friday afternoon.

1. 01

   Inventory and rank

   List every scenario, its monthly operation count, and what breaks if it stops running. You will usually find that a small number of workflows account for most of the cost. Migrate those first, so the savings arrive early while the risk stays low.

2. 02

   Stand up n8n in parallel

   Docker on a small server, reverse proxy, TLS, and automated backups configured from the first day rather than added later. Make keeps running throughout. Nothing is at risk yet.

3. 03

   Rebuild one workflow and compare outputs

   Do not assume it works because it looks correct. Run both versions against the same inputs for a week and compare the results. Discrepancies at this stage are almost always subtle differences in how the two platforms handle data shape, and they are dramatically cheaper to find now than after cutover.

4. 04

   Cut over one workflow at a time

   Switch a single trigger. Watch it for a few days. Then move to the next. The temptation after a smooth first migration is to move five at once, and that temptation is where migrations go wrong.

5. 05

   Commit the workflows to Git

   n8n workflows are JSON, so version them. This is a genuine capability upgrade over Make that most teams forget to use. It converts your automation from something living in a dashboard into something living in your repository, which means it can be reviewed, rolled back, and reproduced.

6. 06

   Cancel Make last

   Only after everything has run cleanly for a full billing cycle. A month of overlapping subscriptions costs one month. A premature cancellation costs a weekend.

Most of our automation work is not greenfield. It is inheriting something that already exists and has become slow, expensive, or fragile, which is a different problem from building fresh and calls for a different first move.

That work usually starts with an audit rather than a rebuild, and it regularly ends with moving only the parts that hurt. A workflow costing eight dollars a month and working correctly does not need migrating because the rest of the stack is moving. Wholesale migration is satisfying and frequently wasteful.

We build in n8n and will say so plainly. But if a client's problem is solved by staying on Make and fixing three scenarios, that is a smaller engagement and the correct answer, and telling them so costs us less than delivering a migration they did not need.