Von Zapier zu n8n migrieren, ohne den Betrieb anzuhalten: in Wellen, im Parallelbetrieb, mit Rückweg

Bevor du einen einzigen Zap bewegst: das Inventar, das die Reihenfolge bestimmt

Fast jeder, der nachschlägt, wie man von Zapier zu n8n migriert, fängt gleich an: n8n öffnen und den ersten Flow bauen. Falsche Reihenfolge. Bauen kommt nicht zuerst. Zuerst kommt zu wissen, was bei dir läuft, was was aufruft und in welcher Reihenfolge man etwas abschalten kann, ohne dass dahinter etwas anderes umkippt.

Die Entscheidung ist gefallen. Wer noch beim «wechseln oder nicht?» steht, klärt das in Alternativen zu Zapier für Unternehmen und in n8n vs Make vs Zapier. Dieser Leitfaden fängt da an, wo jene aufhören: Du weißt, wohin du willst, jetzt musst du ankommen, ohne das Licht auszumachen.

Das Inventar ist keine Liste von Zap-Namen. Es ist ein kurzer Steckbrief pro Flow, sechs Angaben und keine mehr:

• Was ihn auslöst. Ein Webhook, ein Zeitplan oder eine Änderung in einer App. Die Webhook-Fälle tun am meisten weh, und gleich siehst du warum.
• Welche Apps er anfasst, getrennt nach Lesen und Schreiben. Was er schreibt, ist das, was ein echtes System durcheinanderbringt, wenn beide Flows gleichzeitig laufen.
• Wer ihn von außen aufruft. Ein Formular, die Oberfläche eines anderen Anbieters, das Skript von irgendwem. Das ist die Spalte, die niemand ausfüllt, und die für den Schreck sorgt.
• Was passiert, wenn er eine Stunde steht. «Ist wichtig» zählt nicht: Was geht verloren und wer merkt es.
• Mit welchem Konto er sich bei jeder App verbindet, und wem dieses Konto gehört.
• Wer ihn versteht, mit Vor- und Nachnamen. Lautet die Antwort «niemand», wird dieser Flow noch nicht migriert: erst wird er entschlüsselt.

Das erste Hindernis ist eine Tariffrage. Zapier lässt dich die Zaps als JSON aus den Kontoeinstellungen exportieren, im Bereich Sicherheit und Daten, aber nur in Team und Enterprise: in Free und Professional gibt es den Knopf nicht. Wenn du auf Professional bist —wo viele mittelständische Unternehmen sitzen— entsteht das Inventar von Hand, Zap für Zap, und dieser Nachmittag gehört ins Angebot.

Mit dem Inventar vor Augen ergibt sich die Reihenfolge von selbst. Man migriert nicht vom Einfachen zum Schweren, sondern vom Umkehrbaren zum Unumkehrbaren. Eine interne Benachrichtigung kann man falsch migrieren und in zehn Minuten reparieren. Ein Flow, der eine Rechnung stellt oder einem Kunden eine Mail schickt, verträgt kein «machen wir morgen».

In Wellen, nicht auf einen Schlag: Stücke, die sich zurücknehmen lassen

Der teuerste Fehler einer Migration ist nicht technisch, er ist eine Frage der Größe. Alle vierzig Flows an einem Wochenende zu verschieben heißt: Wenn am Montag etwas ausfällt, debuggst du vierzig Dinge gleichzeitig. In Wellen zu migrieren heißt nicht, langsam zu sein — es heißt, die Ursache benennen zu können.

Eine Welle ist eine Gruppe von Flows, die gemeinsam migriert, beobachtet und abgenommen werden — und die gemeinsam an Zapier zurückgegeben werden können. Vier reichen meistens:

1. Welle null: die Installation. Kein einziger Geschäftsflow. n8n wird aufgesetzt, die Zugangsdaten der Apps verbunden, die überall auftauchen, und der Fehler-Flow gebaut. Wer sie überspringt, macht die nächsten drei blind.
2. Welle eins: das Umkehrbare. Interne Benachrichtigungen, Berichte, Synchronisationen, die man neu anstoßen kann. Hier lernst du das Werkzeug, wenn ein Fehler fast nichts kostet.
3. Welle zwei: das Volumen. Die langen Flows mit viel Verkehr — genau die, die die Migration begründet haben.
4. Welle drei: Kunde und Geld. Rechnungsstellung, Verträge, Mails nach außen, Schreibzugriffe im ERP. Zuletzt, mit langem Parallelbetrieb und jemandem, der hinschaut.

