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: Keiner der drei Anbieter bietet eine Funktion, um Workflows automatisch aus einem anderen Tool zu übernehmen. 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 ganz anderes Konzept nötig wird, unterscheidet sich stark je Bauteil eines Workflows.

Kein Import-Knopf: warum der Wechsel ein Neubau ist

Beide Ausgangstools haben zwar einen Export: Make exportiert ein Szenario als sogenanntes „Blueprint” (eine JSON-Datei mit Modulen, Verbindungen und Feldzuordnungen, aber ohne die eigentlichen Zugangsdaten). Zapier bietet eine vergleichbare JSON-Exportfunktion nur auf Team- und Enterprise-Tarifen, als Sicherung oder zum Teilen im selben Konto. Beide Formate sind für den Re-Import in dasselbe Tool gedacht, nicht für ein fremdes System – n8n selbst liest keines von beiden ein. Was existiert, sind Community-Werkzeuge, die eine solche Exportdatei in eine n8n-kompatible Importdatei übersetzen; ein Beispiel dafür hat ein Nutzer im offiziellen n8n-Forum vorgestellt und ausdrücklich um Rückmeldung gebeten, weil das Ergebnis geprüft werden muss, bevor es produktiv läuft. Diese Werkzeuge sind kein Ersatz für die Prüfung, nur eine Abkürzung beim Abtippen: Sie übersetzen Trigger, Aktionen und Feldverweise so gut, wie sich die Konzepte der beiden Systeme aufeinander abbilden lassen – und genau dort, wo sich die Konzepte nicht 1:1 entsprechen, entsteht der Nacharbeitsaufwand, den dieser Beitrag durchgeht.

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

Die folgende Übersicht ordnet neun Bauteile eines typischen Zapier- oder Make-Workflows danach ein, wie viel Arbeit der Wechsel zu n8n an dieser Stelle tatsächlich macht. Sie ersetzt keine Einzelprüfung Ihres Workflows, gibt aber vorab eine realistische Einschätzung, bevor Sie mit dem Nachbau anfangen.

Bauteil	Zapier / Make	n8n-Entsprechung	Einstufung
Sofort-Trigger (Webhook)	Webhook-basierte App-Trigger	Webhook-Node	1:1 übertragbar – Zugangsdaten und URL neu einrichten
Abfrage-Trigger (Polling)	Abfrage alle 1–15 Minuten, automatische Dedublizierung über ein ID-Feld	Schedule-Trigger + Abfrage-Node + eigener Dedublizierungs-Schritt	teilweise übertragbar – Dedublizierung muss explizit nachgebaut werden
Bedingte Verzweigung	Paths (Zapier, sequenziell ausgewertet) / Router (Make, ein Eingang, mehrere gefilterte Ausgänge)	IF- und Switch-Node, danach ein Merge-Node zum Wiederzusammenführen	Konzept überträgt sich, Ausführungslogik nicht – neu bauen
Datenformatierung	Formatter-Schritt (Zapier) / eingebaute Funktionen (Make)	Set-Node mit Ausdrücken ({{ }}) oder Code-Node (JavaScript)	neu bauen – vom Dropdown zum Ausdruck
Listen-/Array-Verarbeitung	Iterator + Aggregator (Make)	Split-Out-Node + Aggregate-Node	weitgehend übertragbar – Konzept identisch, Bedienung abweichend
Fehlerbehandlung je Schritt	Custom Error Handling (Zapier) / fünf Direktiven: Ignore, Resume, Commit, Rollback, Break (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, bis zu fünf Versuche) / Break-Direktive mit konfigurierbarem Intervall (Make)	„Retry On Fail” je Node	neu einrichten – nicht kombinierbar mit „Continue”-Optionen (siehe unten)
Workflow-weite Fehlerbenachrichtigung	Automatische Fehlermail (Zapier) / Scenario-Benachrichtigung (Make)	Error-Trigger-Node in einem separaten 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 – OAuth-Tokens lassen sich nicht exportieren

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 – eine App sendet eine eingehende Anfrage, sobald ein Ereignis eintritt – ist der Wechsel unkompliziert: n8ns Webhook-Node übernimmt dieselbe Rolle wie ein Sofort-Trigger in Zapier oder Make, Sie richten nur die neue URL und gegebenenfalls die Zugangsdaten in der Quell-App neu ein.

