How to migrate from Make.com to n8n

Migrating from Make.com to n8n is the process of moving automation workflows from a usage-based SaaS platform to a self-hosted (or n8n Cloud) alternative built on a node-based architecture. The central difference is the pricing model: Make.com bills per operation (each module step a scenario runs), while self-hosted n8n bills only for the server it runs on, regardless of execution volume. For high-volume automations, that distinction is what drives the cost case for switching — and the practical question of how to migrate from Make.com to n8n comes down to rebuilding scenarios as node-based workflows rather than running any kind of automated import.

Migrating from Make.com to n8n means rebuilding your cloud-based scenarios as self-hosted (or n8n Cloud) workflows, remapping triggers, modules, and data structures into n8n’s node-based model. There is no official one-click converter, so the work is manual scenario-to-workflow recreation. The good news is that the logic transfers cleanly because both platforms model automation the same way: a trigger fires, data flows through transformation steps, and actions execute at the end.

Quick Summary: How to Migrate From Make.com to n8n

• Cost model is the deciding factor. Make.com bills per operation; self-hosted n8n bills per server. A workflow processing tens of thousands of operations monthly can drop from a multi-hundred-dollar Make.com plan to the flat cost of a small VPS. The savings grow as execution volume climbs, because the server cost stays fixed.
• No native importer exists. There is no one-click Make-to-n8n converter. Migration is manual scenario-to-workflow recreation, but the logic maps cleanly because both tools use a node-based, trigger-and-action model.
• Node equivalents exist. Make.com “modules” become n8n “nodes.” Routers become Switch nodes. Iterators become Loop Over Items nodes. Most common modules have a direct counterpart.
• Webhooks need reconfiguration. Every webhook URL changes — you must update external services that point at Make.com, or those triggers go silent after cutover.
• Self-hosting unlocks unlimited executions under n8n’s source-available (fair-code) license, but you take on server maintenance, security patching, monitoring, and backups in exchange.
• Timeline: A clean migration of 10–20 scenarios typically runs 3–7 working days including parallel testing. Plan roughly one to two hours per moderately complex scenario.

Last updated: June 13, 2026.

What Is the Difference Between Make.com and n8n?

Make.com is a cloud-only, operation-billed visual automation platform, while n8n is a source-available workflow tool you can self-host for a flat infrastructure cost with unlimited executions. The core distinction is the pricing model: Make charges for every step a scenario runs, n8n (when self-hosted) charges only for the server it runs on.

Make.com (formerly Integromat) counts “operations” — each module execution inside a scenario. A workflow with eight modules processing 1,000 records consumes roughly 8,000 operations. Self-hosted n8n does not meter execution at all. You pay for a server, and that server runs as many workflow executions as its CPU and memory allow.

n8n uses a node-based canvas similar to Make’s module chain, but adds a built-in Code node for raw JavaScript and Python, native AI/LangChain nodes, and the ability to keep workflow definitions under Git-based version control. The platform also supports custom node development, which lets teams extend it beyond the built-in integration catalog — an option that closed ecosystems restrict. (For the current integration count and feature list, consult n8n’s official documentation at docs.n8n.io and pricing details at n8n.io/pricing, since both change frequently.)

The trade-off is real and worth stating plainly. Make.com requires zero infrastructure knowledge; you sign up and build. n8n self-hosting demands a server, occasional Docker maintenance, and someone comfortable reading logs and applying security updates. For teams without DevOps capacity, n8n Cloud exists as a managed middle ground — but it reintroduces execution-based pricing that erodes the cost advantage of self-hosting. Choosing between them is genuinely a question of volume and in-house technical capacity, not a foregone conclusion.

For teams watching the operation meter climb, the answer to whether self-hosted automation beats cloud SaaS usually comes down to volume and team skills. High-frequency workflows favor n8n economically; low-volume, no-code use cases often favor Make.com’s convenience.

How to Migrate From Make.com to n8n Step by Step

Migrating from Make.com to n8n is a seven-step process: audit existing scenarios, provision n8n hosting (self-hosted or cloud), recreate each scenario as a node-based workflow, remap webhooks and credentials, run parallel testing, validate outputs, then cut over. The migration is manual — there is no automated import tool — but the repeatable pattern prevents data loss.

