Vi hade 153 aktiva automationsflöden i Make (tidigare Integromat). De hanterade allt från CRM-synkronisering till Slack-notiser, datapipeline-triggers och rapportgenerering. Att migrera allt till n8n var ett av de största infrastrukturprojekten vi genomfört - och ett av de mest värdefulla.
01Varför byta från Make?
Make är ett utmärkt verktyg för de flesta. Vi valde det 2023 och det fungerade bra i början. Men när våra automationsbehov växte började vi stöta på begränsningar som blev allt mer problematiska. De tre huvudsakliga anledningarna till bytet var kostnad, kontroll och kodbarhet.
Kostnad: $890/månad och stigande
Med 153 flöden och högvolymintegration (CRM-synk, datapipelines) betalade vi $890/månad för Makes Teams-plan. Varje gång vi la till ett nytt flöde ökade kostnaden. Med n8n self-hosted (på en $40/månad VM) betalar vi en fast kostnad oavsett antal flöden eller exekveringar.
Kontroll: Black box med vendor lock-in
Makes infrastruktur är helt stängd. Vi kunde inte själva övervaka vad som hände inuti flödena, debugging var begränsat till deras UI, och vid driftstörningar (som hände 3 gånger under 2025) hade vi noll insyn och noll kontroll. Vår data passerade Makes servrar i EU, men vi hade ingen garanti för exakt var.
Kodbarhet: Visuella flöden skalar inte
För enkla flöden är Makes visuella editor utmärkt. Men för komplexa flöden med villkor, loopar, error handling och dynamisk data blir det snabbt oöverskådligt. Vi hade flöden med 40+ steg där det var nästan omöjligt att förstå logiken utan att klicka igenom varje steg manuellt.
02Make vs n8n: Jämförelse
Innan vi bestämde oss utvärderade vi tre alternativ: n8n, Temporal och en hemmabyggd lösning med Cloud Functions. n8n vann på grund av kombinationen av visuell editor (för enklare flöden), fullständig kod-tillgång (för komplexa flöden), och self-hosting-möjlighet.
Make: CRM-synk flöde
03Migrationsplan
Med 153 aktiva flöden kunde vi inte göra en big-bang-migration. Istället använde vi en fasad strategi där vi migrerade flöden gruppvis, med både Make och n8n körandes parallellt under 6 veckor. Nyckelregeln var: noll driftavbrott för affärsprocesserna.
Vecka 1-2: Setup och pilot
12 flödenInstallerade n8n på en dedicated VM (Ubuntu, Docker). Migrerade 12 enkla notifikationsflöden (Slack-alerts, email-triggers). Validerade att n8n kunde hantera vår last.
Vecka 3-4: Kärnflöden
48 flödenMigrerade CRM-synk, datapipeline-triggers och rapportgenerering. Dessa körde parallellt i både Make och n8n i 48 timmar för att verifiera att resultaten var identiska.
Vecka 5: Komplexa flöden
53 flödenMigrerade de mest komplexa flödena - de med 20+ steg, branching-logik och externa API-beroenden. Många av dessa skrevs om från grunden i n8n:s code nodes istället för att replikeras visuellt.
Vecka 6: Long tail + avslut
40 flödenMigrerade resterande flöden, de flesta enkla cron-baserade jobb. Stängde ner Make-kontot efter 7 dagars parallellkörning som säkerhetsnät.
Den mest kritiska insikten var att inte försöka replikera Make-flödena exakt i n8n. Istället analyserade vi vad varje flöde faktiskt gjorde och implementerade det på det mest idiomatiska sättet för n8n. I många fall innebar det att 5 visuella steg i Make blev 1 code node i n8n - enklare, snabbare och lättare att underhålla.
04Utmaningar
Migrationen var inte smärtfri. Här är de största utmaningarna vi stötte på och hur vi löste dem:
Saknade integrationer
Make har 1500+ integrationer. n8n har ~400. Vi använde 8 Make-integrationer som inte fanns i n8n: bland annat legacy-CRM, Fortnox och en specialiserad SMS-gateway.
För varje saknad integration byggde vi en custom n8n node eller använde HTTP Request-noden med API-nycklar. n8n:s HTTP-nod är extremt flexibel och kan replikera vilken REST API-integration som helst.
Data transformation-skillnader
Make och n8n hanterar data-transformationer helt olika. Make använder en visuell mapper med formler, n8n använder JavaScript expressions. Konverteringen var tidskrävande.
Vi byggde en cheat sheet som mappade de 30 vanligaste Make-formlerna till n8n JavaScript-ekvivalenter. Teamet använde detta som referens under hela migrationen.
Webhook URL-byten
42 av våra flöden triggades av webhooks från externa system. Varje webhook hade en unik Make-URL som nu behövde bytas till en n8n-URL. Att missa en enda innebar ett tappt flöde.
Vi skapade en inventering av alla webhook-URLer och deras källsystem. Sedan använde vi en DNS-baserad approach: vi pekade om webhook.example.com från Make till n8n, så att externa system inte behövde ändras.
Felhantering och retries
Make har inbyggd automatisk retry för misslyckade steg, men logiken är dold. I n8n måste du explicit konfigurera retry-beteende per nod.
Vi skapade standardmallar för error handling som inkluderade retry med exponential backoff, dead letter queue (vi använder en Supabase-tabell), och Slack-notiser vid permanenta misslyckanden.
05Resultat
Migrationen slutfördes på 42 kalenderdagar med 3 missade exekveringar (alla fångade inom 30 minuter tack vare parallellkörning). Här är de konkreta resultaten:
“Den största vinsten var inte kostnadsbesparingen - även om $10 000 per år är trevligt. Den största vinsten var kontroll. Vi äger nu hela vår automationsinfrastruktur. Vi kan se exakt vad som händer, debugga i realtid, och göra ändringar utan att vara beroende av en extern tjänsts uptime.”
- Simon Axelsson
06Rekommendation
Ska du byta från Make till n8n? Det beror på. Här är vår ärliga rekommendation baserat på vår erfarenhet:
Byt till n8n om:
- •Du har 50+ flöden och kostnaderna växer
- •Du vill/kan self-hosta (eller använda n8n Cloud)
- •Ditt team kan skriva JavaScript
- •Du behöver versionshantering för flöden
- •Du har compliance-krav på datasuveränitet
Stanna på Make om:
- •Du har under 30 enkla flöden
- •Ditt team är icke-tekniskt (no-code först)
- •Du är beroende av specifika Make-integrationer
- •Du inte vill/kan underhålla en server
- •Nuvarande kostnad är acceptabel
För oss var bytet en no-brainer. Men vi hade också det tekniska teamet och infrastrukturen för att göra det. Om du är ett litet team utan DevOps-kapacitet kan Make fortfarande vara det rätta valet. Det finns inget fel med att betala för bekvämlighet - så länge du är medveten om kostnaderna och trade-offs.
Simon Axelsson
IT-konsult & teknisk rådgivare
Simon Axelsson är senior IT-konsult och grundare av SIAX Technology AB i Stockholm. Han hjälper nordiska företag med molninfrastruktur, dataplattformar och AI-automation. Med över 150 aktiva n8n-workflows i kundprojekt har han djup erfarenhet av att bygga och underhålla automationslösningar i stor skala.