Migrera 150 Make-scenarion till n8n - vad vi lärde oss

Make är ett av de snabbaste sätten att bygga integrationer. Det är också ett av de snabbaste sätten att få en oförutsägbar månadsnota när antalet flöden växer. Den här texten beskriver en migration vi gjorde av cirka 150 produktionsflöden från Make till self-hosted n8n - utan att tappa ett enda affärskritiskt flöde.

Varför migrera alls?

Triggern var sällan ideologisk. Den var ekonomisk och operationell. Make prissätter per "operation" - varje steg i ett scenario räknas. Ett bolag med många flöden som körs ofta såg notan passera 40 000 kr i månaden, med en tillväxtkurva som pekade brant uppåt. Samtidigt hade flera scenarier blivit så komplexa att de var svåra att felsöka i Makes visuella editor.

n8n löser båda problemen: self-hosted innebär att kostnaden blir infrastruktur (en container som kostar några hundralappar i månaden) i stället för per-operation, och kod-steg gör komplex logik läsbar igen. Men en migration är aldrig gratis - och den som påstår att det är "bara att flytta" har inte gjort det.

Steg 1: Inventera och klassificera

Vi började inte med att migrera. Vi började med att förstå vad som faktiskt körde. 150 scenarion lät mycket, men efter inventering visade det sig att:

• Cirka 30 flöden stod för 80 % av operationsvolymen - de var de dyra.
• Ett 40-tal flöden hade inte körts på över 90 dagar - kandidater för att helt enkelt tas bort.
• Resten var lågfrekventa men affärsviktiga (t.ex. månadsrapporter).

Lärdomen: migrera inte allt. Den billigaste migrationen är den du slipper göra. Vi avvecklade 40 flöden direkt och prioriterade de 30 dyra först - där låg hela ROI:n.

Steg 2: Bygg om, kopiera inte

Det är frestande att försöka återskapa varje Make-scenario nod för nod i n8n. Motstå det. Make och n8n har olika primitiver, och en blind översättning ger flöden som är svårare att underhålla än originalet. Vi byggde om de komplexa flödena utifrån vad de skulle åstadkomma, inte hur de råkade vara byggda.

Konkret exempel: ett Make-scenario med tolv router-grenar för olika kundtyper blev i n8n ett enda kod-steg med en lookup-tabell. Tolv grenar att underhålla blev ett.

Steg 3: Felhantering är inte valfritt

Den vanligaste skillnaden mellan en hobby-automation och en produktionsautomation är felhantering. I produktion måste varje flöde svara på tre frågor:

• Vad händer om ett anrop misslyckas? (retries med exponential backoff)
• Hur vet vi att det misslyckades? (alerting till rätt kanal, inte tyst)
• Hur kör vi om utan dubbletter? (idempotens via en nyckel)

n8n:s error-workflows och möjligheten att skriva egna retry-villkor i kod gjorde detta enklare än i Make, men det kräver disciplin att bygga in det i varje flöde från start.

Steg 4: Drift, secrets och versionshantering

Self-hosted betyder att ni äger driften. Det är poängen - och priset. Vi körde n8n i en container på Kubernetes med:

• Secrets i en separat secrets-manager, inte i flödena.
• Workflows exporterade som JSON och versionerade i git - så att en felaktig ändring kan rullas tillbaka.
• Monitoring på både container-hälsa och flödes-utfall.

Var låg break-even?

För det här bolaget betalade migrationen sig på under fyra månader: licensbesparingen ensam täckte konsultinsatsen, och därefter var det ren besparing plus en stack som teamet faktiskt kunde felsöka. Tumregeln vi tagit med oss: under ~3 000 kr/månad i Make-kostnad är en migration sällan värd besväret. Över det - och med en uppåtgående volymkurva - blir n8n snabbt rätt val.

Skulle vi gjort något annorlunda?

Ja: börjat med observability. Vi spenderade onödig tid på att felsöka tysta fel under övergången eftersom monitoringen kom på plats för sent. Bygg mätningen först, migrera sen.