Moving from Make to n8n: how the migration works and what breaks

Mostly for two reasons: cost at volume and control. Make bills for each module action a scenario performs, so long or busy scenarios get more expensive as they grow. n8n counts one run of a whole workflow as one execution, however many steps it has, and it can be hosted on your own server.

The second reason is control: where your data lives, how failures are handled, and who can see and change the automations. Make is still the cheaper and faster place to start for short scenarios at moderate volume, and we say so when that is your case. The full comparison is in n8n vs Make.

One Make scenario becomes one n8n workflow, and each Make module becomes a node. Most pieces have a direct counterpart, and a few need a different design. This is the map we work from.

Make data stores, the Rollback error handler, and apps that have a Make module but no n8n node are the usual gaps. None of them blocks a migration, but each needs a deliberate replacement, and we list them for you before we quote.

• Data stores. Rebuilt as a table, in n8n or in a database you already own, with the existing records copied across.
• Rollback. Make can undo earlier steps in a scenario when a later step fails. n8n does not undo automatically, so we add explicit clean-up steps where a half-finished run would leave bad data.
• Apps with no n8n node. We connect to the app directly through its own interface, which covers almost every tool that has one.
• Run history. Your past Make execution history stays in Make. n8n starts its own history from the first run, so we export anything you need to keep before Make is switched off.

Yes. We build the n8n version while your Make scenarios keep running, so nothing stops while we work. We switch over one scenario at a time, only after the n8n version has produced the same results on your real data.

During the overlap the n8n copy is kept from writing to your live systems, so a record is never handled twice. At the switch we repoint the trigger, turn the Make scenario off, and keep it paused for a while so there is an easy way back.

No, they are recreated. Make trigger addresses and app logins cannot be copied into n8n, so we list every trigger and connection in your account, reconnect each app inside your own n8n, and repoint each sender at cutover.

The logins live in your n8n, not in ours, so you hold everything. We recommend creating fresh keys for each app during the move instead of reusing old ones, since Make held the originals.

Count what each scenario consumes. In Make that is the module actions per run times the number of runs. In n8n it is the number of runs. We work this out scenario by scenario before quoting, and you can try your own numbers in the automation cost comparator.

Short scenarios at low volume can be cheaper to leave on Make, and self-hosting n8n has its own small running cost. We show both sides, and if staying put is the better answer, that is what we tell you.

Often only the expensive or fragile ones. Make and n8n can run side by side for as long as you like, so a sensible first step is to move the scenarios that cost the most or fail the most, and leave the rest.

If you want to see how Make fits into the picture first, read about our Make work. If part of your stack is on Zapier instead, the same approach is described on the Zapier migration page.

For an insurance operation we migrated 1,574 contacts, 1,222 policies and 32,279 notes with zero data loss and a full backup kept throughout, and delivered a working proof of concept in a single day. The tools were different, the method is the one we use for every move: map first, run in parallel, switch when the results match.

Read the full case study →

Clutch Top Company 2023 · Upwork Top Rated, $500K+ delivered · Fortune 500 work delivered under NDA. We do not demo. We deploy, with tests, monitoring, and documentation, the same way we have shipped 200+ times.