In a typical implementation, a migration of 10–20 scenarios takes 3–7 working days including parallel testing, with credential re-authentication and webhook remapping consuming a meaningful share of the total effort. There is no official import tool, and any claim of a “one-click Make to n8n converter” should be treated with skepticism. The underlying logic transfers cleanly because both platforms model automation as triggers, transformations, and actions.

1. Audit and document every scenario. Export your Make.com scenario blueprints (Make lets you download them as JSON). Catalog each module, its function, and its data dependencies. List every external service connected via webhook.
2. Provision n8n hosting. Spin up a VPS — Hetzner, DigitalOcean, or a Railway instance — and deploy n8n via Docker. A 2GB RAM server handles most SME workloads. Budget 30–60 minutes for setup.
3. Recreate triggers first. Map Make’s instant/scheduled triggers to n8n’s Webhook, Schedule, or app-specific trigger nodes. Generate new webhook URLs at this stage.
4. Rebuild module logic as nodes. Translate each Make module into its n8n node equivalent. Routers become Switch nodes. Filters become IF nodes. HTTP requests stay HTTP Request nodes.
5. Reconnect credentials. Re-authenticate every service (Gmail, Slack, Airtable, OpenAI) inside n8n’s credential manager. Credentials never transfer automatically.
6. Update external webhook endpoints. Point every third-party service that was hitting a Make.com webhook to your new n8n URL. Miss one, and that trigger goes silent.
7. Run parallel and validate. Keep both systems live for 3–7 days (ideally a full billing cycle), compare outputs, then deactivate the Make.com scenario once data matches.

Practitioners generally find that the migrations which fail almost always skip the validation step. A forgotten webhook is the single most common cause of “my automation stopped working” reports after a migration. Document every endpoint and verify each one after cutover.

How Do Make.com Modules Map to n8n Nodes?

Make.com modules map to n8n nodes on a near one-to-one basis for the most common building blocks. Routers become Switch nodes, iterators become Loop Over Items nodes, aggregators become Code or Merge nodes, and HTTP modules become HTTP Request nodes. Understanding this mapping is the technical heart of any successful migration. A smaller set of specialized or proprietary modules requires custom Code nodes or community-built alternatives.

The conceptual model is identical — data flows left to right through processing steps — so most builders adapt within hours. The friction lives in the details of data structure handling. Make.com passes “bundles” between modules; n8n passes “items” as JSON arrays. A Make scenario that processes one bundle at a time often becomes an n8n workflow that processes all items in a single execution, which is faster but changes how you think about loops.

Common Module-to-Node Equivalents

The following conversions cover the majority of standard Make.com workflows. Each maps a Make.com (formerly Integromat) module to its closest n8n counterpart:

• Router → Switch node — routes data into multiple conditional branches
• Filter → IF node — applies true/false gating between two paths
• Iterator → Loop Over Items node — processes arrays one item at a time
• Array Aggregator → Aggregate or Code node — combines multiple items into a single collection
• Set Variable → Set node (Edit Fields) — defines or modifies field values
• HTTP module → HTTP Request node — sends REST API calls
• JSON parse → built into n8n expressions (no separate node needed, unlike Make.com)
• Tools / Sleep → Wait node — pauses execution for a set interval or until a condition

n8n’s expression syntax differs from Make’s, and this is the detail most teams stumble on first. Where Make uses {{1.email}} to reference a numbered module, n8n uses {{ $json.email }} to reference the incoming item, or {{ $('NodeName').item.json.field }} to pull from a named earlier node. Budget extra testing time for any scenario with heavy data mapping, because most conversion effort lands here rather than on simple node substitution.

One genuine advantage: n8n’s Code node can collapse what Make often requires multiple modules to accomplish. A chain of three Make text-parsing modules frequently becomes a few lines of JavaScript in n8n — fewer points of failure and easier maintenance. For complex transformations, this is where building custom AI agents and workflows in n8n can outpace visual-only platforms.

Why Is Self-Hosting n8n Cheaper Than Make.com?

