Migration
Make.com to n8n migration service
Make meters you by the operation, so the scenarios that became most useful are usually the ones costing most to run. Getting them out is a rebuild rather than an export: modules, routers, iterators, error handlers and data stores each have to be re-expressed in a different execution model, then proved against live traffic before anything is switched off.
The mapping
What a scenario becomes on the other side
The two platforms disagree about the most basic thing: what a step receives. A Make module fires once per bundle, so a scenario is written as a chain of single-record operations with iterators and aggregators bolted on to change shape. An n8n node runs once over an array of items. Almost every difference below follows from that one fact.
Reading the blueprint export is the fastest way to see what you actually have. It lists every module, every filter condition and every mapped field without anyone clicking through the editor — which reliably surfaces the router branch nobody remembers adding, the fallback route that has never once fired, and the two scenarios that are the same scenario with one field changed.
What does not survive contact with the blueprint is Make's error model. Directives are attached per module — break, resume, rollback, ignore, commit — and there is no node in n8n that means any of those things. Each one becomes an explicit choice about a specific failure: route the item down an error output, retry it, park it with its context for a person, or let a dedicated error workflow catch the run. That is more work than a translation, and it is the part of the move worth paying for, because the answers were never written down on the Make side either.
| In Make today | What it is doing | Where it lands in n8n |
|---|---|---|
| Scenario | One trigger and its chain of modules, versioned as a blueprint | A workflow, exported as n8n's own JSON — a different format, so the blueprint informs the rebuild rather than seeding it |
| Module and bundle | One app operation, executed once per bundle passing through | A node, executed once over the whole item array — the per-record loop stops being something you build |
| Router and filters | Branches evaluated in order, with a fallback route at the end | IF or Switch nodes for the branching, a Merge node wherever branches have to rejoin |
| Iterator and aggregator | Splitting one bundle into many, then folding many back into one | Usually nothing at all: items are already plural. A loop node only where a real sequential loop is needed; an aggregate or Code node where a list must become one payload |
| Error handler directives | Break, resume, rollback, ignore or commit, attached per module | No equivalent: a per-node error output plus a dedicated error workflow, decided failure by failure |
| Data store | Platform-hosted tables holding dedup keys, lookups and state between runs | No equivalent and no import path — re-homed to a database or base you own, or to workflow state where it is genuinely small |
| Connection | A stored authorisation to act inside a CRM, mailbox or ledger | A credential, re-authorised at least privilege rather than exported |
| Operations | Consumed per module call, so cost scales with steps and fan-out | Counted per execution on n8n's cloud; not metered at all when self-hosted |
Read both models before deciding. How items flow between nodes is set out in the n8n data documentation (opens in new window), and what counts as a consumed operation is defined in Make's own help pages (opens in new window). Credentials are the part of a migration that deserves the most care — every connection is re-issued, which is an opportunity to scope it properly and to give it an owner who is not somebody's personal account. We handle that side against the NIST Cybersecurity Framework (opens in new window).
The trigger
Why the operation count is usually what starts this
Teams rarely leave because the builder is bad. They leave because the meter runs on module calls, and the scenarios that grew most valuable are the ones that fan out: an iterator turning one order into forty line items, a search module doing a lookup that a stored id would have answered, a polling trigger checking every fifteen minutes whether anything happened. None of that is waste in the sense of being pointless — it is just billed per call, and the bill climbs with the business rather than with the value of the automation.
The honest version of the saving is a trade, not a discount. On n8n's cloud a run counts once no matter how many nodes it touches, which usually flatters a fan-out scenario dramatically. Self-hosting removes the meter altogether and hands you upgrades, backups, monitoring and uptime in exchange. That is a good trade for a team with somewhere to run it and a bad one for a team without, and it is worth settling before the rebuild rather than during it.
There is a second reason worth naming, because it decides more migrations than cost does among the teams we talk to: a scenario that quietly stops halfway has no good answer in Make unless somebody chose the right directive in advance, and almost nobody did. Rebuilding forces that conversation for every branch that touches a third-party API.
Sequence
How the move runs, stage by stage
Blueprint inventory
Every scenario exported and read: modules, filters, mapped fields, owner, last run, operations consumed. Duplicates get consolidated and dead scenarios get retired, because paying to rebuild waste is still paying for waste.
Rebuild in the item model
Each surviving scenario rebuilt as a workflow rather than transliterated — iterators dropped where items already handle it, routers expressed as branches that merge, and every error path made explicit.
Parallel run
Both versions fire on the same real triggers with the new workflow's write steps disabled, until the outputs agree. Where they disagree is where the undocumented logic was hiding.
Cutover, one scenario at a time
Cutover happens per scenario, never as one event. The workflow takes the trigger, the scenario is switched off but kept, and the Make organisation stays on its plan through a quiet period before anything is deleted or downgraded. Cancelling early is the only irreversible step in the project, and it saves a fraction of what an unplanned rollback costs.
You finish owning the result outright: workflows exported as JSON, credentials issued in your own accounts, data stores re-homed somewhere you can query, and a runbook naming what each error path means and who gets alerted. If your team would rather run the rebuild themselves, we will set up the instance and the conventions and stay on as backup.
Where this sits next to the rest of the work
Leaving is not the only option, and it is not always the right one. If the scenarios are sound and the bill is tolerable, hardening what you have is cheaper — that is what Make.com consulting covers, including the error handlers and operation economics that make a scenario survivable without moving it anywhere. If the destination is still an open question, n8n vs Zapier vs Make argues it on hosting, pricing unit and flexibility rather than on feature lists.
Once you have landed, an n8n workflow automation consultant covers the build, repair and hosting decisions that follow. If the platform you are leaving is Zapier rather than Make, the Zapier to n8n migration route is a different enough problem — linear Zaps, task-based billing, no data stores — to be worth reading on its own page. And if what you are actually moving is the CRM underneath, the HubSpot to GoHighLevel migration page deals with a different class of problem again: object models and record history rather than scenarios and operations.
Questions
Common questions about leaving Make
Can a Make blueprint be converted into an n8n workflow automatically?
Not reliably. A blueprint is Make's own JSON, describing Make modules and Make's bundle model; n8n workflow JSON describes different nodes over a different execution model. The blueprint is genuinely useful as an inventory artifact — it tells you every module, every filter condition and every mapped field without clicking through the editor — but it is something we read, not something we import.
What happens to the data stores our scenarios read and write?
They get re-homed, because there is no export-import path for them. Each data store is examined for what it is really doing: deduplication keys, a lookup table, or state carried between runs. Deduplication and state usually move into the destination system or the workflow itself, and a lookup table becomes a table in a database or base you already own.
Our scenarios use routers and iterators heavily. Does that translate?
Routers translate directly; iterators often disappear. A router with filters becomes an IF or Switch node, with a Merge node where the branches rejoin. Iterators mostly have no counterpart because n8n nodes already run once over an array of items, so the fan-out an iterator exists to create is the default behaviour rather than a step you add.
Will moving to n8n actually cut what we spend on automation?
Often, but it is a trade rather than a free saving. Make meters operations per module call, so a scenario that fans one bundle into hundreds of calls is expensive by design. n8n bills a run as one execution on its cloud, and self-hosting removes that meter entirely — in exchange for upgrades, backups and uptime becoming your responsibility.
Free consultation
Tell us what is costing you the most time
Describe the process. You get a straight read on whether it is worth automating, roughly what it would take, and what we would tackle first — on a call that costs nothing.
- Under an hour, free, and no obligation
- Fixed price per stage, agreed before any work starts
- You own everything we build, documented and in your accounts
- If you do not need us, we will say so on that call
The form is the fastest way to reach us — we reply from a real person, usually within one business day.
Not sure which migration is right? See the CRM migration services overview.