Does anyone have experience migrating from n8n to make? Was it easy? What was it like migrating with a lot of credentials?
1 Like
Hi Topher,
There is no direct n8n-to-Make migration, so the workflows have to be rebuilt and validated manually. The actual difficulty depends on:
-
The number and size of the workflows.
-
Whether they use standard nodes, custom code, or community nodes.
-
The number and type of unique credentials that must be reauthorized in Make.
-
Webhooks, sub-workflows, data stores, and persistent state.
-
Branching, loops, data transformations, and batch processing.
-
Error handling, retries, deduplication, and idempotency requirements.
-
Execution volume, since the same workflow may consume operations differently in Make.
A simple linear workflow can be straightforward, while workflows with custom code, multiple branches, state, and error recovery may require architectural changes rather than a one-to-one rebuild.
The safest first step would be to review one representative workflow and create a migration map before estimating the complete migration. Approximately how many active workflows do you have?
1 Like
Well, if there is no clean way that really stinks. I have not counted, but I believe around 50 or so. Looks like I should get to work. Thank you so much for your reply.
You’re welcome. Out of curiosity, what is driving the move from n8n to Make—maintenance, reliability, cost, or a specific limitation?
With around 50 workflows, the reason matters. It may be easier to solve the underlying problem than rebuild everything.
Topher — with approximately 50 workflows, I would not start by promising a blind rebuild. I can take a fixed USD 350 migration-map pass, delivered asynchronously in three business days after protected payment and one sanitized representative export.
I will:
- map the representative n8n workflow to Make modules;
- flag custom/community nodes, credential types (never secrets), webhooks, sub-workflows, data stores, state, retries, deduplication and operation-volume risks;
- return a sequencing plan for the wider inventory, a go/no-go note and the smallest safe pilot with objective acceptance checks.
This first unit does not rebuild 50 workflows, move credentials, access production or handle customer data. It is a proposed first-unit format, not a claim of prior n8n-to-Make client work. RomeoApps’ reliability proof is here: Build-to-Proof Software Sprints | RomeoApps
If useful, reply with the rough workflow mix and whether you can provide a redacted export.
Hello,
It’s easy – as long as you know what you’re doing and why you’re doing it.
If the underlying process is well documented, it genuinely doesn’t matter whether it’s N8N or Make.
The real trouble spot, from my experience, is webhooks and access to external tools and services.
You need access to every single tool that triggers your workflows in order to update them there too. And every single one that is triggered via workflow.
Doing this for yourself, that’s a non-issue but definitely time consuming.
Doing it for a company or a client, expect multiple access requests along the way.
So to keep the process smooth, map out what you’re actually dealing with beforehand – it saves headaches later.
Have a nice day,
Michal
Hi Topher,
With around 50 workflows, I’d recommend doing a proper migration assessment before rebuilding everything.
The main thing is that it won’t necessarily be a one-to-one conversion. Workflows using webhooks, branching, data transformations, credentials, error handling, loops or persistent state may need some restructuring in Make.
I’d start with 1–2 representative workflows, map the existing n8n logic to Make, and use that to estimate the wider migration accurately.
If you’d like, I’d be happy to take a look at one of the workflows and give you my thoughts on the migration approach.
Topher, with roughly 50 workflows, the quickest useful step is an inventory before rebuilding anything. That should separate workflows that are simple module-for-module moves from the ones that depend on custom code, webhooks, state, sub-workflows, or credentials that must be reauthorized. It may also show that only a small group should move.
TinyOps Studio can deliver a fixed $49 written migration triage within one business day after receiving a workflow-name list and one sanitized representative export. The result will classify the workflows as keep, migrate, or redesign; flag credential and state risks; note likely Make operation-cost pressure; and recommend the smallest pilot plus migration order.
No production access or credentials are needed. If that would save you time, can you export the workflow list and one representative JSON with secrets and customer data removed?
Hi Topher, is the move from n8n to Make still on your list? With around 50 workflows, I’d first map one representative workflow, its credential owners and any custom code before estimating a migration. I work on n8n/API systems and can scope a paid review to help decide what should move. What is driving the switch?