Migracja z Make do n8n: jak przenoszę scenariusze bez przestoju
Scenariusze w Make działają, ale rachunek za operacje rośnie, a część logiki i tak siedzi w funkcjach upchniętych w polach. Wtedy pojawia się pytanie o n8n. Opisuję, kiedy przeniesienie ma sens i jak przebiega.
Autor: Szymon Łakomy. Aktualizacja:
Trzy powody, dla których firmy przechodzą
Koszt przy wolumenie
Make liczy każdy moduł, który przetworzy pakiet danych. Scenariusz z iteratorem po pozycjach zamówienia zużywa jednostki proporcjonalnie do liczby pozycji. W n8n na własnym serwerze ta zależność znika, zostaje koszt serwera.
Dane na własnym serwerze
Dane klientów i faktur przechodzą przez infrastrukturę, którą wybiera firma. To częsty argument przy danych osobowych, choć sama zmiana narzędzia nie zastępuje analizy RODO. To nie jest porada prawna.
Logika, która potrzebuje kodu
Gdy scenariusz ma kilkanaście funkcji w polach, parsowanie tekstu i obejścia przez magazyn danych, w n8n zastępuje je jeden węzeł Code z czytelnym JavaScriptem.
Jak tłumaczę moduły Make na węzły n8n
| W Make | W n8n | Na co uważam |
|---|---|---|
| Router z filtrami | Switch albo If | trasę zapasową (fallback) odtwarzam jako wyjście domyślne Switcha |
| Iterator | zwykle nic, bo węzły przetwarzają każdy element osobno; przy tablicach Split Out | pola, które w Make były tablicą w jednym pakiecie |
| Agregator tablicowy lub tekstowy | Aggregate albo Code | grupowanie, które w Make ustawia się w polu Group by |
| Magazyn danych (data store) | tabela danych n8n albo baza Postgres | przeniesienie istniejących rekordów przed przełączeniem |
| Webhook niestandardowy | Webhook | nowy adres trzeba wpisać w systemie wysyłającym |
| Moduł HTTP | HTTP Request | klucze przenoszę do poświadczeń n8n |
| Funkcje w polach | wyrażenia n8n albo Code | inna składnia dat i formatowania liczb |
Make pozwala wyeksportować scenariusz jako blueprint w JSON. n8n go nie zaimportuje, ale plik jest dobrą specyfikacją: widać w nim każdy moduł, mapowania i filtry.
Obsługa błędów działa inaczej
W Make błędy łapie się dyrektywami przy module: Ignore, Resume, Rollback, Commit i Break, a nieukończone wykonania można przejrzeć i dokończyć. W n8n każdy węzeł ma ustawienie On Error: zatrzymanie przepływu, kontynuację albo osobne wyjście błędu, które prowadzę do własnej gałęzi. Cały przepływ ma do tego przypisany Error Workflow, który wysyła alert z nazwą węzła i linkiem do wykonania.
Odpowiednik dyrektywy Break, czyli ponowienie po czasie, ustawiam jako Retry On Fail z przerwą między próbami. Wykonanie zakończone błędem można w n8n ponowić z listy wykonań, na danych z pierwotnego wejścia.
Kolejność prac i testy
- Spis scenariuszy z liczbą operacji z ostatnich miesięcy i oznaczeniem, które są krytyczne dla firmy.
- Serwer n8n z kopiami zapasowymi i domeną dla webhooków, jeśli firma jeszcze go nie ma.
- Odbudowa od scenariuszy najdroższych w operacjach, bo tam migracja zwraca się najszybciej.
- Testy na danych z historii wykonań w Make: te same wejścia muszą dać te same wyniki.
- Krótka praca równoległa, w której n8n zapisuje wyniki w arkuszu zamiast w systemach docelowych.
- Przełączenie webhooków i harmonogramów, wyłączenie scenariuszy w Make, a po okresie obserwacji eksport blueprintów jako archiwum.
Serwer pod n8n i jego utrzymanie opisuję na stronie hosting n8n, a koszty całego wdrożenia w tekście ile kosztuje wdrożenie n8n.
Kiedy zostać na Make
Nie każdy scenariusz warto ruszać. Zostawiam Make, gdy scenariuszy jest kilka, mieszczą się w planie, a osoby w firmie same je edytują i dobrze znają ten edytor. Także wtedy, gdy kluczowe są moduły aplikacji, których n8n nie ma, a odtworzenie ich przez API kosztowałoby więcej niż abonament przez długi czas.
Czym jest Make i jak liczy zużycie, wyjaśniam w tekście co to jest Make.com. Porównanie trzech narzędzi zostaje na stronie Make, n8n czy Zapier, a usługę budowy przepływów opisuję na stronie automatyzacja w n8n i Make.
Najczęstsze pytania
Czy w trakcie migracji scenariusze w Make muszą być wyłączone?
Nie. Do momentu przełączenia działają normalnie. Wyłączam je pojedynczo, dopiero gdy odpowiednik w n8n przejdzie testy i okres równoległy, więc firma nie ma przerwy w działaniu.
Co z rekordami zapisanymi w magazynach danych Make?
Odczytuję je scenariuszem lub przez API Make i wczytuję do tabeli danych n8n albo bazy. Gdy scenariusz w Make nadal dopisuje rekordy, robię drugi, końcowy odczyt tuż przed wyłączeniem.
Czy po migracji rachunek zawsze spadnie?
Nie zawsze. Przy małym ruchu abonament Make bywa tańszy niż serwer i jego utrzymanie. Przed wyceną porównuję zużycie z historii z kosztem serwera i opieki, a gdy różnica jest niewielka, odradzam migrację.
Czy mogę przenieść tylko część scenariuszy?
Tak i często tak robię. Najdroższe lub najbardziej złożone scenariusze przechodzą do n8n, a proste, edytowane przez zespół, zostają w Make. Dane między narzędziami wymieniają webhooki.
Powiązane strony
Planujesz przejście z Make na n8n?
Wyślij listę scenariuszy z liczbą operacji z ostatniego miesiąca. Policzę, czy migracja się opłaca.