I’m looking for someone who can transfer flows from Make.com to N8N. If you have experience with this, or suggestions to improve the workflow during the transfer, I’d appreciate any advice or recommendations.
The workflow is ready—I’m done working with Make.com and want to move everything over to N8N.
I’m looking for someone with experience in automation who can assist. I will review the workflow I have at the moment to make sure you’re comfortable with it before we start. Please let me know if you have experience with this and how many workflows you’ve migrated or built before.
I’ve helped multiple clients move from Make.com to n8n — including full migrations of multi-scenario setups with custom APIs, routers, conditional logic, and webhooks. The key to a smooth transition is understanding where Make’s built-in simplicity needs to be manually replicated in n8n, and how to make the most of n8n’s flexibility (like custom JS, subworkflows, and error branches).
I typically start with a workflow audit, mapping out all scenario structures, webhook dependencies, and app connections. During migration, I’ll refactor the flows to improve performance and add retry/error handling where Make.com fell short
Hi, Omar
How are you today?
As a AI automation engineer with n8n, make.com, zapier and CRM etc… I can help you
Look forward to discuss with you in more detail via call
My Email: [email protected]
Best
Will
I’ve worked extensively with both Make.com and n8n, and I’ve successfully migrated several production-grade workflows between the two platforms including custom API calls, error handling, data mapping, and webhook logic.
I’d be happy to review your current Make.com setup and offer suggestions to optimize or simplify it during the transition to n8n. In past projects, I’ve also restructured flows to better leverage n8n’s native flexibility and node-based logic.
Let me know a good time to connect. I can walk you through the migration approach and share examples of similar work I’ve done.
I’ve migrated multiple workflows from Make.com to n8n, handling everything from basic webhook-driven automations to more complex API integrations with error handling, custom JS, and parallel processing. Happy to review your existing flows first and advise on any improvements we can make during the transition to n8n — often we find ways to optimize execution speed and simplify the structure.
Hi Omar – migrating from Make.com to n8n is a smart move if you want more flexibility and self-hosting options.
Here’s a simple migration playbook I’ve used:
Inventory & Mapping – export a list of all Make.com scenarios, note triggers, actions, and any custom logic. Create a one-to-one spreadsheet mapping to n8n nodes so nothing is missed.
Credential Abstraction – set up all API keys and OAuth credentials in n8n’s credential store first; this lets you reuse them across multiple flows and rotate them easily.
Modular Rebuild – rebuild each scenario as a separate sub-workflow in n8n, then use the Execute Workflow node to stitch them into larger processes. This keeps things testable and avoids one huge flow.
Logging & Error Handling – add a simple logging sub-workflow that catches errors and pushes them to Slack/email so issues surface quickly during the transition phase.
Parallel Run & Cutover – run Make.com and n8n in parallel for a short period, compare outputs, then switch DNS/webhooks once you’re confident results match.
Questions to scope effort:
• Approximately how many active scenarios are we migrating, and do any rely on custom code modules?
• Do you need on-prem/self-hosted n8n, or is Cloud acceptable?
Best-practice tips:
• Use environment variables for any sensitive values that appear in multiple nodes – it’s more maintainable.
• Version control your workflows with n8n’s CLI export so you have rollback points during the migration.
This is general guidance based on similar platform migrations I’ve handled – hope it helps clarify the path forward!ren’t
Migrating scenarios from Make.com to n8n usually breaks down into three passes:
Mapping triggers and data structures – identify every incoming webhook or scheduled run and recreate them in n8n, making sure field names stay consistent.
Normalising data – use n8n’s Set or Function nodes to keep payloads identical so downstream steps work the same.
Action rebuild & testing – rebuild each action step-by-step, run sample executions, and log any edge cases.
To keep the move smooth I’d suggest exporting one representative scenario first, rebuilding it in n8n and running it side by side for a day. That surfaces hidden dependencies (rate limits, retries, Make-specific modules) before you invest time in the rest.
A few questions that help scope the effort:
• How many total scenarios and total steps per scenario are you migrating?
• Are any custom apps/modules involved that don’t have direct equivalents in n8n?
• Do you need version control or CI/CD around the finished workflows?
Practical tip: n8n’s HTTP Request node combined with Expressions can replace several specialised Make modules in one place, which keeps the node count low and performance high.
This is general guidance based on my experience with similar projects.
I work with n8n extensively and can help map over your existing flows cleanly.
Happy to review what you have and suggest better ways to structure it if needed.
Moving scenarios from Make to n8n usually follows a proven three-phase approach:
Inventory and mapping: Export each Make scenario to JSON and list its triggers, actions, and custom webhooks. In n8n, create a matching workspace folder so you can migrate piece by piece rather than all at once.
Node-by-node rebuild: For every Make module choose its n8n equivalent. Common pairs are HTTP module → HTTP Request node, Iterator → SplitInBatches, and Router → IF node. When a direct node does not exist, an HTTP Request with credentials often covers the gap.
Validation and observability: Enable Execution data save and add an Error Trigger node that posts a Slack or email alert when any execution fails. This catches discrepancies early.
Practical tips:
• Use the Import from Curl option when rebuilding any HTTP modules to speed things up.
• Group credentials in one Credentials folder so they can be updated centrally if endpoints change.
• Start each workflow with a small test data set and run it in manual mode so you can step through every node.
A couple of scope questions:
• Approximately how many active scenarios do you plan to migrate?
• Are there rate-limited APIs involved that might need queue or retry logic?
This is general guidance based on my experience with similar projects.