Migrate from Make to n8n

How to migrate from Make to n8n without losing scenario logic

Make scenarios can be planned from blueprint exports, but the export does not carry the connections, so the migration is a rebuild rather than an import. A Make blueprint is a .json file that holds the scenario's modules, module settings and mapped values, and Make's help center states that connections must be recreated after import. Whether the trigger is a renewal, a credit bill that keeps climbing, or a need to run workflows inside your network, the work is the same: each scenario is read, redrawn as an n8n workflow, reconnected to credentials in your own instance, and tested against live data before the Make version is switched off. Integration engineers usually carry this work, with an internal owner who signs off on which scenarios move first and which are retired.

The effort and risk concentrate in three places: routers, iterators and aggregators, and error handling. Start by inventorying every scenario, its trigger type, its data volume and any scenario that depends on another, then map each module to an n8n node or a code step and record the gaps. Decide how each scenario will be tested, for example by replaying a sample of past runs in a staging instance. Credentials need their own plan, because they must be re-authorized in n8n and stored under the encryption key of your instance. Confirm with n8n's current pricing page which edition covers your needs, since features such as SSO and environments with Git sit in the paid tiers.

Licensing belongs in the plan from the start. n8n is source-available under the Sustainable Use License, not an OSI open source license. That license allows use for your own internal business purposes and non-commercial or personal use, but it does not allow you to offer n8n as a managed service to others, and files with .ee in their name require an n8n Enterprise License. Have legal or procurement review the LICENSE file against how your organization will use the platform before the first scenario is rebuilt, and confirm whether any of your planned use involves external customers or resale.

Which Make capabilities map cleanly to n8n and which need rework

This table maps the Make scenario elements you will need to rebuild onto n8n nodes and sub-workflows, and marks each as clean, needs rework or gap. Read the status column as a planning signal, not a guarantee: the mapping depends on whether n8n has a node for each app in your own environment, so confirm node coverage for every app before you commit to a migration plan. Most of the effort usually sits in error handling, data mapping and connection recreation rather than in the routing logic itself.

Make capability	n8n equivalent	Status
Modules and app connections	Nodes for each app, with credentials stored in n8n	Needs rework
Routers	IF and Switch nodes that branch on item fields	Clean
Iterators	Split In Batches or item-based execution per incoming item	Needs rework
Aggregators	Aggregate and Summarize nodes, or Code node logic	Needs rework
Mapped data between modules	Expressions that reference earlier node output by name	Needs rework
Error handlers and retries	Error Trigger workflows and per-node retry settings, designed again	Gap
Scheduling	Schedule Trigger nodes with cron-style timing	Clean
Webhooks	Webhook trigger nodes with their own production and test URLs	Clean
Sub-scenarios	Sub-workflows called with the Execute Workflow node	Clean

What a Make blueprint exports and what must be recreated

A Make blueprint is the starting point for the rebuild, but it describes only part of a scenario. The cards below separate what the JSON file carries from what sits outside it, so the migration team can inventory every dependency before rebuilding anything in n8n.

Modules, settings and mapped values

A blueprint .json file holds each scenario's modules, their configuration and the values mapped between them. This is the logic you can read directly: which app each step calls, which fields feed which inputs and in what order the steps run. Use it as the specification for the n8n nodes you will build. Check that every module type in the file has an equivalent node or HTTP Request pattern in n8n before committing to a timeline.

Connections must be recreated

Connections are not included in the export. Every app login, OAuth grant and API key referenced by a module has to be created again in the target n8n instance as a credential. Make a list of the connections per scenario, note which accounts own them and who can re-authorize each one. Credentials stored in n8n are encrypted with the instance key, so plan where they will be created and who holds access to them.

Schedules and trigger settings

The blueprint records module settings, but the operational schedule that starts a scenario is the team's responsibility to confirm. Write down each scenario's run interval, time zone and active or paused state. In n8n, the equivalent is a Schedule Trigger node, and it has to be activated after import. Missing a schedule is a common cause of silent gaps in data flows after cutover.

Webhook URLs and inbound endpoints

Webhook addresses generated by Make are tied to its hosted service, so external systems that post to them must be pointed at new n8n webhook URLs. Inventory every inbound endpoint, the sender that calls it and the payload it expects. Confirm the new n8n URLs are reachable from each sender's network, including any on-premises systems that Make could not reach directly.

