How to Migrate From Make.com to n8n
Teams that move from Make.com to n8n usually share one of a few profiles. They've been on Make for a while, they understand visual scenario builders well, and they've run into something the visual model can't give them: a custom code block that does real data processing, a workflow that needs to live in a Git repository alongside the application code it serves, or a situation where they want to host the automation engine inside their own infrastructure rather than trust a third-party SaaS with the credentials and data flow.
The other profile is the cost-conscious team that has scaled past Make's operation limits and found that self-hosting n8n on a small server eliminates the per-operation cost entirely. At high automation volumes, the economics are significant. Neither reason is more valid than the other; this guide handles both.
What's actually different
Make.com and n8n are both canvas-based visual tools, which makes the conceptual migration easier than moving from Zapier's linear list. The vocabulary is different but the patterns are close.
| Dimension | Make.com | n8n |
|---|---|---|
| Pricing | Per operation | Self-host free; cloud by workflow |
| Deployment | Cloud only | Docker / npm / cloud |
| Code execution | None native | Code node (JS or Python) |
| Iteration | Iterator + Aggregator | Loop Over Items (built-in node behavior) |
| Error handling | Error handler routes | Error Trigger workflow |
| Versioning | Limited in-app history | JSON export, Git-versionable |
| Credential storage | Make vault | n8n credential store |
The biggest functional difference is the Code node. n8n lets you drop a node anywhere in your workflow and write JavaScript or Python that transforms data, calls a library, or performs logic that would require five chained modules in Make. For engineers who are comfortable writing code, this collapses a lot of multi-module chains into a single, readable, testable function.
The iteration model is also different in a meaningful way. In Make, you explicitly place an Iterator module to split an array, do work, then optionally aggregate. In n8n, many nodes process arrays automatically by running once per item. The IF node, Set node, and HTTP Request node all handle batches of items without a wrapper iterator. When you do need explicit looping, the Loop Over Items node provides it. This is simpler for common patterns and slightly more surprising when n8n's implicit per-item processing isn't what you expected.
Mapping your existing workflows
Make's module types translate to n8n nodes with some renaming.
A Make scenario becomes an n8n workflow. The JSON export that n8n uses is human-readable, which is one of the reasons it version-controls well.
A Make trigger module maps to an n8n trigger node. For webhook triggers, both platforms generate a URL you point external services at. Webhook URLs change when you recreate the trigger, so note every external service that posts to your Make webhooks before you start.
A Make Router maps to n8n's Switch node. You define conditions on each output branch. The Switch node in n8n can have as many branches as you need, same as Make's Router.
A Make Filter between modules maps to n8n's IF node or, for simple true/false gates, an IF node with a single condition. In n8n, the IF node has two outputs: true and false. You can leave the false branch unconnected if you just want to stop execution on non-matching items.
A Make Iterator maps to n8n's default per-item behavior. In n8n, if a node receives an array of items, most nodes process each item automatically. If you specifically need to loop and accumulate state, the Loop Over Items node handles it. If you need to aggregate results back into a single item (like Make's Aggregator), the Merge node with "Combine" mode works.
A Make HTTP module maps directly to n8n's HTTP Request node. The configuration options are similar: URL, method, headers, body type, authentication.
A Make Tools module (text manipulation, date parsing, etc.) maps to n8n's Set node with expressions. n8n's expression language covers most of Make's built-in functions: string manipulation, date formatting, number operations, and JSON path access. Complex transformations go into the Code node.
Make's Data Store (built-in key-value storage) has no direct n8n equivalent. You'll need to wire in an external data store: a Postgres or MySQL node, a Redis HTTP call, or a simple Google Sheets or Airtable node for lighter use cases.
The actual migration steps
Step 1: Export and document your Make scenarios. Make doesn't have a bulk export feature. Go through each active scenario and document: the trigger, every module in order, the filters on each Router route, and any Data Store references. Screenshots are useful here because Make's canvas shows the full structure visually.
Step 2: Set up n8n. For self-hosting, Docker is the standard approach. Pull the n8nio/n8n image, set your environment variables for authentication and the external URL, and mount a persistent volume for the database. n8n supports both SQLite (simple) and Postgres (production). If you want to test before committing to infrastructure, n8n Cloud has a trial.
Step 3: Export n8n workflows as JSON from the start. Once you've set up n8n, get in the habit of exporting workflows as JSON files and committing them to your repository. This is one of the key advantages over Make: your automation definitions live alongside your code. Store them in a /workflows directory in your repo.
Step 4: Rebuild a pilot workflow. Choose a scenario that's representative of your typical complexity. Rebuild it node by node in n8n. Pay attention to how data references work: n8n uses {{ $json.fieldName }} for the current node's output and {{ $('NodeName').item.json.fieldName }} to reference a specific previous node. This is more explicit than Make's reference system but also more predictable in complex workflows.
Step 5: Run in parallel. Activate the n8n workflow alongside the Make scenario and compare outputs for a few days. When you're satisfied with parity, update any webhook URLs in external services to point to n8n, then deactivate the Make scenario.
Step 6: Work through your inventory systematically. Migrate scenarios in batches, prioritizing by execution volume or business criticality. Deactivate each Make scenario only after the n8n equivalent has run in production without errors.
Gotchas you'll hit
Webhook URLs change. This is the most operationally demanding part of the migration. Every Make scenario triggered by a webhook has a URL that external services are hitting. When you recreate that trigger in n8n, the URL is different. You need to update every external service before switching off the Make scenario. Make a thorough list of webhook-triggered scenarios and their callers before you start.
Data Store references need a new home. If any of your Make scenarios read from or write to Make's Data Store, you'll need to pick a replacement. Postgres is the most common choice for teams running n8n on their own server. For simple key-value needs, a Redis instance or even a Google Sheets integration works.
n8n's expression syntax has a learning curve. Make uses a module output reference panel that you click through. n8n uses text expressions with a specific syntax. The n8n expression editor has an autocomplete panel that helps, but expect to spend time learning the reference patterns, especially for accessing items from non-adjacent nodes.
Error handling requires explicit setup. Make's error handler routes are configured per-module. In n8n, error handling is done at the workflow level via the Error Trigger workflow. Create a dedicated error-handling workflow and connect your main workflows to it via the "Error Workflow" setting. Without this, errors will just show up in the execution log with no alerting.
Self-hosting means managing updates. Make.com updates automatically. With self-hosted n8n, you're responsible for pulling new Docker images and running database migrations. Set up a maintenance window and test major version updates on a staging instance before applying to production.
Make's built-in functions don't have identical n8n expressions. Most common functions translate directly, but a few Make-specific functions (some array operations, certain date formats) need to be reimplemented with n8n's expression language or a short Code node. Budget a bit of extra time for these edge cases.
When NOT to switch
There are scenarios where Make.com is the better choice to stay with.
If your team relies heavily on non-technical users building and editing scenarios, Make's visual interface with its click-to-reference output values is friendlier than n8n's expression syntax. The onboarding difference is meaningful for business users.
If you're using Make-specific modules for apps that don't have an n8n node and don't have a public API, you'll need to build the integration yourself using n8n's HTTP Request node. Check your app inventory against n8n's node library first.
If you're not ready to manage infrastructure, Make's cloud is mature and reliable. n8n Cloud is an option, but self-hosting's cost advantage is the main reason most teams make this switch.
The migration from Make.com to n8n is one of the smoother transitions in the automation space because both tools share the visual canvas mental model. The main work is operational: documenting your scenarios, updating webhook URLs, and finding alternatives for Make-specific features like Data Store.
Teams that invest a week or two in the migration typically end up with workflows that are easier to maintain, version-controlled, and running at a fraction of the previous cost. The Code node alone often justifies the switch for any team with engineering resources.