Migracja z Make i Zapiera do n8n: jak przenieść scenariusze bez wywracania firmy

Porównań Make, Zapiera i n8n jest w internecie tyle, że mogłyby wypełnić osobną bibliotekę. Opisów samej migracji prawie nie ma, a to ona rozstrzyga, czy zmiana narzędzia skończy się niższym rachunkiem, czy dwoma tygodniami gaszenia pożarów w procesach, które wcześniej działały.

Przenosiliśmy takie zestawy kilka razy: od czterech scenariuszy w małej firmie usługowej po kilkadziesiąt automatyzacji spiętych z CRM-em, księgowością i sklepem. Za każdym razem najtrudniejszy był ten sam moment: pierwszy tydzień, w którym stara i nowa automatyzacja działają jednocześnie.

TL;DR: Konwertera z Make ani Zapiera do n8n nie ma, scenariusze przepisujesz ręcznie. Zacznij od inwentaryzacji, bo spora część automatyzacji okazuje się martwa albo zdublowana. Migruj po jednym, z okresem równoległym i zabezpieczeniem przed podwójnym wykonaniem. Credentiale zakładasz od nowa. Zwraca się przy dużym wolumenie operacji albo wymogach na dane, nie przy pięciu prostych zapach.

Kiedy migracja ma sens, a kiedy jest stratą czasu

Sytuacje, w których zwraca się dość szybko:

• Rachunek rośnie razem z wolumenem. Make liczy operacje, Zapier zadania. Scenariusz przetwarzający kilkaset zamówień dziennie zżera pakiet w tempie, którego nie da się optymalizować w nieskończoność. n8n self-hosted nie liczy niczego poza możliwościami Twojego serwera.
• Uderzasz w limity, nie w cenę. Limit kroków w scenariuszu, czas wykonania, rozmiar payloadu, brak dostępu do plików. Przy prostych integracjach nie zauważysz tego nigdy, przy przetwarzaniu dokumentów zauważysz w pierwszym tygodniu.
• Dane są wrażliwe. Na własnej instancji treść przetwarzanych wiadomości nie opuszcza Twojego serwera, a rejestr czynności przetwarzania robi się krótszy (n8n i RODO).
• Logika przerasta narzędzie wizualne. Pętla w pętli, własny algorytm liczący coś z dwudziestu pól, wywołanie modelu AI z kontrolą kosztu. W Make to gąszcz modułów, w n8n jeden node z kodem.

I dwie, w których odradzamy. Pierwsza: kilka prostych scenariuszy, które działają. Pięć zapów typu „formularz do arkusza, arkusz do maila" na najtańszym planie nie uzasadnia ani przepisywania, ani utrzymywania serwera. Druga: nikt w firmie nie ogarnie utrzymania. Bez osoby, która serwer zaktualizuje i zabackupuje, albo bez usługi zarządzanej, migracja przenosi problem, zamiast go rozwiązać (plusy i minusy własnej instancji n8n).

Jeśli dopiero rozstrzygasz sam wybór narzędzia, zacznij od porównania Make, n8n i Zapiera albo szczerej analizy n8n kontra Make. Reszta artykułu zakłada, że decyzja zapadła.

Inwentaryzacja, zanim dotkniesz czegokolwiek

Najczęstszy błąd na starcie to otwarcie n8n i przepisywanie pierwszego scenariusza z brzegu. Najpierw spisz wszystko, co masz. Arkusz wystarczy:

Dwie ostatnie kolumny robią najwięcej dobrego. Historia wykonań pokazuje scenariusze, które ostatni raz zadziałały pół roku temu, i takie, które odpalają się codziennie, tylko od dawna kończą się błędem, o którym nikt nie wie. Kolumna z konkretną osobą wyłapuje automatyzacje uznawane za ważne, choć nikt od dawna nie patrzy na ich wynik. Dopiero ta tabela pokazuje skalę bałaganu: dwie wersje tego samego scenariusza, bo ktoś zrobił kopię do testów i tak zostało, albo powiadomienie na kanał, do którego nikt nie zagląda.

„Najlepszym wynikiem migracji rzadko jest niższy rachunek. Zwykle jest nim lista scenariuszy, których nie przenieśliśmy, bo okazały się martwe albo zdublowane. Firma płaciła za nie latami i nikt tego nie zauważył, bo w abonamencie to była jedna pozycja." — Mikołaj Brunka, założyciel NoCodeWork

