Von Zapier oder Make zu n8n wechseln: Was migrierbar ist und was neu gebaut werden muss

Ein Wechsel von Zapier oder Make zu n8n ist kein Import, sondern ein Neubau: Zapier und Make exportieren Workflows zwar als JSON, aber die n8n-Dokumentation beschreibt keinen Import dieser Dateien. Was sich übertragen lässt, ist die Logik dahinter (welcher Trigger, welche Verzweigung, welche Fehlerbehandlung), nicht die Konfiguration selbst. Wie viel davon sich in n8n direkt nachbauen lässt und wo ein anderes Konzept nötig wird, unterscheidet sich je Bauteil eines Workflows.

Kein Import-Knopf: warum der Wechsel ein Neubau ist

Beide Ausgangstools haben einen Export: Make exportiert ein Szenario als sogenanntes „Blueprint“, eine JSON-Datei mit Modulen, Moduleinstellungen und Feldzuordnungen. Verbindungen enthält sie laut Make nicht, die legt man nach dem Import neu an. Einfügen lässt sich ein Blueprint laut Make in andere Make-Szenarien, in LLMs oder in „andere kompatible Tools“. Einen JSON-Export aller eigenen Zaps (Kontoinhaber und Super-Admins: aller Zaps im Konto) bietet Zapier in den Tarifen Team und Enterprise, um Zaps zu sichern und mit anderen Zapier-Konten zu teilen. Daneben enthält der Export der Kontodaten aus den Kontoeinstellungen eine Datei Zapfile.json mit allen nicht gelöschten Zaps. Einen Import von Zapier- oder Make-Dateien beschreibt die n8n-Dokumentation dagegen nicht.

Für Zapier-Exporte gibt es ein Community-Werkzeug, das daraus eine n8n-Importdatei erzeugt. Ein Nutzer hat es im offiziellen n8n-Forum vorgestellt: Nach seiner eigenen Angabe übersetzt es rund 80 Prozent der Arbeit, der Test mit echten Daten bleibt beim Anwender. Daneben gibt es kommerzielle Konvertierungsdienste, etwa Migromat, der nach eigener Beschreibung Zapier- und Make-Workflows mit KI-Unterstützung als prüfbare n8n-Workflows nachbaut; für Zapier laden Sie laut dessen Anleitung den Zapier-Export aller privaten und geteilten Zaps (laut Zapier in den Tarifen Team oder Enterprise und nur für Kontoinhaber oder Super-Admins) hoch. Prüfen Sie vor dem Hochladen, welche Daten der Export enthält; die Zapfile.json aus dem Kontodaten-Export etwa enthält laut Zapier auch die Ein- und Ausgabewerte der einzelnen Schritte. Solche Werkzeuge sparen Abtipparbeit, ersetzen aber keine Prüfung. Sie übersetzen Trigger, Aktionen und Feldverweise so weit, wie sich die Konzepte beider Systeme aufeinander abbilden lassen. Wo sich die Konzepte nicht entsprechen, entsteht der Nacharbeitsaufwand, den dieser Beitrag Bauteil für Bauteil durchgeht.

Die Prüfmatrix: was übertragbar ist und was neu entsteht

Die folgende Übersicht ordnet vierzehn Bauteile eines Zapier- oder Make-Workflows danach ein, wie viel Arbeit der Wechsel zu n8n an dieser Stelle macht. Sie ersetzt keine Einzelprüfung Ihres Workflows, gibt aber eine Einschätzung, bevor Sie mit dem Nachbau anfangen. Die Angaben zu den Funktionen der drei Tools geben den Stand der Herstellerdokumentation am 28. September 2026 wieder.