Anders bei Abfrage-Triggern – dem Fall bei Apps ohne Webhook-Unterstützung. Zapier fragt hier je nach Tarif alle ein bis 15 Minuten ab, ob neue Daten vorliegen. Damit ein und derselbe Datensatz nicht mehrfach einen Lauf auslöst, vergleicht Zapier laufend die IDs neu abgefragter Datensätze mit bereits gesehenen IDs und lässt einen Zap nur bei einer neuen ID laufen. Diese Erkennung läuft automatisch im Hintergrund – ohne dass Sie sie konfigurieren müssen, solange die angebundene App ein eindeutiges ID-Feld liefert. n8ns Schedule-Trigger bildet nur den Zeitplan-Teil nach; die Erkennung „diesen Datensatz kenne ich schon” ist ein eigener Baustein, den Sie mit dem Remove-Duplicates-Node im Modus „Remove Items Processed in Previous Executions” nachbauen müssen. Wer diesen Schritt beim Nachbau übersieht, bekommt denselben Datensatz bei jedem Lauf erneut verarbeitet.

Verzweigungen: von Pfaden und Routern zum Node-Graphen

Zapiers Paths werten mehrere Zweige sequenziell aus, in der Reihenfolge, in der sie im Editor von links nach rechts angeordnet sind – abhängig von den Bedingungen können ein, mehrere oder gar kein Zweig laufen. Makes Router-Modul hat einen Eingang und mehrere Ausgänge: Jeder Zweig dahinter trägt eigene Filterbedingungen, und ein Datensatz durchläuft je nach Konfiguration einen oder mehrere davon.

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 anschließend über einen Merge-Node wieder zusammenführen, falls der Workflow danach weiterläuft. Das dahinterliegende Konzept – abhängig von einer Bedingung unterschiedliche Schritte ausführen – überträgt sich. Die konkrete Verzweigung selbst überträgt sich nicht: Wo Zapier eine Reihenfolge von Pfaden vorgibt und Make gefilterte Router-Ausgänge, bauen Sie in n8n den Entscheidungsbaum als eigenen Graphen neu, Bedingung für Bedingung.

Formatierung und Datenverarbeitung: vom Dropdown zum Ausdruck

Zapiers Formatter bietet vier vorgefertigte Aktionsgruppen – Text, Zahlen, Datum/Uhrzeit, Utility –, aus denen Sie per Dropdown die passende Transformation auswählen, etwa Groß-/Kleinschreibung ändern oder ein Datumsformat umwandeln. Make deckt vergleichbare Fälle über eingebaute Funktionen innerhalb der Feldzuordnung ab.

n8n kennt keine äquivalente Dropdown-Sammlung. Stattdessen tragen Sie dieselbe Logik über Ausdrücke ({{ }}, JavaScript-basiert) im Set-Node (heute als „Edit Fields” bezeichnet) ein oder schreiben sie bei komplexeren Fällen als eigenen Code-Node. Das ist kein Rückschritt an Möglichkeiten – JavaScript deckt mehr Fälle ab als eine feste Aktionsliste –, aber jede einzelne Formatter-Aktion aus dem alten Workflow muss als Ausdruck oder Codezeile neu geschrieben werden. Eine automatische Übersetzung „Formatter-Aktion X entspricht Ausdruck Y” gibt es nicht.

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

Hier liegt der am ehesten übertragbare Bauteil aus dieser Prüfmatrix. Makes Iterator löst ein Array in einzelne Bundles auf, die einzeln weiterverarbeitet werden; der Aggregator führt mehrere Bundles anschließend 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 – dasselbe Muster, andere Namen. Die Denkfigur „aufteilen, einzeln verarbeiten, wieder zusammenführen” überträgt sich direkt; was sich unterscheidet, ist die Bedienung der einzelnen Nodes und die Feldauswahl dabei.

Fehlerbehandlung: drei unterschiedliche Sicherheitsnetze

Dieser Bauteil hat in keinem der drei Tools ein Gegenstück in einem anderen. Zapier trennt zwei Mechanismen: Autoreplay wiederholt einen fehlgeschlagenen Schritt automatisch bis zu fünf Mal über einen Zeitraum von rund zehneinhalb Stunden, ohne dass Sie währenddessen eine Fehlermail bekommen; scheitert auch der letzte Versuch, kommt genau eine Benachrichtigung. Getrennt davon lässt sich über Custom Error Handling ein alternativer Pfad definieren, der bei einem Fehler statt des Hauptpfads läuft.

Make bietet fünf Direktiven, die Sie an einzelnen Modulen befestigen: Ignore und Resume lassen die Ausführung weiterlaufen, Commit und Rollback beenden sie kontrolliert, und Break verschiebt den betroffenen Datensatz in die „Incomplete Executions”, wo Make eine begrenzte Zahl automatischer Wiederholungsversuche unternimmt, bevor eine manuelle Prüfung nötig wird; Anzahl und Abstand der Versuche lassen sich in den Szenario-Einstellungen konfigurieren.