Custom functions and data stores

Blueprints do not describe the data stores a scenario reads and writes, and they do not capture custom functions or code that lives in other places. Identify every Make data store, every external database table and every script the scenario depends on. Decide whether each one moves to n8n, stays where it is or is replaced, and confirm who owns that decision before the rebuild starts.

Operational history and ownership

Run history, error logs, scenario owners and the teams that rely on each output are outside the blueprint. Record which scenarios are business critical, which ones are dormant and who signs off on cutover for each. Ask your Make administrator to confirm which team accounts and organization settings hold the scenarios, since a blueprint export captures a single scenario at a time.

Migration sequence from inventory to decommission

This sequence moves Make scenarios into self-hosted n8n one at a time, with each scenario proven against its Make output before Make is switched off. Each step ends with a named artifact so the team can see what is finished and what is still open.

Build the scenario register from Make
Start by listing every active and paused scenario in the Make organization, with its owner, trigger, modules, schedule, data volume and the systems it touches. Export each scenario as a blueprint .json file, since the blueprint holds the modules, module settings and mapped values but not connections. Record which scenarios call private systems, which send data outside your network and which depend on a Make data store or webhook URL. The output is a scenario register: one row per scenario with a risk rating and a named business owner. The step is done when every scenario has a row and an owner has confirmed it is still needed.
Review blueprints and map modules to n8n nodes
Open each blueprint JSON in a text editor or diff tool and read the module sequence, router branches, iterators, aggregators and error handlers. For each module, note the n8n node or HTTP Request call that will replace it, and flag modules with no native node so they can be rebuilt with a generic HTTP call or custom code. Write down the mapped values that reference other modules, because these become expressions in n8n. The output is a mapping sheet attached to the register, with a complexity score and a list of open questions for the vendor or the application owner. The step is done when every module in the register has a mapping or a documented gap.
Rebuild a pilot scenario in self-hosted n8n
Choose one low-risk scenario that uses common apps and a single trigger, then rebuild it in a self-hosted n8n instance inside your network. Recreate every credential in n8n, since Make connections are not carried over in the blueprint, and check each one against the source system's own permissions. Use a test copy of the data where possible and keep the Make scenario running unchanged. Confirm that the n8n license edition matches the features the scenario needs, since the Community edition is free to run and paid editions add features such as SSO and log streaming. The output is a working pilot workflow and a test log that records inputs, outputs and errors for each run. The step is done when the pilot has run successfully against agreed test cases.
Run the parallel test and compare outputs
Run the pilot and the Make scenario side by side on the same inputs for a period the owner agrees in writing. Compare record counts, field values, timestamps, error paths and any messages sent to people or external systems. Pay particular attention to iterator and aggregator behavior, duplicate handling and retries, because small differences there cause the most surprises. Note that n8n counts an execution as one run of a whole workflow regardless of step count, so credit or execution figures in both platforms should be compared by the team, not assumed. The output is a signed comparison log with each difference classified as expected, fixed or accepted by the owner. The step is done when no unexplained differences remain for that scenario.
Cut over each scenario with a checklist
Move scenarios one at a time, not all at once. For each scenario, prepare a cutover checklist that lists the trigger change, webhook URL changes in upstream systems, schedule times, n8n credential checks, monitoring alerts, a rollback step that turns the Make scenario back on, and the person who approves the switch. Disable the Make scenario only after the n8n version has run in production under the checklist. If the n8n setup uses queue mode, confirm that the encryption key is shared with every worker and webhook processor, because workers need it to read stored credentials. The output is a completed cutover checklist per scenario and an updated register that marks each scenario as live in n8n. The step is done when the owner signs off and the rollback path has been tested.
Decommission Make connections and scenarios
After all scenarios in the register are live in n8n and the observation period has passed without open incidents, turn off the remaining Make scenarios and remove stored connections, webhooks and data stores that are no longer used. Revoke the API tokens and service accounts that Make used to reach your systems, and rotate any secret that was shared with Make. Keep the final blueprint exports and comparison logs in your records system so the decisions can be audited later. Confirm with your Make account owner what happens to your data and subscription at the end of the contract, and ask for written confirmation. The output is a decommission record listing each removed connection, revoked credential and archived export. The step is done when the register shows every scenario as retired or live in n8n and no Make credential remains in use.