Bauteil	Zapier / Make	n8n-Entsprechung	Einstufung
Sofort-Trigger (Webhook)	Webhook-basierte App-Trigger	Trigger-Node der App, falls vorhanden; sonst Webhook-Node mit eigener URL in der Quell-App	weitgehend übertragbar, sofern n8n einen Trigger-Node hat oder die Quell-App eine eigene Webhook-URL zulässt
Abfrage-Trigger, n8n hat einen Trigger-Node für die App	Abfrage in festen Abständen, automatische Deduplizierung über ein ID-Feld (Zapier)	Trigger-Node der App, z. B. Gmail Trigger mit einstellbarer Poll Time	weitgehend übertragbar, Verhalten im Testlauf prüfen
Abfrage-Trigger, n8n hat keinen Trigger-Node für die App	wie oben	Schedule Trigger + Abfrage-Node + Remove-Duplicates-Node	teilweise übertragbar, Deduplizierung explizit nachbauen
App-Aktion (z. B. Datensatz anlegen)	Aktionsschritt der App (Zapier) / App-Modul (Make)	Node der App; gibt es keinen, HTTP-Request-Node gegen die REST-API der App	weitgehend übertragbar mit App-Node; teilweise, wenn Sie die Anfrage im HTTP-Request-Node selbst aufbauen
Filter	Filter-Schritt (Zapier) / Filter zwischen Modulen (Make)	Filter-Node	weitgehend übertragbar, Bedingungen neu eintragen; gemischte UND/ODER-Logik kann der Filter-Node nicht, dann mehrere Filter- oder IF-Nodes hintereinander oder eine Bedingung als Ausdruck
Code-Schritt	Code-Schritt in JavaScript oder Python (Zapier)	Code-Node (JavaScript oder Python)	teilweise übertragbar, Ein- und Ausgabe im Testlauf prüfen
Verzögerung	Delay for, Delay until, Delay after queue (Zapier)	Wait-Node: After Time Interval, At Specified Time	Delay for und Delay until weitgehend übertragbar; Delay after queue ohne Gegenstück im Wait-Node, Drosselung neu planen
Bedingte Verzweigung	Paths (Zapier, von links nach rechts ausgewertet) / Router (Make, Routen mit Filtern, nacheinander abgearbeitet)	IF- und Switch-Node, bei Bedarf ein Merge-Node zum Zusammenführen	Konzept überträgt sich, Ausführungslogik nicht: neu bauen
Datenformatierung	Formatter-Schritt (Zapier) / Funktionen in der Feldzuordnung (Make)	für einzelne Fälle eigene Nodes (z. B. Date & Time), sonst Ausdrücke ({{ }}) im Edit-Fields-Node oder Code-Node	neu bauen, jede Aktion einzeln neu zuordnen
Listen-/Array-Verarbeitung	Looping by Zapier / Iterator + Aggregator (Make)	Split-Out-Node + Aggregate-Node, bei Bedarf Loop-Over-Items-Node	weitgehend übertragbar, Konzept gleich, Bedienung abweichend
Fehlerbehandlung je Schritt	Error-Handler als alternativer Pfad (Zapier) / fünf Error Handler: Skip, Retry, Resume, Commit, Rollback (Make)	„On Error“-Einstellung je Node: Stop Workflow, Continue, Continue (using error output)	neu bauen, kein Bauteil bildet ein anderes 1:1 nach
Automatischer Wiederholungsversuch	Autoreplay (Zapier, ab Professional) / Retry-Handler mit einstellbarer Zahl und Abstand der Versuche (Make)	„Retry On Fail“ je Node	neu einrichten, Kombination mit „Continue“-Optionen vorab testen (siehe unten)
Workflow-weite Fehlerbenachrichtigung	Fehlermails an die E-Mail-Adresse des Zapier-Kontos, außer wenn ein Error-Handler läuft (Zapier) / Mail bei Fehler oder deaktiviertem Szenario (Make)	Error-Trigger-Node in einem eigenen Error-Workflow, verknüpft über die Workflow-Einstellung	Konzept überträgt sich, eigener Workflow nötig
Zugangsdaten/Anmeldungen	App Connections (Zapier) / Connections (Make)	Credentials	nicht übertragbar, in n8n neu anlegen