n8n trennt Fehlerbehandlung ebenfalls in zwei Ebenen, aber anders geschnitten als Zapier oder Make: Pro Node stellen Sie unter „On Error” zwischen Stop Workflow, Continue und Continue (using error output) um; 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 Falle beim Nachbau: Automatisches Wiederholen („Retry On Fail”) und eine der „Continue”-Optionen lassen sich laut einem öffentlich dokumentierten n8n-Issue nicht gleichzeitig sinnvoll nutzen – ist eine „Continue”-Option aktiv, greifen die Wiederholungsversuche nicht. Prüfen Sie das vor dem Produktivbetrieb mit einem Testlauf gegen den aktuell eingesetzten n8n-Stand, weil sich das Verhalten mit künftigen Versionen ändern kann.

Ein geordneter Ablauf für den Wechsel

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

1. Bestandsaufnahme. Für jeden Zap oder jedes Szenario: Welcher Trigger-Typ, welche Verzweigungen, welche Fehlerbehandlung – anhand der Prüfmatrix oben lässt sich der Aufwand grob vorab einschätzen.
2. Mit dem einfachsten Fall anfangen. Ein linearer Workflow ohne Verzweigung ist die schnellste Bestätigung, dass Trigger und Zugangsdaten im neuen System sauber laufen, bevor komplexere Fälle folgen.
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-Trigger läuft zwar, meldet einen Ausfall aber nicht von selbst.

Für den Mittelstand heißt das

Ein Wechsel lohnt sich nicht deshalb, weil Sie ohnehin gerade das Tool wechseln wollen, sondern dort, wo eine der Prüfmatrix-Zeilen für Sie besonders schwer wiegt – etwa weil Self-Hosting oder eine ausführungsbasierte Abrechnung den Ausschlag geben. Was dabei für die Werkzeugwahl selbst zählt, arbeitet unser Vergleich der drei Tools im Detail heraus – dieser Beitrag hier setzt eine getroffene Entscheidung voraus und zeigt, was ihr Umbau konkret kostet. Rechnen Sie den Aufwand je Workflow einzeln durch, bevor Sie einen ganzen Bestand umstellen: Ein Workflow mit mehreren verschachtelten Verzweigungen und eigener Fehlerbehandlung je Schritt ist ein Vielfaches des Aufwands eines einfachen linearen Workflows. Sitzt der Hauptgrund für den Wechsel im Hosting, lohnt sich vorab ein Blick in unseren Beitrag zu n8n und DSGVO, und für den Betrieb nach dem Wechsel in unseren Beitrag zum Monitoring – ein migrierter Workflow braucht dieselbe Fehlerüberwachung wie ein neu gebauter. Wie ein erster n8n-Workflow strukturiert eingeführt wird, unabhängig davon, ob er migriert oder neu gebaut ist, beschreibt unser Leitfaden zu n8n im Mittelstand.

FAQ

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

Nein. Keiner der drei Anbieter bietet einen offiziellen Ein-Klick-Import. Es gibt Community-Werkzeuge, die eine Zapier- oder Make-Exportdatei in eine n8n-Importdatei übersetzen, aber auch deren Ergebnis ist ein Entwurf, der vor dem produktiven Einsatz geprüft werden muss – kein fertiger Workflow.

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

Am aufwendigsten sind bedingte Verzweigungen und die Fehlerbehandlung: Zapiers sequenzielle Pfade und Makes Router-Routen lassen sich nicht direkt in n8ns IF- und Switch-Nodes übertragen, und keiner der drei Anbieter bildet die Fehlerbehandlung der anderen nach – Zapiers Custom Error Handling, Makes fünf Direktiven und n8ns Kombination aus Error Trigger und Retry-Einstellung je Node folgen jeweils eigener Logik.

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 identisch – nur die Zugangsdaten müssen Sie neu einrichten, weil sich OAuth-Verbindungen nicht exportieren lassen.

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

Nein. Ein einfacher, linearer Workflow ohne Verzweigungen und mit wenigen Schritten überträgt sich schnell. Ein Workflow mit mehreren verschachtelten Pfaden, individueller Fehlerbehandlung je Schritt und Array-Verarbeitung braucht in n8n einen echten Neubau, keine Übersetzung – prüfen Sie das vor dem Wechsel je Workflow einzeln anhand der Prüfmatrix in diesem Beitrag.

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

Prüfen Sie, ob der bestehende Trigger webhook-basiert (sofort) oder polling-basiert (Abfrage in festen Abständen) arbeitet. Webhook-Trigger übertragen sich konzeptionell direkt. Bei Polling-Triggern übernimmt Zapier die Erkennung bereits verarbeiteter Datensätze automatisch über ein ID-Feld; in n8n müssen Sie diese Deduplizierung mit einem eigenen Node explizit nachbauen.