What drives cost and duration in a Make to n8n move

This table lists the factors that change how much a Make to n8n move costs and how long it takes, with a way to reduce each one. Read it as a checklist for scoping and for asking vendors and implementation partners for a written quote. Cost falls into four components: hosting, rebuild labor, the license edition decision and ongoing operations.

Driver	Why it changes cost or effort	How to keep it down
Number and complexity of scenarios	Each scenario is rebuilt and tested by hand, so routers, error paths and sub-scenarios multiply the rebuild labor.	Inventory all scenarios from blueprint exports first, retire unused ones and group similar scenarios into shared templates.
Distinct app connections	Make blueprints exclude connections, so every app login or token must be recreated and verified in n8n credentials.	List every connection per scenario, consolidate shared accounts and confirm with each app owner who can authorize them.
Iterators and aggregators	Loops over large bundles can behave differently in n8n and need redesign, which adds testing time.	Document expected item counts per run and test with realistic sample volumes before cutover.
Custom code and functions	Make code modules and external calls may need rewriting in n8n JavaScript or Python nodes and new error handling.	Count code steps early, move reusable logic into shared sub-workflows and reuse tested snippets.
Hosting and queue mode design	A single instance is simpler to run, while queue mode with Redis and PostgreSQL adds components to provision, secure and monitor. Shared encryption keys across workers must be managed carefully.	Start with a single-instance design sized to actual volume and add queue mode only when throughput requires it.
SSO and license edition	SSO with SAML, Git environments and log streaming are listed only on n8n Business and Enterprise plans, and multi-main high availability is Enterprise self-hosted only. Edition choice shifts the license line item.	Confirm required features against the n8n pricing page before design, and ask for a written license recommendation.
Monitoring and ongoing operations	Someone must watch executions, failed runs, updates and backups after go-live, a recurring cost that continues after the migration project ends.	Define alerting and owners before cutover and agree on a support model, in-house or retainer, in the written scope.

How the migration differs by team size and starting point

A small team with a handful of scenarios can usually treat the migration as a single project owned by one or two people. The inventory is short enough to read every blueprint by hand, and most of the effort goes into recreating connections and testing each flow end to end. Because the scenario count is low, the operating model can stay simple, with one n8n instance, a backup routine and a shared place to store credentials.

Scope: Export each scenario as a blueprint .json file and list its modules, routers and error handlers in a single spreadsheet.
Sequence: Rebuild the most business-critical scenario first, then move the rest in order of risk, retiring each Make scenario only after its replacement has run cleanly.
Connections: Plan to recreate every app connection by hand, since blueprints do not carry account credentials.
Operations: Run one n8n instance with a documented backup of its data and encryption key, and confirm what the Community edition provides for your needs.
Licensing: Confirm with counsel that your internal use fits the Sustainable Use License before you start.

Before you begin, ask whether anyone on the team will own the n8n instance after the project ends, because a small team often loses its only maintainer.

What usually goes wrong in a Make to n8n migration

Most failed Make to n8n rebuilds do not fail on the workflow logic itself. They fail on what sits around it: connections that were never recreated, mapping behavior that changed quietly, and scenarios nobody wrote down. The cards below cover the risks we see most often and the check that prevents each one.

Missed connections and credentials

A Make blueprint holds the modules, module settings and mapped values, but connections are not included and must be recreated after import. Each rebuilt n8n workflow will fail at its first call to a service unless credentials exist in the target instance. Prevention: build a connection inventory from every blueprint before any rebuild starts, create each credential in n8n under the owning team's account, and test each node with real input before enabling the trigger.

Silent differences in data mapping

Make and n8n both pass data between steps, but they address and shape items differently, so a mapped field can resolve to an empty value or a different array item without raising an error. Empty results often look like success until a downstream system receives incomplete records. Prevention: for each mapped field, compare sample outputs from the Make run history with the n8n execution output, and add explicit checks for empty values and array length on the first production runs.

Timing and schedule drift