Nicht enthalten sind Zwischenspeicher (Storage by Zapier, Data Stores in Make) und wiederverwendbare Sub-Zaps; prüfen Sie diese je Workflow gesondert. Die Zeilen im Detail, mit den Quellen dazu, folgen in den nächsten Abschnitten.

Trigger: vom Sofort- oder Abfrage-Zap zum n8n-Auslöser

Bei webhook-basierten Triggern sendet eine App eine Anfrage, sobald ein Ereignis eintritt. Prüfen Sie zuerst, ob n8n für die App einen eigenen Trigger-Node hat. Gibt es keinen, übernimmt n8ns Webhook-Node die Rolle des Sofort-Triggers. Voraussetzung ist dann, dass Sie in der Quell-App eine eigene Webhook-URL eintragen können; ist das möglich, hinterlegen Sie dort die neue URL und gegebenenfalls die Zugangsdaten.

Bei Abfrage-Triggern fragt das Tool in festen Abständen nach neuen Daten. Zapier tut das laut Preisseite (Stand 28. September 2026) im Free-Tarif alle 15 Minuten, im Professional-Tarif alle 2 Minuten, in Team und Enterprise jede Minute; im Enterprise-Tarif lässt sich das Intervall zusätzlich auf bis zu 15 Minuten einstellen. Damit ein Datensatz nicht mehrfach einen Lauf auslöst, vergleicht Zapier die ID jedes abgefragten Datensatzes mit den IDs, die der Zap schon gesehen hat, und startet nur bei einer neuen ID.

In n8n hängt der Aufwand davon ab, ob es für die App einen eigenen Trigger-Node gibt. Der Gmail Trigger zum Beispiel fragt ebenfalls in einstellbaren Abständen ab und löst laut n8n-Dokumentation bei neuen Nachrichten aus. In diesem Fall übernimmt der Trigger-Node die Erkennung neuer Einträge, und der Nachbau ist weitgehend eine Übertragung. Prüfen Sie im Testlauf trotzdem, ob er dieselben Datensätze liefert wie der alte Trigger. Gibt es keinen Trigger-Node, bildet der Schedule Trigger nur den Zeitplan nach. Die Erkennung „diesen Datensatz kenne ich schon“ ist dann ein eigener Baustein, den Sie mit dem Remove-Duplicates-Node im Modus „Remove Items Processed in Previous Executions“ nachbauen, zum Beispiel über eine eindeutige ID oder ein Datumsfeld. Fehlt dieser Schritt, verarbeitet der Workflow bei jedem Lauf dieselben Datensätze erneut.

Verzweigungen: von Pfaden und Routern zum Node-Graphen

Zapiers Paths werten die Zweige nacheinander aus, in der Reihenfolge, in der sie im Editor von links nach rechts stehen. Je nach Bedingungen laufen ein oder mehrere Zweige; ein Fallback-Zweig läuft, wenn keiner der anderen greift. Makes Router verteilt den Ablauf auf mehrere Routen mit eigenen Filterbedingungen. Make arbeitet die Routen nacheinander ab, nicht parallel, und eine Fallback-Route verarbeitet, was zu keiner anderen Route passt.

n8n bildet Verzweigungen über den IF-Node für zwei Wege oder den Switch-Node für mehr als zwei ab. Beide sind Teil eines expliziten Node-Graphen, in dem Sie die Zweige bei Bedarf über einen Merge-Node zusammenführen. Laut n8n-Dokumentation führt der Merge-Node Daten zusammen, sobald die Daten aller Eingänge vorliegen; testen Sie deshalb das Verhalten, wenn nur ein Zweig Daten liefert. Das Konzept, abhängig von einer Bedingung unterschiedliche Schritte auszuführen, überträgt sich. Die konkrete Verzweigung nicht: Wo Zapier eine Reihenfolge von Pfaden vorgibt und Make gefilterte Routen, bauen Sie in n8n den Entscheidungsbaum als eigenen Graphen neu, Bedingung für Bedingung. Prüfen Sie dabei, wohin Datensätze laufen, die keine Bedingung erfüllen und bisher im Fallback-Zweig landeten; beim IF-Node ist das der False-Ausgang. Beim Switch-Node steht die Option „Fallback Output“ laut Dokumentation standardmäßig auf „None“: Nicht passende Items werden ignoriert. Laufen in Zapier bisher mehrere Pfade für denselben Datensatz, stellen Sie im Switch-Node die Option „Send data to all matching outputs“ ein; ausgeschaltet gehen die Daten nur an den ersten passenden Ausgang.

