Migrating from Make (Integromat) to n8n: a practical step-by-step guide

Make (formerly Integromat) remains one of the most powerful no-code tools on the market — its visual canvas with routers, iterators and aggregators goes well beyond a simple Zapier. But that power comes at a price, literally: past a certain volume, per-operation billing and the limits of the built-in function editor push more and more teams to make the switch to n8n. The good news: unlike switching CRMs, your data doesn't move — only the orchestration layer changes. Here's how to do it without breaking anything.

Why migrate, in concrete terms

Three reasons come up again and again with teams making the switch from Make:

• An operations model that punishes sophisticated scenarios. Make counts one operation per module execution. A scenario with an iterator unrolling 50 rows, followed by 3 processing modules, consumes over 150 operations for a single trigger event. On a 10,000-operations/month plan, a few dozen daily runs of a rich scenario are enough to blow through the quota. Self-hosted n8n charges nothing per execution: the marginal cost of a workflow running 10 times or 10,000 times a month is identical.
• Data control. On Make, your data flows through and is temporarily stored on third-party infrastructure (hosted in the EU or the US depending on the region picked when the account was created, with no way to change it afterward). Self-hosted on n8n, it stays on your own server — a point that matters more and more for teams under GDPR or contractual data-residency requirements.
• More complete code logic. Make's function editor is limited to IML expressions within a constrained scope. n8n gives you a full JavaScript or Python Code node, with access to data from any preceding node, npm packages when self-hosted, and reusable sub-workflows — useful the moment your logic goes beyond simple transformation.

Before you start: map your Make scenarios

This is the step everyone wants to skip, and it's exactly the one that prevents nasty surprises later. For every active scenario, list:

• The exact trigger (webhook, polling, a third-party app's trigger module) and its scheduling frequency.
• The cascading modules, in order, paying special attention to routers (multiple branches) and iterator/aggregator pairs.
• Any filters applied on each route.
• The Data Stores used, their column structure and current volume.
• The third-party connections (credentials) used and their authentication mode.
• The business criticality: a scenario that feeds invoicing carries a different risk level than an informational Slack notification.

This mapping also becomes your test baseline: once the scenario is rebuilt in n8n, you'll know exactly what behavior to verify before cutting over from the original.

Module equivalents you need to know

The good news: most Make building blocks have a direct n8n equivalent, and they're often clearer once you've grasped n8n's item-based data model.

Make	n8n
Router	Switch node — routes to multiple branches based on a field's value, without stacking a router's filters
Filter (on a route)	IF node, or conditions directly inside a Switch node
Iterator	Split Out node — unrolls an array into individual items, one per row rather than one per bundle
Aggregator	Aggregate node — groups N items into one, with "Individual Fields" or "All Item Data" modes
Data Store	An n8n Data Table for small internal volumes, or Postgres/Supabase beyond a few thousand rows
Webhooks (receiving module)	Webhook node as a trigger
HTTP > Make a request	HTTP Request node
Text/Function editor (IML)	Set node for simple formatting, Code node (JavaScript or Python) for richer logic
Sleep	Wait node

The main thing to watch is the iterator/aggregator pair: Make processes data as "bundles" (each pass through an iterator produces a bundle handled sequentially through the following modules), while n8n handles items that all travel together between two nodes, with each node running once per item received. The end logic is equivalent, but the way you reason about it differs — our guide on Split Out and Aggregate in n8n covers this data model in detail and helps avoid the classic pitfalls (a downstream node unexpectedly running N times, for instance).

Migrate scenario by scenario, not all at once

Rebuilding every scenario in one big push is tempting — and it's the surest way to multiply risk. A single mapping or counting error is hard to isolate if ten automations switch over on the same day.

The method that works:

1. Rank your scenarios by criticality, and start with the lowest-risk ones (internal notifications, non-blocking syncs).
2. Rebuild one scenario at a time in n8n, working from your initial mapping.
3. Test it in isolation with real data but a manual trigger, before switching it to run continuously.
4. Once validated, move to the next one.

For scenarios combining several distinct pieces of logic (a router with five different branches, say), splitting the result into sub-workflows makes both testing and maintenance easier — see our guide on breaking down complex n8n workflows into sub-workflows.

Coexistence: run both in parallel

Before disabling a Make scenario, let it keep running alongside its n8n equivalent for a period ranging from a few days to a few weeks, depending on criticality. Compare the output of both systems against the same events: same data sent, same actions triggered, same fields populated in the target tool.

This coexistence period is the single best safety net in the whole migration — it turns a bet into a verification. To avoid duplicate side effects during this phase, a common trick is to have both systems write to separate fields or identifiers, then unify once n8n is validated.

Classic pitfalls specific to Make

• Bundles vs. items. A Make scenario that handles bundles one at a time can look, once rebuilt in n8n, as if "data is missing" — in reality it's all there, just grouped differently until an Aggregate node is inserted in the right spot.
• Per-module error routes disappear. Make lets you attach an error handler directly to a module (Break, Resume, Ignore, Commit). n8n doesn't do this natively at the node level: you need to set up a global Error Workflow or explicit handling branches, otherwise an error that Make silently absorbed can stop an n8n execution dead.
• Unmanaged rate limits. Make absorbs part of the responsibility for handling third-party API rate limits, fairly opaquely. Migrating to n8n, that responsibility becomes yours — our guide on rate limiting API calls in n8n covers the patterns to put in place (Loop Over Items, Wait, reading the retry-after header).
• Data Stores to re-export, not recreate as-is. The default 10,000-row cap on a Make Data Store often pushes teams into workarounds (several Data Stores for a single need). Migrating to Postgres or Supabase is the moment to go back to a clean schema instead of reproducing the workaround.

Migrating connections and API keys

Make doesn't let you export the connections stored in a scenario — OAuth tokens, API keys, passwords. Every credential has to be recreated directly inside n8n:

• For a simple API key (most SaaS tools), grab the value from the provider's account and create a dedicated n8n credential.
• For an OAuth2 connection (Google Workspace, Slack, HubSpot), you'll need to redo the authorization from n8n — the existing Make connection doesn't carry over.
• Use this step to set up clean credential management from the start: see our guide on securing credentials and API keys in n8n for project-based structuring and key rotation.

What the research says about moving to more open tools

The argument isn't specific to n8n: a study by Zhaohang Yan (University of Toronto, 2021) on the impact of low-code/no-code development notes that these platforms do speed up delivery, but create a strong dependency on the vendor — a constraint that weighs more and more as scenarios grow in complexity and execution volume (read the paper on arXiv, also indexed on Google Scholar). That's exactly the shift described by teams leaving Make for n8n once volume and complexity pile up: keeping the power of visual no-code, without the dependency on a closed, per-operation-billed execution engine.

Final checklist before disabling your Make scenarios

• The equivalent scenario has been running in n8n for at least a few days with no errors.
• Output from both systems has been compared on real cases, not just synthetic tests.
• An Error Workflow or retry policy is in place for critical steps, replacing Make's per-module error handlers.
• All required Data Stores have been exported and reimported, with a verified structure rather than a straight copy.
• All connections have been recreated and tested in n8n.
• The original Make scenario is paused (not immediately deleted) for one final safety-net week before permanent deletion.

Wrapping up

Once your Make scenarios are rebuilt in n8n, the building blocks most frequently asked for — AI email triage and prioritization, a RAG documentation assistant, conversational audit questionnaires — already exist ready to use instead of being rebuilt from scratch: the Inbox AI Pack (€79), the RAG Assistant Pack (€119) and the Compliance & Audit Pack (€149) cover these use cases with n8n workflows you can import directly. To pin down exactly where Make keeps the edge and where n8n takes over, our comparison n8n vs Make vs Zapier is the reference to check before deciding.