Jeśli scenariusze budował ktoś z zewnątrz i zniknął, przyda się instrukcja o przejęciu automatyzacji po freelancerze. A jeśli okaże się, że nie rozumiesz połowy procesów, najpierw zmapuj je porządnie.

Mapowanie pojęć: Make i Zapier kontra n8n

Nie istnieje konwerter, który zamieni scenariusz Make albo zapa w workflow n8n. Blueprint z Make eksportuje się do JSON-a, ale to format opisujący moduły Make, nie n8n. Przepisujesz ręcznie. Zawsze.

Pocieszające jest to, że koncepcje odpowiadają sobie niemal jeden do jednego:

Potykają się natomiast wszyscy o te same dwie rzeczy.

Przepływ danych. W Make przez scenariusz idą bundle i moduł uruchamia się raz na bundle. W n8n płynie tablica itemów, a node przetwarza ją w jednym uruchomieniu. Sporo iteratorów z Make po prostu znika, ale trzeba zrozumieć, kiedy node działa raz na wszystko, a kiedy raz na item. Na to jedno warto poświęcić wieczór przed startem, bo oszczędza tydzień później. Zmienia się też sam sposób sięgania po dane: zamiast klikania w mapowaniu piszesz wyrażenie w rodzaju {{ $json.email }}.

Obsługa błędów. Make ma retry i autoreplay w ustawieniach scenariusza. W n8n ponawianie ustawiasz na pojedynczym node'dzie, a dla całego workflow wskazujesz osobny error workflow. Zmiana na plus, ale domyślnie nie dostaniesz żadnego alertu.

A czy AI to przepisze? Częściowo i pod nadzorem. Blueprint z Make wklejony do modelu językowego daje sensowny szkic: strukturę, kolejność kroków, propozycję node'ów. Modele regularnie wymyślają nieistniejące parametry, więc każdy node trzeba potem otworzyć i sprawdzić z dokumentacją.

W jakiej kolejności przenosić scenariusze

Dostaniesz tu dwie sprzeczne rady i obie są słuszne. Zaczynaj od najprostszych, żeby nauczyć się narzędzia na czymś, czego zepsucie nikogo nie zaboli. Ale priorytetem są scenariusze najdroższe w operacjach, bo to one uzasadniają całe przedsięwzięcie. Godzimy to tak:

1. Dwa lub trzy najprostsze na rozgrzewkę. Trigger, jeden warunek, jeden zapis. Nie po to, żeby oszczędzić pieniądze, tylko żeby zderzyć się z przepływem itemów i wyrażeniami na czymś nieszkodliwym. Jeśli n8n widzisz pierwszy raz, zacznij od pierwszej automatyzacji w pół godziny.
2. Najdrożsi pożeracze operacji. Posortuj arkusz po zużyciu i weź szczyt listy. Zwykle kilka scenariuszy odpowiada za większość rachunku, a ich przeniesienie od razu pozwala zejść w starym narzędziu o próg niżej.
3. Reszta, według krytyczności rosnąco. Najpierw rzeczy wewnętrzne (raporty, powiadomienia, synchronizacje), na końcu te, które dotykają klienta: maile, SMS-y, faktury, płatności.
4. Scenariusze do skasowania. Nie przenosisz ich wcale. Wyłączasz w Make, czekasz dwa tygodnie i jeśli nikt się nie odezwie, kasujesz.

Do tego jedna zasada: jeden scenariusz na raz, w pełni skończony, zanim ruszy następny. Przepisanie dziesięciu naraz i przełączenie wszystkiego w weekend kończy się poniedziałkiem, w którym nie wiadomo, który rozsyła śmieci.

Okres równoległy i pułapka podwójnego wykonania

Przełączanie na żywca, bez okresu równoległego, to hazard. Puszczenie obu wersji naprawdę, bez żadnych zabezpieczeń, jest jeszcze gorsze. Schemat, który stosujemy per scenariusz:

1. Nowy workflow powstaje i przechodzi testy na danych przygotowanych ręcznie.
2. Włączasz go obok starego w trybie obserwacyjnym: robi wszystko poza zapisem do systemów produkcyjnych. Zamiast tworzyć rekord w CRM, dopisuje wiersz do tabeli kontrolnej z tym, co zrobiłby.
3. Przez kilka dni porównujesz wyniki obu wersji. Jeśli się zgadzają, przełączasz nowy na prawdziwe akcje i w tym samym momencie wyłączasz stary scenariusz.
4. Stary zostaje wyłączony, ale nieskasowany, przez dwa do czterech tygodni. To Twój przycisk cofnij.

Kluczowy jest punkt trzeci: przełączenie i wyłączenie to jedna czynność, nie dwie. Jeśli oba działają naprawdę, dostajesz podwójne wykonanie. Podwójny wpis w arkuszu zauważysz i skasujesz. Podwójny SMS do klienta i podwójna faktura to już rozmowa telefoniczna, której nie chcesz odbyć.

Jeśli oba muszą przez chwilę działać naprawdę, zabezpiecz się idempotencją. Każde zdarzenie ma naturalny identyfikator: numer zamówienia, ID wiadomości, ID zgłoszenia z formularza. Przed wykonaniem akcji sprawdzasz w tabeli, czy już był obsłużony, a po wykonaniu go dopisujesz. Kilka minut roboty, a ratuje przed całą klasą problemów, która wraca potem także przy zwykłych ponowieniach po błędzie.

Osobno traktuj wszystko, co wychodzi na zewnątrz firmy: maile, SMS-y, dokumenty finansowe. Tu okresu równoległego po prostu nie ma. Nowy workflow działa w trybie obserwacyjnym do końca, a przełączenie jest jednorazowe.

Credentiale i webhooki: dwa miejsca, które zawsze bolą

Credentiale zakładasz od zera. Eksportu połączeń z Make ani z Zapiera nie ma i nie będzie, bo byłaby to luka bezpieczeństwa. Każde połączenie OAuth przechodzisz ręcznie w n8n, a tempo zależy tu od tego, jak szybko dostaniesz dostępy. Oto co potrafi zatrzymać cały dzień:

• Adres zwrotny OAuth. Część usług wymaga wpisania adresu przekierowania na białą listę. Adres pochodzi z Twojej instancji, więc domena musi być gotowa przed pierwszym połączeniem.
• Konto, na które autoryzujesz. Podłączanie skrzynki albo CRM-u na prywatne konto pracownika to prosta droga do awarii w dniu jego odejścia. Używaj konta technicznego.
• Jeden aktywny token. Niektóre usługi wydają jeden token na aplikację i ponowna autoryzacja unieważnia poprzedni. Podłączasz n8n i w tej samej sekundzie przestaje działać scenariusz w Make.
• Weryfikacja aplikacji. Przy niektórych zakresach uprawnień u dużych dostawców podłączenie wymaga dodatkowego procesu w ich konsoli. To bywa kwestia dni, więc sprawdź to już przy inwentaryzacji.

Webhooki mają swój własny zestaw problemów. Adres w n8n jest inny niż w Make, więc każdy system wysyłający dane trzeba przestawić: formularz na stronie, bramka płatności, sklep, dostawca SMS. Zrób z tego osobną listę, bo to jedyne miejsce w całej migracji, gdzie zmiana leży poza Twoim narzędziem (czym jest webhook). Uważaj przy tym na testowy i produkcyjny adres webhooka w n8n: rejestrowanie u nadawcy tego testowego to klasyczny błąd pierwszego tygodnia, bo działa idealnie, dopóki masz otwarty edytor.

Częsty kłopot: nadawca pozwala wpisać tylko jeden adres, więc równoległe działanie niby odpada. Da się to obejść. Przestaw nadawcę na n8n, a w workflow jako pierwszy krok dołóż przekazanie kopii żądania pod stary adres webhooka w Make. Stary scenariusz nadal dostaje swoje dane, a Ty dopiero za nim budujesz nową logikę i po przełączeniu kasujesz jeden node.

Po migracji utrzymanie przechodzi na Ciebie

W Make i Zapierze płacisz między innymi za to, że ktoś inny pilnuje, żeby platforma działała. Przy własnej instancji ta odpowiedzialność przechodzi na Twoją stronę. To trzeba ustawić od razu, nie „później":