Formatierung und Datenverarbeitung: vom Formatter zu Node und Ausdruck

Zapiers Formatter bietet vier Gruppen vorgefertigter Transformationen (Text, Zahlen, Datum/Uhrzeit, Utilities), aus denen Sie per Auswahl die passende wählen, etwa ein Datumsformat umwandeln oder Text aufteilen. Make deckt vergleichbare Fälle über Funktionen in der Feldzuordnung ab, etwa Text kürzen oder ein Datum anders formatieren.

n8n bündelt diese Transformationen nicht in einem Formatter-Schritt. Für einzelne Fälle gibt es eigene Nodes, etwa den Date-&-Time-Node mit der Operation „Format a Date“ oder Transformations-Nodes wie Sort, Limit oder Summarize. Alles andere schreiben Sie als Ausdruck ({{ }}, JavaScript-basiert) im Edit-Fields-Node (in der Doku „Edit Fields (Set)“) oder bei komplexeren Fällen in einen Code-Node (JavaScript oder Python). Jede Formatter-Aktion aus dem alten Workflow ordnen Sie also einzeln neu zu: einem passenden Node, einem Ausdruck oder einer Codezeile. Eine Zuordnungstabelle „Formatter-Aktion X entspricht Node oder Ausdruck Y“ findet sich in den Herstellerdokumentationen nicht.

Listen und Arrays: Iterator/Aggregator vs. Split Out/Aggregate

Dieses Bauteil gilt als weitgehend übertragbar, ebenso wie Trigger mit App-eigenem Trigger-Node oder Webhook. Makes Iterator wandelt ein Array in einzelne Bundles um, die einzeln weiterverarbeitet werden; der Aggregator führt mehrere Bundles wieder zu einem Array zusammen. n8ns Split-Out-Node trennt eine Liste in einzelne Items auf, der Aggregate-Node führt Items wieder zu einem Datensatz zusammen. Das Muster „aufteilen, einzeln verarbeiten, wieder zusammenführen“ überträgt sich direkt; anders sind die Bedienung der Nodes und die Feldauswahl.

Aktionen, Filter, Code und Verzögerungen

Neben Triggern und Logik enthält ein Workflow App-Aktionen, etwa einen Datensatz anlegen oder eine Nachricht senden. Hat n8n einen Node für die App, wählen Sie dort die entsprechende Operation und ordnen die Felder neu zu. Gibt es keinen, bauen Sie die Anfrage mit dem HTTP-Request-Node gegen die REST-API der App selbst auf; dafür brauchen Sie die API-Dokumentation des Anbieters.

Zapiers Filter lässt einen Zap nur weiterlaufen, wenn die Daten eine Bedingung erfüllen; Make setzt Filter zwischen Module. In n8n übernimmt der Filter-Node diese Rolle. Code-Schritte in JavaScript oder Python aus Zapier landen im Code-Node, der ebenfalls beide Sprachen ausführt; prüfen Sie im Testlauf, ob der Code mit den Ein- und Ausgabedaten in n8n dasselbe Ergebnis liefert. Zapiers Delay kennt drei Varianten (Delay for, Delay until, Delay after queue); in n8n pausiert der Wait-Node die Ausführung. Delay for entspricht dort „After Time Interval“, Delay until „At Specified Time“. Delay after queue reiht Zap-Läufe in eine Warteschlange und arbeitet sie mit Abstand nacheinander ab; Zapier empfiehlt das, wenn zu viele Läufe gleichzeitig dieselbe App ansprechen. Keine der vier Wait-Optionen (After Time Interval, At Specified Time, On Webhook Call, On Form Submitted) bildet eine solche Warteschlange; die Drosselung müssen Sie in n8n neu planen.