Und eine Welle ist nicht vorbei, wenn der neue Flow läuft. Sie ist vorbei, wenn vier Dinge gelten: Er liefert seit einem vereinbarten Zeitraum dasselbe Ergebnis wie der alte, seine Alarme sind gebaut und getestet, jemand, der ihn nicht gebaut hat, kann ihn lesen, und der ursprüngliche Zap ist abgeschaltet, aber nicht gelöscht. Solange eines fehlt, startet die nächste Welle nicht.

Was nicht kopiert wird: der lineare Zap mit dreißig Schritten wird neu entworfen

Hier ist die Versuchung, die gut laufende Migrationen ruiniert: den Zap öffnen, die Schritte zählen und dieselben dreißig Knoten einen nach dem anderen in n8n nachbauen. Heraus kommt ein Flow, der am ersten Tag läuft und den im sechsten Monat niemand pflegen kann: Du hast wörtlich eine Struktur übersetzt, die nur wegen einer Grenze des alten Werkzeugs existierte.

Zapier ist eine Kette: ein Auslöser und eine Reihe Schritte. Wenn zwei Wege nötig sind, wird der Prozess üblicherweise in mehrere Zaps zerlegt, die über ein Zwischenfeld aneinanderhängen. n8n ist eine Leinwand mit Verzweigungen, Schleifen und Subflows, und diese mit Klebeband zusammengehaltene Zap-Sammlung schrumpft meistens auf einen einzigen Flow mit zwei Zweigen. Das ist der Unterschied zwischen «in einem Jahr noch änderbar» und «traut sich keiner mehr anzufassen».

Achtung: nicht alles wird neu entworfen. Der Zwei-Schritt-Flow, der eine Sache tut und sie gut tut, wird eins zu eins übernommen. Die Regel passt in eine Zeile: Erklärt er sich in einem Satz, kopieren; brauchst du einen Absatz und ein «außer wenn», neu entwerfen.

Automatische Konverter: Ausgangspunkt, nie Lieferung

Weder Zapier noch n8n bieten eine offizielle Brücke zwischen beiden Plattformen. Was es gibt, sind Konverter von Drittanbietern, die das exportierte JSON lesen und einen ungefähren n8n-Flow zurückgeben. Sie sind nützlich und nehmen den mechanischen Teil ab: Feldzuordnung, Namen, grobe Form. Nutze sie.

Und behandle sie dann als das, was sie sind: einen Entwurf. Ein Konverter übersetzt die Struktur, und die Struktur ist genau das, was du nicht kopieren wolltest. Er bringt keine Zugangsdaten, baut keine Fehlerbehandlung und kann nicht sehen, dass diese drei Zaps in Wahrheit ein Prozess sind. Die Ausgabe eines Konverters abzuliefern heißt, das Problem übersetzt abzuliefern.

Zugangsdaten und OAuth: hier steckt die eigentliche Arbeit

Frag irgendjemanden, der diese Migration gemacht hat, was die Stunden gefressen hat, und er wird nicht die Logik nennen: er wird die Zugänge nennen. Ein Export trägt die Struktur des Flows, nie den Schlüssel für die Apps. Das ist kein Mangel der Konverter: Zugangsdaten leben in der Verbindung, nicht im Schritt.

Zapiers eigene Dokumentation sagt das selbst für den einfachsten Fall, den Import von Zaps innerhalb von Zapier: Danach musst du sie einschalten und die App-Verbindungen testen und die nicht mehr aktiven neu verbinden. Zwischen zwei verschiedenen Plattformen wird alles neu authentifiziert, eine nach der anderen, von Hand. Drei Fallen machen aus diesem Nachmittag eine Woche:

• Das persönliche Konto. Ein halbes Dutzend Verbindungen laufen üblicherweise über das Konto einer bestimmten Person. Die Migration ist die einzige billige Gelegenheit, alles auf Servicekonten umzustellen; wiederholst du das Muster, hast du die Schuld nur verschoben.
• Die OAuth-Berechtigungen. Eine neue Anwendung gegen Google Workspace, Microsoft 365 oder Salesforce freizugeben kann nicht immer die Person, die den Flow baut: In vielen Unternehmen gibt das ein Administrator frei. Das ist kein Klick, das ist ein Ticket mit einer Vorlaufzeit, die du nicht kontrollierst. Beantrage es in Welle null.
• Die Webhook-Adressen. Ein per Webhook ausgelöster Zap hat eine URL, die an Stellen klebt, die du nicht kontrollierst. Beim Migrieren ändert sie sich. Aktualisiert niemand die Quelle, fällt der neue Flow nicht aus: er bekommt schlicht nichts.