Self-hosting n8n is cheaper at scale because Make.com charges per operation while self-hosted n8n charges only for server capacity, meaning execution volume carries no marginal cost on your own infrastructure. A workflow that costs a few hundred dollars per month in Make operations can run on a small VPS costing single digits per month.

Consider the math at scale. Make.com’s paid tiers bundle a fixed allotment of operations, and once a workflow’s volume pushes past that allotment you move into higher plans (or pay overage charges that stack quickly). A small, self-hosted n8n instance — for example a low-tier Hetzner or DigitalOcean VPS — runs the same execution volume for a flat monthly server fee. Because the server cost does not scale with operation count, the savings compound as volume grows. The exact figures depend on your current Make.com tier and your actual monthly volume, so verify both against live pricing at n8n.io/pricing and Make’s own pricing page before deciding.

This is what we’d describe as escaping the operation tax — the same dynamic behind the more familiar “Zapier tax.” Usage-billed SaaS automation platforms monetize your growth: the more your automation runs, the more you pay. Self-hosted n8n inverts that relationship. Your cost stays flat while execution volume can multiply.

The honest caveat is essential here: self-hosting is not free of cost, it is free of per-execution cost. You take on the true total cost of ownership — server provisioning and uptime, operating-system and application security patching, monitoring and alerting, backups, and the staff time to handle incidents when something breaks at 2 a.m. For a team running only a few thousand operations monthly, Make.com’s fully managed convenience may genuinely be the better value once that maintenance burden is priced in. As a rough planning heuristic, the break-even point often sits somewhere in the tens of thousands of operations per month: above that, n8n’s flat-cost economics tend to dominate; below it, the maintenance overhead may not justify the switch. Run the numbers against your actual volume — including a realistic estimate of maintenance hours — rather than on gut feel, ideally with an automation ROI calculator.

What Are the Biggest Pitfalls When You Migrate From Make.com to n8n?

The biggest pitfalls when you migrate from Make.com to n8n are forgotten webhook reconfigurations, data structure mismatches between bundles and items, missing error-handling logic, and underprovisioned servers that crash under load. Each is preventable with disciplined testing.

Migration failures cluster into four predictable categories. Webhook silence tops the list — external services still point at dead Make.com URLs after cutover. Data mapping errors come second, when Make’s bundle-by-bundle processing gets naively copied into n8n without accounting for item arrays. Third is error handling: Make’s built-in error routes don’t auto-translate, so unhandled failures can silently break a workflow chain. Fourth is infrastructure — a 1GB server choking on a workflow that batches thousands of items.

How to Avoid Migration Failures

• Maintain a webhook registry. List every external endpoint and check each one after cutover.
• Test with real data volumes. A workflow that works on 5 items may break on 5,000 due to memory limits.
• Add Error Trigger workflows. n8n’s dedicated Error Trigger node catches failures and alerts you — rebuild Make’s error routes deliberately.
• Provision generously. Start with 2GB RAM minimum; scale up if you process large datasets.
• Run parallel for a full billing cycle. Don’t decommission Make.com until n8n has proven itself across at least one complete data cycle.

Parallel running is the safeguard that matters most, because the cost of keeping Make.com live for one extra week is trivial against the cost of a silently broken revenue workflow. Practitioners consistently report that the discipline of comparing outputs side by side — rather than the platform switch itself — is what separates a smooth cutover from a scramble.

Worked Example: A Typical Lead-Routing Migration

To make the steps concrete, consider a representative (anonymized, illustrative) scenario that practitioners encounter often. A Make.com scenario watches a web form via webhook, runs the submission through a Router to split leads by region, enriches each record with an HTTP call to a CRM API, then posts a Slack notification. In Make, that scenario consumes roughly four to five operations per submission; at a few thousand submissions a month it sits comfortably inside a mid-tier plan, but a sudden campaign spike can push it into overage territory.