Fehlerbehandlung: drei unterschiedliche Sicherheitsnetze

Bei der Fehlerbehandlung bildet keines der drei Tools ein anderes 1:1 nach. Im Konzept am nächsten kommen sich Zapiers Error-Handler-Pfad und n8ns Option „Continue (using error output)“, die die Fehlerinformation zur Weiterverarbeitung an den nächsten Node gibt, sowie Makes Retry-Handler und n8ns „Retry On Fail“. Die Details unterscheiden sich.

Zapier bietet ab dem Professional-Tarif zwei Mechanismen. Autoreplay wiederholt Zap-Läufe mit Fehlerstatus automatisch. Getrennt davon hängen Sie mit einem Error-Handler an einen Schritt einen alternativen Pfad, der bei einem Fehler statt des Erfolgspfads läuft. Zwei Folgen nennt Zapier dazu ausdrücklich: Mit einem veröffentlichten Error-Handler schaltet sich Autoreplay für diesen Zap ab, und Zapier verschickt keine Fehlermail, wenn der Error-Handler läuft.

Make bietet laut Help Center (Stand 8. September 2026) fünf Error Handler, die Sie an einzelne Module hängen: Skip und Resume lassen die Ausführung weiterlaufen, Commit und Rollback beenden sie kontrolliert. Der Retry-Handler legt den betroffenen Datensatz als „Incomplete Execution“ ab; dafür müssen Incomplete Executions in den Szenario-Einstellungen aktiviert sein. Ist die automatische Fertigstellung eingeschaltet, wiederholt Make den Lauf standardmäßig bis zu dreimal im Abstand von 15 Minuten; beide Werte stellen Sie im Error Handler selbst ein.

n8n trennt die Fehlerbehandlung in zwei Ebenen, anders geschnitten als Zapier oder Make. Pro Node wählen Sie in den Node-Einstellungen unter „On Error“ zwischen Stop Workflow, Continue und Continue (using error output); dort sitzt auch „Retry On Fail“. Für den gesamten Workflow richten Sie einen Error-Trigger-Node in einem eigenen Workflow ein und verknüpfen ihn über die Error-Workflow-Einstellung mit dem eigentlichen Workflow. Eine Stelle, die Sie beim Nachbau testen sollten: In einem öffentlich gemeldeten n8n-Issue vom September 2024 gab ein Node mit aktivem „Retry On Fail“ und einer der „Continue“-Optionen einen Fehler aus, obwohl ein Wiederholungsversuch erfolgreich war. Ein n8n-Mitarbeiter schrieb beim Schließen am 11. September 2024, „Retry On Fail“ funktioniere derzeit nur mit der Option „Stop Workflow“; bei den anderen Optionen müsse man Wiederholungen selbst abbilden. Am 18. Dezember 2024 schrieb derselbe Mitarbeiter, er könne das gemeldete Problem nun nachvollziehen, und schrieb, er habe eine interne Verbesserungsanfrage angelegt. Das Issue ist weiterhin als „not planned“ geschlossen. Ob Ihre n8n-Version sich so verhält, zeigt ein Testlauf mit absichtlich ausgelöstem Fehler, bevor der Workflow produktiv geht.

Den Aufwand abschätzen: ein Rechenweg mit Ihren eigenen Werten

Die Einstufung in der Matrix lässt sich in eine grobe Aufwandsschätzung je Workflow übersetzen. Zählen Sie je Workflow, wie oft jedes Bauteil vorkommt, und multiplizieren Sie mit einem Gewicht je Einstufung. Dazu kommen ein fester Block für Test und Parallelbetrieb sowie die Credentials.

Das folgende Beispiel rechnet in abstrakten Einheiten, nicht in Stunden. Die Gewichte sind Annahmen, keine Erfahrungswerte: Sie bilden nur ab, dass ein Neubau mehr Arbeit macht als eine Übertragung. Wie viele Stunden eine Einheit bei Ihnen sind, zeigt erst Ihr erster migrierter Workflow.

