make.com naar n8n migreren.

Je hebt de knoop al doorgehakt. Deze pagina gaat niet over of je moet migreren, maar over wat er dan feitelijk gebeurt: wat overzet, wat je opnieuw bouwt, wat er kapot gaat op de dag van de omzetting, en wat je zelf kunt doen om de rekening te drukken.

Waarom teams van Make.com naar n8n migreren

Drie redenen, in deze volgorde.

Je betaalt per operatie. Elke module die afvuurt telt. Zodra een scenario over een lijst loopt, telt elke rij. Dat is prima bij honderd rijen per dag en pijnlijk bij tienduizend. Bij self-hosted n8n betaal je je server en verder niets, ongeacht hoe vaak een node draait.

Je wilt weten waar de data staat. Bij Make gaat elk item door hun infrastructuur. Voor sommige teams is dat een AVG-gesprek dat je niet wilt voeren, zeker als er persoonsgegevens of klantcontracten doorheen lopen. Self-hosted n8n draait op jouw server in jouw regio.

Je loopt tegen de rand van wat kan. Op het moment dat je in Make een module gaat misbruiken om iets te doen wat het platform niet bedoeld heeft, ben je toe aan een code-node. De redenering achter die keuze staat in waarom wij n8n gebruiken.

Wat een-op-een overzet en wat je opnieuw bouwt

Er bestaat geen importknop. De blueprint-JSON van Make is geen n8n-workflow, en converters die je online vindt produceren iets dat er ongeveer uitziet als je scenario en op de eerste uitzondering stukloopt. Wat je wel meeneemt is het denkwerk: de logica ligt vast, je hoeft alleen de vertaling te maken.

Gaat snel over. HTTP-aanroepen, veldmapping, filters, routers en scheduling. Een router met drie takken wordt een Switch-node. Een filter op een route wordt een IF. Een scenario dat elk uur draait wordt een Schedule Trigger. Dit is typewerk, geen ontwerpwerk.

Moet je opnieuw ontwerpen. Dit is het echte werk en het valt in drie stukken.

Ten eerste het datamodel. Make duwt bundels een voor een door je scenario. n8n geeft een node de hele set items tegelijk. Wie de Make-structuur letterlijk overneemt, wikkelt uit gewoonte een lus om alles heen en houdt een trage workflow over die twee keer zo veel nodes heeft als nodig. Iterators en aggregators verdwijnen vaak gewoon, omdat n8n dat gedrag standaard al doet.

Ten tweede de foutafhandeling. In Make hangt die aan een module: negeren, hervatten, terugdraaien. In n8n zit het op twee plekken, per node in de retry-instellingen en op workflowniveau in een error workflow. Dat is niet dezelfde knop met een andere naam, dus je moet per scenario opnieuw bepalen wat er moet gebeuren als stap zeven faalt terwijl een tot zes al weggeschreven zijn.

Ten derde alles wat Make voor je regelde. Data stores hebben geen equivalent, dus daar komt een echte database of een tabel voor terug. Voor apps waar Make een module heeft en n8n geen node, val je terug op de HTTP-node en schrijf je authenticatie en paginering zelf.

Wat er breekt bij een n8n migratie

Elke webhook-URL verandert. Alles wat nu naar Make wijst moet naar jouw instance gaan wijzen, per bronsysteem. Bij systemen die een externe partij beheert, is dat een aanvraag en een wachttijd, niet een instelling die je zelf omzet.

Geen enkele OAuth-koppeling verhuist mee. Verbindingen zijn niet exporteerbaar. Voor elk systeem heeft iemand met de juiste rechten opnieuw op akkoord moeten klikken. Dit is in de praktijk de grootste vertrager van een migratie, niet het bouwen.

Ratelimieten worden ineens jouw probleem. Make remde je impliciet af doordat alles per operatie liep. Een self-hosted n8n vuurt vrolijk door tot een API 429 teruggeeft. Retry met oplopende wachttijd moet je expliciet aanzetten.

Tijdzones. Een scenario dat om 07:00 draaide, draait na de overzetting op de tijdzone van je instance. Dat merk je pas als iemand belt dat het rapport een uur te laat is.

Dat opnieuw ontwerpen is niet alleen kostenpost. Bij Vergelijker.nl draait er elke ochtend een scraper langs alle grote internet- en tv-providers. Provider-sites zijn niet gebouwd om uitgelezen te worden, dus daar zit per provider een eigen fallback in plus een alert als een pagina niet meer laadt. Dat soort per-tak afhandeling bouw je in n8n zonder tegen het platform te vechten.

Hoe lang het duurt

Reken op de bouwtijd van hetzelfde aantal workflows vanaf nul. Een eenvoudige workflow met een of twee koppelingen is 2 tot 4 werkdagen. Een set van vijf tot tien scenario’s loopt over enkele weken, inclusief testen.

De volgorde die wij aanhouden: eerst het minst kritieke scenario, om te leren hoe jouw data zich in n8n gedraagt. Dan de rest, gerangschikt op hoeveel pijn het doet als het een dag stilligt. Beide omgevingen draaien een periode naast elkaar, en we zetten pas om als de n8n-kant dezelfde output produceert als Make op dezelfde input. Make blijft daarna nog een maand staan.

Zapier naar n8n migreren gaat net iets anders

Zapier-zaps zijn meestal korter en rechtlijniger, dus het overzetten zelf is sneller. Wat je terugkrijgt is meer dan je had: vertakking, lussen en code op plekken waar Zapier je dwong een tweede zap te maken. De valkuil zit in zaps die iemand ooit heeft opgesplitst omdat het anders niet paste. Die hoor je samen te voegen, niet een-op-een over te zetten. Wat je daarvoor terugkrijgt staat in waarom wij n8n gebruiken.

Wanneer je bij Make moet blijven

Als je team niet technisch is, je scenario’s onder de vijf stappen blijven en je geen server wilt beheren, is Make de goedkopere keuze en is migreren een dure hobby. Self-hosted betekent dat iemand die instance draait, bijwerkt en in de gaten houdt. Dat is werk. Beleg het of neem n8n cloud.

Wat je zelf kunt doen voordat je iemand belt

1. Exporteer elk scenario en tel hoeveel er de afgelopen maand daadwerkelijk hebben gedraaid. Bij vrijwel elke migratie blijkt een deel al maanden dood en dat zet je dus niet over.
2. Schrijf per scenario op welke systemen erin zitten en wie in jouw organisatie de beheerrechten heeft. Dat lijstje bepaalt je doorlooptijd.
3. Noteer welke webhook-URL’s door een externe partij beheerd worden en zet die aanvraag alvast in gang.
4. Beslis self-hosted of n8n cloud, en als het self-hosted wordt: wie draait de upgrades.

Met die vier dingen op tafel is het eerste gesprek een half uur in plaats van drie. Meer over hoe wij bouwen staat op de pagina over n8n consulting, en hoe zo’n pipeline er in productie uitziet lees je in de Capptions-case, waar n8n, Claude, Apollo en HubSpot samen een handmatige stap van 25 tot 40 minuten per lead hebben teruggebracht naar seconden.