Schedules, time zones and polling intervals do not carry over automatically when a scenario is rebuilt. A trigger set to run every few minutes in Make may be configured differently in n8n, and daylight saving changes can shift runs by an hour. Prevention: record each schedule and its time zone from the source scenario, set the same values on the n8n trigger, and run both systems in parallel for one full business cycle with the Make scenario disabled only after the comparison matches.

Unplanned execution counts

n8n counts an execution as one run of a whole workflow regardless of the number of steps, while Make bills by credits that scale with operations. The two meters do not translate one to one, so a plan sized from Make credit usage can be wrong in either direction. Prevention: review the n8n pricing page for the plan and edition you are considering, then estimate runs per workflow from Make history before choosing a tier, and confirm the counting rules in writing with n8n.

Undocumented scenarios owned by departed staff

Scenarios built by one person often hold business rules that exist nowhere else, such as exception handling, manual approvals or hard-coded lists. Once that person leaves, nobody knows which scenarios are still live or what they should do. Prevention: list every scenario in the Make organization, mark owners and last run dates, export each blueprint, and assign a named owner in the migration plan for every workflow before it is rebuilt or retired.

Encryption key missing on workers in queue mode

In n8n queue mode, the main instance handles triggers and webhooks and hands executions to workers through Redis, and workers read credentials from PostgreSQL. The main instance's encryption key must be shared with every worker and webhook processor, or workers cannot decrypt stored credentials and executions fail. Prevention: set the same encryption key on the main instance, all workers and all webhook processors during deployment, store it in your secrets manager, and test a credential-backed workflow on a worker before cutover.

What the Sustainable Use License and n8n editions mean for the plan

Before you commit to n8n, confirm that its licensing fits how you plan to run it. n8n's main codebase is under the Sustainable Use License, which permits use or modification for your own internal business purposes or for non-commercial or personal use. Distribution is limited to free-of-charge, non-commercial purposes. That means an internal Make replacement running in your own network usually sits inside the permitted use, but offering n8n-based automation to customers as a service, or redistributing a modified build, does not. n8n is source-available, not OSI open source, so do not describe it to your board or auditors as open source without that qualifier. The n8n LICENSE file is the document to put in front of counsel.

Next, map your required features to editions. Files with .ee in their name or directory are outside the Sustainable Use License and need a valid n8n Enterprise License. Without a license key, n8n runs as the free Community edition. Single sign-on through SAML, environments with Git, log streaming and multi-main high availability are not in the Community edition. The pricing page places SSO, LDAP, Git environments and log streaming in the Business and Enterprise plans, and multi-main setup is restricted to Enterprise self-hosted deployments. If your security team requires SSO, audit trails from log streaming or a highly available main instance, price the Business or Enterprise edition into the plan from the start rather than retrofitting it after the rebuild.

Confirm three things in writing with n8n before you commit: which license applies to your intended use, which edition holds each feature your controls depend on, and whether the self-hosted Business plan terms match your procurement process. Ask counsel to review the license against any plan to share workflows with subsidiaries, contractors or customers, since those cases are where internal-use limits are most often misread. Record the answers in the migration plan so the decision is traceable later.

Common questions about moving from Make to n8n

How much effort does moving Make scenarios to n8n take?

Effort depends mostly on how many scenarios you have, how many modules each one uses, and how much custom logic (filters, iterators, aggregators, error handling) sits inside them. No researched figure is available for typical hours or weeks, so the best way to size the work is to export your blueprints and count modules per scenario. Simple linear scenarios that call common apps usually map quickly, while scenarios with nested routers, data stores or custom HTTP calls need more design and testing. Ask any implementer for a written estimate based on your actual blueprint inventory, and ask them to name the assumptions behind it.

Can our internal team migrate Make scenarios without outside help?

Yes, many teams do this in-house, provided someone understands both platforms and has time to test. The work requires people who can read blueprint JSON, rebuild logic in n8n nodes, recreate credentials, run test executions and document the result. Internal teams usually struggle with three things: scenarios with undocumented business rules, monitoring and alerting that must match what Make provided, and the operational work of running n8n itself, including updates and backups. If those gaps are visible in your inventory, a fixed-scope engagement with DeployOpen can cover the rebuild, testing and runbooks while your team keeps ownership.