Parallelbetrieb: beide laufen, bis das Abschalten langweilig wird

Parallelbetrieb ist der Zeitraum, in dem der alte und der neue Flow dasselbe gleichzeitig verarbeiten und du ihre Ergebnisse vergleichst, bevor du einen abschaltest. Er macht aus der Umstellung —dem Moment, der Angst macht— eine Formalie: Wenn du den Zap abschaltest, weißt du bereits mit Daten vor dir, dass der n8n-Flow dasselbe tut.

Eine Falle muss vorher gelöst werden: Wenn beide an dieselbe Stelle schreiben, hast du gerade jede Bestellung und jede Rechnung verdoppelt. Deshalb läuft der neue Flow im Schattenbetrieb: Er liest aus der echten Quelle und schreibt in ein paralleles Ziel. Das echte Ziel bekommt er erst, wenn der Vergleich keine Überraschungen mehr liefert. Und vergleichen heißt nicht «sieht gut aus». Es sind vier Dinge:

1. Die Anzahl. Sind in beiden dieselben Fälle angekommen? Hat der neue weniger verarbeitet, hast du einen falsch gebauten Auslöser oder einen Filter zu viel.
2. Der Inhalt Feld für Feld, an einer echten Stichprobe. Hier kommen Datumsformate, Nachkommastellen und das leere Feld heraus, weil es anders hieß.
3. Die seltsamen Fälle, mit Absicht. Die Bestellung ohne Kunden, die Mail ohne Betreff, der Betrag null. Der Happy Path stimmt immer überein; die Migration bricht an der Handvoll, die nicht passt.
4. Der Kalender. Lass den Monatsabschluss oder den Rechnungslauf vorbeigehen — alles, was nur am Ersten passiert.

Wie lange der Parallelbetrieb dauert, misst man nicht in Tagen, sondern in gesehenen Fällen. Ein Flow, der tausendmal am Tag feuert, hat seine Vielfalt in einer Woche durch. Einer, der bei einer Ausschreibung feuert, wartet auf eine Ausschreibung. Der Umstellung ein festes Datum zu geben ist die elegante Art, zu früh zu schneiden.

Alarme und Rückweg: vor der Umstellung gebaut, nicht danach

Ein migrierter Flow ist nicht fertig, wenn er läuft. Er ist fertig, wenn du mitbekommst, dass er aufgehört hat zu laufen, und ohne Improvisation zurückkannst. Beides wird gebaut, bevor irgendetwas abgeschaltet wird, denn danach baut es niemand mehr: Sobald der neue Flow läuft, wandert die Aufmerksamkeit zur nächsten Welle.

In n8n hat das einen konkreten Namen. Du legst einen separaten Flow an, der mit dem Knoten Error Trigger beginnt, und wählst ihn in den Einstellungen jedes wichtigen Flows als Fehler-Flow aus. Und Vorsicht bei einem Detail aus n8ns eigener Dokumentation, das viele erwischt: Dieser Fehler-Flow lässt sich mit einem manuellen Lauf nicht testen, weil der Error Trigger nur auslöst, wenn eine automatische Ausführung fehlschlägt. Teste ihn, indem du einen echten Fehler provozierst, sonst erfährst du an dem Tag, an dem du ihn brauchst, dass er nie funktioniert hat.

Das deckt ab, was laut ausfällt. Was leise stirbt —der Flow, der nichts mehr bekommt, weil niemand die Webhook-URL aktualisiert hat— erwischt kein Alarm, weil es keinen Fehler gibt: es gibt nichts. Auf Abwesenheit zu achten ist die andere Hälfte der Arbeit und steht in Ausfälle in Automatisierungen erkennen.

Der Rückweg ist das Billigste zum Aufschreiben und das, was niemand aufschreibt. Pro Welle drei Sätze: welcher Zap wieder eingeschaltet wird, welcher n8n-Flow abgeschaltet wird und wo die Webhook-URL zurückgesetzt gehört. Wenn sich das nicht in fünf Minuten und ohne Rückfrage ausführen lässt, hast du keinen Plan: du hast eine Absicht.

Wenn die letzte Welle schließt, hast du nicht «dasselbe, nur in n8n»: Du hast neue Flows, die ab morgen betrieben werden müssen. Da beginnt die Arbeit, sie am Leben zu halten und zu steuern, was sie tun. Wie man n8n so aufsetzt, dass es ein echtes Unternehmen trägt, steht in n8n für Unternehmen; die ganze Karte im Leitfaden zum Automatisieren mit KI.