Rebuilding it in n8n looks like this: the form webhook becomes a Webhook trigger node (with a new URL that must be updated on the form provider’s side); the Router becomes a Switch node keyed on the region field; the enrichment step becomes an HTTP Request node; and the notification becomes a Slack node using a freshly authenticated credential. The data-handling shift is the part that trips people up — where Make processed one submission “bundle” at a time, n8n hands the workflow an array of items, so a batched import of historical leads now runs in a single execution rather than one-per-record. The instructive lesson from this pattern: the node mapping is quick, but verifying the new webhook URL and confirming the item-array behavior against real data is where the testing time goes.

Actionable Takeaways: Your Migration Checklist

Ready to move? Use this condensed playbook to execute a clean transition without losing a single automation.

1. Calculate first. Price your current Make.com volume against a self-hosted setup including realistic maintenance time. If you’re at low volume, verify the savings justify the operational overhead. At high volume, migration usually pays off.
2. Export blueprints. Download every Make scenario as JSON for reference documentation.
3. Deploy n8n via Docker on a 2GB+ VPS. Hetzner and Railway are reliable low-cost picks; review n8n’s self-hosting documentation for the current install command.
4. Rebuild triggers, then logic, then actions — in that order, scenario by scenario.
5. Reconnect all credentials inside n8n’s credential vault.
6. Update every external webhook using your registry as a checklist.
7. Run parallel for one full billing cycle and compare outputs before deactivating Make.com.
8. Add Error Trigger workflows for production-critical automations, and set up backups and monitoring before you rely on the instance.

For SMEs without in-house DevOps, the setup-and-maintenance layer is where partnering with a specialist can pay for itself — not because the platform switch is hard, but because the disciplined testing, backup, and monitoring work is easy to under-resource when you’re busy running the business.

The Bigger Picture: Automation Ownership

Migrating from Make.com to n8n isn’t only about trimming a monthly bill. It’s also about who owns your automation infrastructure. When your workflows live on someone else’s metered cloud, every price change, rate limit, and policy update affects your operations directly. Self-hosting n8n hands that control back — at the price of taking on the responsibility for keeping the lights on.

Expect more SMEs to treat automation infrastructure the way they treat their codebase — owned, version-controlled, and portable. The teams building that capability now will be better positioned to reason about cost and risk than those locked into per-operation billing they can’t predict or cap. As with any infrastructure decision, the right answer depends on your volume, your team, and your tolerance for operational ownership.

Frequently Asked Questions

Is there a tool to automatically migrate from Make.com to n8n?

No automatic one-click migration tool exists between Make.com and n8n as of 2026. Migration is a manual process of recreating each scenario as an n8n workflow. The logic maps cleanly — routers become Switch nodes, iterators become Loop Over Items — but you rebuild each workflow by hand and reconfigure all webhooks and credentials.

How long does it take to migrate from Make.com to n8n?

Migrating from Make.com to n8n typically takes 3 to 7 working days for 10–20 scenarios, including testing and parallel running. Simple single-trigger workflows often migrate in under an hour each, while complex scenarios with heavy data transformation and multiple branches can take a full day apiece to rebuild and validate.

Is n8n really cheaper than Make.com?

At high execution volumes, yes — self-hosted n8n charges a flat server fee instead of per-operation pricing, so a workflow that costs a few hundred dollars per month in Make operations can run on a single-digit-to-low-double-digit VPS. But the comparison must include the true cost of self-hosting (maintenance, security patching, monitoring, backups). The break-even often sits in the tens of thousands of operations per month; below that, Make’s managed convenience may be the better value. Confirm figures against live pricing before deciding.

Do I need to be a developer to self-host n8n?

You don’t need to be a developer, but basic comfort with Docker, a command line, and server management helps significantly — and you should be prepared to handle updates, backups, and security patches over time. n8n deploys via a single Docker command, and many SMEs run it successfully with minimal technical staff. Teams without any DevOps capacity often use n8n Cloud or hire a specialist to handle hosting and maintenance.

Will my webhooks still work after migrating to n8n?

No — your webhook URLs change completely when you migrate to n8n, so existing integrations will break unless updated. Every external service that sends data to a Make.com webhook must be reconfigured to point at the new n8n webhook URL. Maintaining a complete webhook registry and verifying each endpoint after cutover prevents silent automation failures.

Note: This article is for general informational purposes; verify specifics against your own context.