What do we need to provide before a Make to n8n migration starts?

Prepare a complete inventory before any rebuild begins. For each scenario, export its blueprint, record the trigger, the apps involved, the schedule, the expected volume and the people who depend on its output. Identify the owners who can approve changes and confirm which systems must be reachable from the n8n runtime, including any on-premises endpoints. You will also need administrative access to the target n8n host, a place to store credentials securely, and a test environment that mirrors production data flows without sending live messages. Confirm these items in writing with any implementer so scope is clear.

Can Make scenarios be imported into n8n automatically?

Make exports a scenario as a blueprint .json file containing its modules, module settings and mapped values, according to Make's help center. Those blueprints are the starting point for planning the rebuild, but they are not a one-click import into n8n. Each Make module must be matched to an n8n node or an HTTP Request node, and mapped values must be re-expressed in n8n's expression syntax. Treat blueprints as a specification to read and map, and test each rebuilt workflow against the original outputs before switching traffic. Confirm with your implementer how they will verify parity.

Do connections and credentials carry over from Make to n8n?

No. Make's blueprint does not include connections, so every app connection must be recreated after import, according to Make's help center. In n8n, credentials are created in the n8n instance and stored in its database. If you run n8n in queue mode, the main instance's encryption key must be shared with all worker and webhook processor nodes so they can read those credentials, according to n8n's queue mode documentation. Plan a credential inventory, rotate secrets where policy requires it, and confirm who holds the encryption key and how it is backed up.

How does n8n's license affect a plan to replace Make?

n8n's main codebase is under the Sustainable Use License, which allows use or modification for your own internal business purposes or for non-commercial or personal use, according to its LICENSE.md. That covers running workflows inside your organization, but it does not permit offering n8n as a hosted service to others. Files with .ee in their name require a valid n8n Enterprise License. n8n is source-available, not OSI open source, so have your legal team review the terms against how you plan to use it. Ask whether your use case falls within the license before you commit.

Which n8n edition do we need to run migrated workflows?

Without a license key, n8n runs as the free Community edition, and adding a Business or Enterprise license key enables those editions, according to n8n's hosting documentation. Single sign-on through SAML, environments with Git, and log streaming are listed on n8n's pricing page as Business and Enterprise features, while multi-main high availability is restricted to Enterprise self-hosted deployments. Decide which of these you need before the rebuild, because the answer shapes the architecture. Confirm current plan contents directly with n8n, since pricing pages change.

What do we take on to run n8n after the migration?

Once n8n runs in your infrastructure, your team owns hosting, upgrades, backups, monitoring, secrets handling and access control. Recurring work includes applying n8n release updates, maintaining the database (typically PostgreSQL in queue mode), keeping Redis available for queue mode, and reviewing executions and failures. Ongoing costs come from infrastructure and the people who run it, and they continue after the migration ends. Ask any provider whether they offer ongoing support, upgrades or testing as a retainer, and what the written scope covers.

How DeployOpen scopes and runs a Make to n8n migration

DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For a Make to n8n move, we start from the scenarios you actually run, rebuild them in your own n8n environment, and hand over the workflows with the documentation your operations team needs.

How we scope

Inventory every Make scenario from exported blueprint files, noting modules, routers, iterators and aggregators in each one.
Classify scenarios by business owner, data sensitivity, schedule and whether they reach private or on-premises systems.
Agree the scope, deliverables and timeline in writing before work starts, since engagements are fixed-scope.

How we build

Map each Make module to an n8n node or a custom code step, and record every gap that needs a manual design decision.
Recreate connections and credentials in your n8n instance, because blueprints do not carry account authentication.
Test each rebuilt workflow against the original output with representative data before any scenario is switched over.

How we hand over

Document each workflow's purpose, trigger, inputs, outputs, credentials owner and the rollback steps for it.
Review the license position with you, including the Sustainable Use License terms and any files that require an n8n Enterprise License.
Walk your operations and integration teams through running, monitoring and changing the workflows after handover.

How we support

Scope ongoing support, upgrades and continuous testing as a retainer after the initial migration is complete.
Confirm with your team how n8n upgrades and release notes will be reviewed before each change is applied.
Agree in writing which parts of queue mode, backup and access control DeployOpen covers, and which stay with your team.