• Backup. Baza danych razem z kluczem szyfrowania, poza serwerem, z przetestowanym odtworzeniem. Bez klucza kopia credentiali jest bezużyteczna i nie jest to zagrożenie teoretyczne (procedura).
• Aktualizacje. Regularnie, małymi krokami, z przypiętą wersją obrazu. Skok o kilkanaście wersji naraz to najprostszy sposób na zepsucie działających workflow.
• Monitoring i alerty. Workflow, który cicho przestał działać, jest gorszy od workflow, którego nie ma, bo firma jest przekonana, że proces jest pilnowany. Ustaw error workflow wysyłający powiadomienie na kanał, który ktoś czyta (monitoring i alerty).

Serwer i konfigurację opisaliśmy w poradniku jak postawić n8n na własnym serwerze. Jeśli nikt w firmie tego nie weźmie, zostaje n8n Cloud albo usługa zarządzana (zestawienie opcji).

Rachunek: kiedy to się realnie zwraca

Licencja n8n w modelu self-hosted nie kosztuje nic, dopóki firma automatyzuje własne procesy. To nie znaczy, że n8n jest darmowy, bo koszt przenosi się w dwa inne miejsca.

Koszt jednorazowy: przepisanie. Liczba scenariuszy razy czas na scenariusz razy stawka. Prosty scenariusz to godzina lub dwie, złożony potrafi zająć dzień. Dolicz jedną czwartą na testy i okres równoległy.

Koszt stały: infrastruktura i czyjś czas. VPS 2 vCPU i 4 GB RAM to 30 do 50 zł miesięcznie i na start wystarcza, backup poza serwerem 10 do 30 zł. Największa pozycja jest niewidoczna w żadnej fakturze: 2 do 4 godzin miesięcznie pracy osoby, która to utrzymuje. Usługa zarządzana zdejmuje to z głowy za zwykle 100 do 400 zł miesięcznie (pełne wyliczenie).

Rachunek robisz w trzech krokach: weź miesięczny koszt Make albo Zapiera w planie, którego naprawdę potrzebujesz przy obecnym wolumenie; odejmij miesięczny koszt n8n (serwer plus backup plus utrzymanie); podziel koszt przepisania przez tę różnicę. Wynik to liczba miesięcy do zwrotu. Przy kilku miesiącach decyzja jest oczywista. Powyżej roku albo półtora migracja z samych kosztów się nie broni i potrzebujesz drugiego powodu: wymogów na dane, limitów nie do obejścia albo logiki, której wizualne narzędzie nie ogarnia.

W tym rachunku łatwo pominąć dwie rzeczy. n8n Cloud liczy wykonania workflow, a nie kroki, więc przy scenariuszach wielokrokowych zmienia arytmetykę na Twoją korzyść nawet bez własnego serwera (od ok. 24 € miesięcznie, ceny z lipca 2026). Druga: różnica między progami cenowymi w SaaS bywa większa niż całe utrzymanie n8n. Część firm zostaje z Make dla kilku prostych rzeczy i schodzi po prostu na tańszy próg.

Na co uważać

• Nie kasuj starych scenariuszy od razu. Wyłącz i zostaw na kilka tygodni. Kasowanie po miesiącu kosztuje kilka złotych abonamentu i potrafi uratować dzień pracy.
• Nie przebudowuj procesu i narzędzia jednocześnie. Przy błędzie nie będziesz wiedzieć, co zawiodło.
• Nie zapominaj o strefie czasowej. Instancja n8n domyślnie może działać w UTC. Harmonogram, który w Make chodził o ósmej rano, potrafi po przeniesieniu odpalać się o dziesiątej.
• Nie zostawiaj workflow bez alertu o błędzie. W Make dostawałeś maila o zatrzymanym scenariuszu. W n8n dostaniesz go tylko wtedy, gdy sam to ustawisz.
• Nie zakładaj, że każda integracja ma gotowy node. Zawsze znajdzie się polskie narzędzie, którego nie ma. Zostaje node HTTP Request i dokumentacja API: wykonalne, tylko wolniejsze (jak sprawdzić, czy narzędzie ma API).

FAQ

Czy da się zaimportować scenariusz z Make do n8n?