Annahme	Gewicht
Bauteil „übertragbar“ oder „weitgehend übertragbar“	1 Einheit
Bauteil „teilweise übertragbar“	2 Einheiten
Bauteil „neu bauen“	4 Einheiten
Credential neu anlegen, je Verbindung	1 Einheit
Test mit echten Daten und Parallelbetrieb, je Workflow	4 Einheiten

	Workflow A: linear	Workflow B: verzweigt
Trigger	Webhook (weitgehend übertragbar): 1	Abfrage ohne n8n-Trigger-Node (teilweise): 2
App-Aktionen	zwei Aktionen mit App-Node (weitgehend): 2	zwei Aktionen mit App-Node (weitgehend) und eine per HTTP-Request-Node (teilweise): 4
Verzweigung	keine	Router mit drei Routen (neu bauen): 4
Formatierung	zwei Formatter-Schritte (neu bauen): 8	ein Formatter-Schritt (neu bauen): 4
Listen	keine	Iterator + Aggregator (weitgehend): 1
Fehlerbehandlung je Schritt	keine	Error Handler an zwei Modulen (neu bauen): 8
Fehlerbenachrichtigung	Error-Workflow (Konzept überträgt sich, als teilweise gewertet): 2	Error-Workflow (teilweise): 2
Credentials	zwei Verbindungen: 2	drei Verbindungen: 3
Test und Parallelbetrieb	4	4
Summe	19 Einheiten	32 Einheiten

Solange ein Neubau mehr Zeit kostet als eine Übertragung, treiben die Zeilen „neu bauen“ die Summe, nicht die Anzahl der Schritte: Workflow A hat kaum Logik, aber zwei Formatter-Schritte, die neu zugeordnet werden müssen. Außerdem fallen Test, Credentials und der Error-Workflow je Workflow an, egal wie einfach er ist; den Error-Workflow verlangt auch Schritt 4 im Ablauf unten. Wer viele kleine Workflows migriert, zahlt diesen Block viele Male. Auf der Kostenseite kommt hinzu, dass während des Parallelbetriebs der alte Tarif weiterläuft, während n8n schon genutzt wird.

Ein geordneter Ablauf für den Wechsel

Bauen Sie nicht alle Workflows gleichzeitig um. Gehen Sie je Workflow in dieser Reihenfolge vor:

1. Bestandsaufnahme. Für jeden Zap oder jedes Szenario: welcher Trigger-Typ, welche Verzweigungen, welche Fehlerbehandlung. Mit der Prüfmatrix und dem Rechenweg oben schätzen Sie den Aufwand vorab.
2. Mit dem einfachsten Fall anfangen. Ein linearer Workflow ohne Verzweigung bestätigt am schnellsten, dass Trigger und Zugangsdaten im neuen System laufen, und zeigt Ihnen, wie viele Stunden eine Einheit bei Ihnen tatsächlich sind.
3. Beide Systeme parallel laufen lassen, bis der neue Workflow mit echten Daten geprüft ist. Erst dann den alten Zap oder das alte Szenario deaktivieren, nicht löschen.
4. Fehlerbehandlung zuletzt, aber vor der Abschaltung des alten Workflows. Ein Workflow ohne Error-Workflow läuft zwar, meldet einen Ausfall aber nicht von selbst.

Für den Mittelstand heißt das

Ein Wechsel lohnt sich dort, wo einer der Gründe für n8n für Sie schwer wiegt, etwa Self-Hosting oder die Abrechnung pro Ausführung: n8n zählt einen vollständigen Workflow-Lauf als eine Ausführung, unabhängig von der Zahl der Schritte (Stand 28. September 2026). Was dabei für die Werkzeugwahl selbst zählt, arbeitet unser Vergleich von n8n, Make und Power Automate heraus. Dieser Beitrag setzt eine getroffene Entscheidung voraus und zeigt, was ihr Umbau kostet. Rechnen Sie den Aufwand je Workflow durch, bevor Sie einen ganzen Bestand umstellen: Jede Verzweigung, jeder Formatter-Schritt und jeder Error Handler an einem Modul zählt im Rechenweg oben als Neubau. Liegt der Hauptgrund für den Wechsel im Hosting, lohnt vorab ein Blick in unseren Beitrag zu n8n und DSGVO. Für den Betrieb danach gilt unser Beitrag zum Monitoring: Ein migrierter Workflow braucht dieselbe Fehlerüberwachung wie ein neu gebauter. Wie ein erster n8n-Workflow strukturiert eingeführt wird, ob migriert oder neu gebaut, beschreibt unser Leitfaden zu n8n im Mittelstand.

FAQ

Kann ich meine Zapier- oder Make-Workflows automatisch nach n8n importieren?

Nicht mit einer Funktion der Anbieter. Zapier und Make exportieren Workflows als JSON, und die n8n-Dokumentation beschreibt keinen Import dieser Dateien. Für Zapier-Exporte gibt es etwa ein Community-Werkzeug, das eine n8n-Importdatei erzeugt, dessen Ergebnis aber ein Entwurf ist, den Sie vor dem produktiven Einsatz mit echten Daten prüfen müssen.

Was muss bei einem Wechsel zu n8n komplett neu gebaut werden?

Neu bauen müssen Sie bedingte Verzweigungen, die Formatierung und die Fehlerbehandlung: Zapiers Paths und Makes Router-Routen lassen sich nicht direkt in n8ns IF- und Switch-Nodes übertragen, Formatter-Schritte ordnen Sie einzeln einem Node, Ausdruck oder Code zu, und bei der Fehlerbehandlung bildet keines der drei Tools ein anderes 1:1 nach. Am nächsten kommen sich Zapiers Error-Handler-Pfad und n8ns Option „Continue (using error output)“ sowie Makes Retry-Handler und n8ns „Retry On Fail“.

Was bleibt bei einem Wechsel zu n8n weitgehend gleich?

Die Grundidee der Listen- und Array-Verarbeitung: Makes Iterator und Aggregator entsprechen im Aufbau n8ns Split-Out- und Aggregate-Node, auch wenn Bedienung und Benennung abweichen. Webhook-basierte Sofort-Trigger sind ebenfalls konzeptionell gleich. Die Verbindungen zu Ihren Apps legen Sie in n8n dagegen als Credentials neu an.

Lohnt sich der Wechsel zu n8n für jeden Workflow gleichermaßen?

Nein. Ein linearer Workflow ohne Verzweigungen und ohne Formatter-Schritte braucht wenig Neubau. Ein Workflow mit mehreren verschachtelten Pfaden, eigener Fehlerbehandlung je Schritt und mehreren Formatierungsschritten braucht in n8n einen echten Neubau, keine Übersetzung. Auch ein linearer Workflow kann aufwendig werden, wenn er viele Formatter-Schritte enthält. Prüfen Sie das vor dem Wechsel je Workflow einzeln anhand der Prüfmatrix und des Rechenwegs in diesem Beitrag.

Wie stelle ich fest, ob ein einzelner Auslöser sich 1:1 übertragen lässt?

Prüfen Sie zuerst, ob der bestehende Trigger webhook-basiert (sofort) oder polling-basiert (Abfrage in festen Abständen) arbeitet. Bei einem Webhook-Trigger prüfen Sie zuerst, ob n8n einen Trigger-Node für die App hat; sonst nutzen Sie den Webhook-Node und tragen dessen URL in der Quell-App ein, sofern die App das zulässt. Bei einem Polling-Trigger kommt es darauf an, ob n8n für die App einen eigenen Trigger-Node hat, wie etwa den Gmail Trigger, der neue Nachrichten erkennt. Gibt es keinen, bauen Sie die Abfrage mit dem Schedule Trigger nach und ergänzen die Erkennung bereits verarbeiteter Datensätze mit dem Remove-Duplicates-Node.