Nie. Nie istnieje oficjalny ani sensownie działający nieoficjalny konwerter między tymi formatami. Blueprint z Make eksportuje się do pliku JSON, ale opisuje moduły i parametry Make, których n8n nie rozumie. Scenariusze przepisujesz ręcznie, node po node. Blueprint przydaje się jako dokumentacja i jako materiał wejściowy dla modelu AI, który przygotuje szkic do weryfikacji.

Ile trwa migracja z Make do n8n?

Prosty scenariusz to godzina do dwóch razem z testem, złożony (rozgałęzienia, pętle, przetwarzanie dokumentów, kilka systemów) potrafi zająć cały dzień. Do sumy godzin doliczyć trzeba okres równoległy: od kilku dni przy procesach wewnętrznych do kilku tygodni przy tych, które dotykają klienta. Zestaw kilkunastu automatyzacji zamyka się realnie w kilku tygodniach pracy rozłożonej w czasie, nie w weekend.

Czy podczas migracji automatyzacje mogą wykonać się dwa razy?

Tak i to najczęstsza awaria przy takich przeprowadzkach. Jeśli stary scenariusz i nowy workflow działają jednocześnie na tym samym zdarzeniu, oba wykonają akcję: dwa rekordy w CRM, dwa maile, dwie faktury. Zabezpieczasz się tak: nowy workflow uruchamiaj w trybie obserwacyjnym bez zapisu do systemów produkcyjnych, przełączaj i wyłączaj stary w tej samej chwili, a tam, gdzie oba muszą przez moment działać, sprawdzaj identyfikator zdarzenia przed wykonaniem akcji.

Czy trzeba przenosić wszystkie scenariusze?

Nie i zwykle nie warto. Inwentaryzacja regularnie pokazuje, że część automatyzacji jest martwa, zdublowana albo obsługuje proces, którego już nie ma. Te po prostu wyłączasz. Sensowna bywa też migracja częściowa: ciężkie i kosztowne procesy idą do n8n, a kilka prostych zostaje w Make na najtańszym planie.

Co się dzieje z połączeniami i dostępami po migracji?

Wszystkie credentiale zakładasz w n8n od nowa, bo eksport połączeń nie jest możliwy w żadnym z tych narzędzi. Każde połączenie OAuth przeprowadzasz ręcznie, najlepiej na koncie technicznym firmy. Zaplanuj to wcześniej: część usług wymaga wpisania adresu zwrotnego na białą listę albo dodatkowej weryfikacji aplikacji, a niektóre wydają tylko jeden aktywny token, więc podłączenie n8n zrywa działające połączenie w starym narzędziu.

Podsumowanie

Samo przepisanie scenariuszy jest przewidywalne i policzalne, więc ludzie planują migrację tak, jakby na tym się kończyła. Ryzyko siedzi w procesach, które przez chwilę działają w dwóch miejscach naraz, w dostępach do odtworzenia i w tym, że utrzymanie platformy przechodzi na Twoją stronę.

Kolejność, która się sprawdza, jest zawsze ta sama. Najpierw arkusz ze wszystkim, co masz, i uczciwa decyzja, co w ogóle jedzie dalej. Potem dwa proste scenariusze na naukę, potem te najdroższe w operacjach, na końcu te, które dotykają klienta. Każdy z osobna, z okresem równoległym i zabezpieczeniem przed podwójnym wykonaniem. I policz to przed startem: jeśli koszt przepisania dzielony przez miesięczną oszczędność wychodzi powyżej roku, a nie masz drugiego powodu, zostawienie wszystkiego tak, jak jest, jest racjonalną decyzją.

Zastanawiasz się, czy w Waszym przypadku migracja się opłaca i od czego zacząć? Umów bezpłatną konsultację — przejdziemy przez Waszą listę scenariuszy i powiemy wprost, jeśli lepiej zostać przy tym, co macie.

Przeczytaj również

• Make vs n8n vs Zapier: porównanie narzędzi do automatyzacji
• W czym n8n jest lepszy od Make: szczera analiza
• Jak postawić n8n na własnym serwerze: przewodnik krok po kroku
• Ile kosztuje utrzymanie n8n na własnym serwerze
• Backup i aktualizacje n8n: jak nie stracić automatyzacji po restarcie