Von Make zu n8n migrieren: Ablauf, Tests und Umschaltung

Konkreter Anlass. Benennen Sie zuerst den konkreten Anlass. Vielleicht benötigt der Prozess einen genehmigten Zugriff auf interne Systeme, eine andere Betriebsform oder eine gezielt entwickelte API-Verarbeitung. Vielleicht sind Verbrauch oder Wartbarkeit des bestehenden Szenarios unbefriedigend. „n8n ist günstiger“ ist ohne vergleichbares Betriebs- und Volumenmodell noch keine ausreichende Begründung.

Aufwandsvergleich. Erfassen Sie den Ist-Aufwand einschließlich Fehlerbearbeitung und Änderungen. Stellen Sie ihm einmalige Migration, Schulung, Paralleltest und künftigen Betrieb gegenüber. Falls die aktuelle Lösung zuverlässig und wirtschaftlich arbeitet, kann eine begrenzte Verbesserung sinnvoller sein als ein vollständiger Wechsel. Die Migration braucht einen erwarteten Nutzen, an dem sie später gemessen werden kann.

Erster Prozess. Verwenden Sie einen abgegrenzten Prozess als erste Übertragung. Ein Szenario mit klaren Eingängen, einem überschaubaren Zielsystem und guten Ergebnisreferenzen lässt sich leichter abnehmen als eine unübersichtliche Kette vieler voneinander abhängiger Szenarien.

Kein verdeckter Umbau. Verbinden Sie die Plattformmigration nicht mit einem unerklärten Umbau des gesamten Geschäftsprozesses. Notwendige Verbesserungen bleiben möglich, sollten aber gesondert benannt und freigegeben werden, damit der Vergleich aussagekräftig bleibt.

Make-Blueprint. Make beschreibt Blueprints als wiederverwendbare Darstellung von Modulen, Einstellungen und Zuordnungen; Verbindungen müssen bei der Nutzung in einem anderen Konto neu eingerichtet werden. Siehe offizielle Blueprint-Anleitung, geprüft am 26. September 2026. Behandeln Sie den Export als Bestandsaufnahme und Rekonstruktionshilfe.

n8n-Import und -Export. n8n verwendet eigene Import- und Exportverfahren für seine Workflows. Dass beide Systeme JSON-Dateien verwenden, begründet keine direkte Kompatibilität. Die n8n-Dokumentation zum Import und Export beschreibt das eigene Format und die verfügbaren Wege. Eine gegebenenfalls eingesetzte Konvertierung ist nur ein Ausgangspunkt und muss fachlich geprüft werden.

Außerhalb des Szenarios. Sichern Sie vor Änderungen zusätzlich Zeitpläne, Verbindungsübersicht, Variablen, Datenablagen, offene Ausführungen und Einstellungen außerhalb des sichtbaren Szenarios. Ein Screenshot zeigt nicht, welche Daten ein dauerhaft verwendeter Speicher enthält oder wer eine Verbindung erneuern kann.

Für jedes Szenario sollten folgende Angaben vorliegen:

Erfolgsnachweis. Ergänzen Sie je Zielaktion, wie ein Erfolg nachgewiesen wird. Eine Antwort mit Ziel-ID ist ein stärkerer Beleg als die Annahme, dass ein grüner Schritt immer die erwartete Wirkung hatte. Diese Zielreferenzen werden beim Parallelvergleich besonders wertvoll.

Abhängigkeiten. Erfassen Sie auch Abhängigkeiten zwischen Szenarien. Ein scheinbar unabhängiger Workflow kann auf eine Tabelle angewiesen sein, die an anderer Stelle aktualisiert wird, oder auf eine geplante Bereinigung, die seine Eingaben verändert. Der Migrationsumfang sollte diese Beziehungen einschließen, auch wenn das abhängige Szenario in Make bleibt.

Sammeln, teilen, zusammenführen. Untersuchen Sie jede Stelle, an der Daten gesammelt, geteilt oder zusammengeführt werden. Ein einzelner Geschäftsvorgang kann mehrere technische Elemente enthalten. Eine Anfrage mit drei Anhängen sollte beispielsweise nicht versehentlich drei Kundenaufträge erzeugen. Prüfen Sie dieses Verhalten ausdrücklich in beiden Versionen.

Leere Werte und Formate. Vergleichen Sie leere Werte, fehlende Felder und explizite Nullwerte. Ein Filter, der im bisherigen Aufbau „nicht vorhanden“ erkennt, kann im neuen Datenmodell eine Anpassung benötigen. Ebenso sollten Textzahlen mit führenden Nullen, Dezimaltrennzeichen und Datumsangaben getestet werden.

Regeln in normaler Sprache. Beschreiben Sie jede Bedingung zunächst in normaler Sprache: „Nur freigegebene Vorgänge mit genau einem Kundenbezug dürfen einen Auftrag anlegen.“ Danach setzen Sie diese Regel in n8n um. So bleibt die fachliche Absicht sichtbar, auch wenn die technische Darstellung anders aussieht.

Annahmen zur Reihenfolge. Halten Sie Annahmen zur Reihenfolge fest. Erwartet ein Prozess, dass Datensätze chronologisch eintreffen, klären Sie, ob die Quelle diese Reihenfolge tatsächlich garantiert. Eine Migration ist eine gute Gelegenheit, eine bestehende Annahme sichtbar zu machen; die daraus folgende Korrektur braucht trotzdem eine ausdrückliche Freigabe.

Verwenden Sie zulässige, bereinigte oder synthetische Eingaben mit bekannten Soll-Ergebnissen. Eine gute Auswahl enthält Normalfälle sowie wenige bewusst schwierige Fälle:

• keine Anhänge
• mehrere Anhänge
• fehlender Kunde
• mehrfacher Kunde
• doppelte Zustellung
• ungewöhnliche Zeichen
• ein zeitlicher Grenzfall

Ausfall eines Ziels. Nehmen Sie außerdem einen Fall auf, bei dem ein Zielzugriff vorübergehend fehlschlägt. Der Vergleich sollte zeigen, welche Vorgänge warten, welche abgewiesen werden und welche abgeschlossen sind. Zwei Workflows können dieselbe Zahl erfolgreicher Läufe haben und trotzdem unterschiedliche Aufträge erzeugen.

Umfang. Dokumentieren Sie den Umfang ehrlich. Ein Test mit 20 sorgfältig gewählten Fällen ist kein Nachweis für beliebige Last oder jedes seltene Datenformat. Er liefert aber eine nachvollziehbare Grundlage, auf der weitere Prüfungen gezielt ergänzt werden können.

Unabhängige Sollergebnisse. Legen Sie die erwarteten Ergebnisse unabhängig von der Ausgabe beider Plattformen fest. Enthält das alte Szenario einen Fehler, würde ein exaktes Kopieren seiner Ergebnisse diesen Fehler erhalten. Die fachlich verantwortliche Person sollte das richtige Ergebnis festlegen und jede bewusste Abweichung vom bisherigen Verhalten freigeben.

Das folgende Beispiel ist konstruiert und wurde nicht als Live-Integration getestet. Ein Make-Szenario erhält Serviceanfragen, sucht Kunden, legt einen CRM-Vorgang an und speichert Unterlagen. Der neue n8n-Ablauf soll dieselbe Aufgabe erfüllen.

Für die Abnahme werden sechs Fälle festgelegt:

Vergleich nach Anfrage-ID. Im ersten Durchlauf schreibt n8n ausschließlich in kontrollierte Testziele oder erzeugt einen vorgesehenen Ergebnisentwurf. Ein Vergleich ordnet Ausgaben nach Anfrage-ID zu. Feldwerte, Zielaktionen und Ausnahmezustände werden einzeln verglichen. Eine bloße Gegenüberstellung der Gesamtsummen würde beispielsweise eine fehlende und eine doppelte Anfrage gegenseitig verdecken.

Unterschiede. Wenn ein Unterschied auftritt, entscheiden Sie, ob ein Fehler oder eine bewusst gewünschte Änderung vorliegt. Gewünschte Änderungen werden separat freigegeben. Eine Migration sollte nicht unbemerkt neue Geschäftsregeln einführen, nur weil die neue Plattform eine andere Standardoption anbietet.

Eine verbindliche Version. Im Vergleichsbetrieb darf nur eine Version verbindliche Zielaktionen ausführen. Die zweite liest genehmigte Eingangsdaten und berechnet ihr erwartetes Ergebnis, ohne Kunden erneut zu benachrichtigen oder zusätzliche Aufträge anzulegen. Kennzeichnen Sie technische Testziele eindeutig.

Nebenwirkungen des Lesens. Prüfen Sie, ob bereits das Lesen Nebenwirkungen hat. Manche Eingangskanäle markieren Nachrichten, verschieben Dateien oder verändern eine Abrufposition. Wenn beide Versionen dieselbe Quelle beeinflussen, kann der Vergleich selbst Daten verändern. Verwenden Sie dann einen geeigneten aufgezeichneten Eingang oder eine kontrollierte Kopie.

Dauer. Der Vergleich muss lang genug laufen, um die relevanten Betriebsfälle abzudecken: Monatswechsel, übliche Spitzen oder eine bestimmte periodische Aufgabe. Die Dauer ergibt sich aus dem Prozess; eine pauschale Anzahl Tage beweist keine Vollständigkeit.

Regelmäßiger Abgleich. Gleichen Sie die Ergebnisse des Shadow-Betriebs regelmäßig ab, statt bis zum Ende zu warten. Frühe Abweichungen zeigen oft Annahmen zu Feldzuordnung oder Zustand, die korrigiert werden sollten, bevor der Vergleich einen großen Rückstand unerklärter Ergebnisse erzeugt.

Offene Fälle. Vor der Umschaltung benötigen Sie eine Liste offener Fälle mit eindeutigen IDs und Bearbeitungsstand. Trennen Sie neue Eingänge, wartende Wiederholungen, fachliche Klärungen und teilweise erledigte Vorgänge. Für jede Gruppe wird entschieden, ob sie im alten System abgeschlossen oder kontrolliert im neuen fortgesetzt wird.

Zuordnungen. Übertragen Sie nötige Zuordnungen zwischen Quell- und Ziel-IDs. Übernehmen Sie dabei keine unnötigen historischen Daten, nur weil sie verfügbar sind. Entscheidend ist, welcher Zustand zur sicheren Fortsetzung und zum Nachweis benötigt wird.

Bestätigte Schreibaktionen. Eine wichtige Prüfung betrifft bereits bestätigte Schreibaktionen. Wenn das neue System nur den Eingang kennt, aber nicht die vorhandene Ziel-ID, könnte es denselben Vorgang erneut anlegen. Der Zustandsabgleich muss deshalb vor dem Freigeben produktiver Schreibrechte erfolgen.

Offene Freigaben. Liegt eine offene menschliche Freigabe vor, entscheiden Sie, ob sie nach der Migration gültig bleibt. Eine Freigabe kann sich auf einen früheren Datenstand beziehen. Ändert sich der Vorschlag, ist eine neue Entscheidung oft angemessener, als eine veraltete Freigabemarkierung zu übernehmen.

Entscheidung und Zeitfenster. Vereinbaren Sie einen Verantwortlichen für die Umschaltentscheidung und ein nachvollziehbares Zeitfenster. Dokumentieren Sie den letzten durch Make bearbeiteten Eingang beziehungsweise die letzte bestätigte Position. Stoppen Sie anschließend die vorgesehenen alten Auslöser und warten Sie auf laufende Vorgänge oder behandeln Sie diese ausdrücklich.

Erste produktive Fälle. Richten Sie den neuen Eingang ein, prüfen Sie seine Erreichbarkeit und kontrollieren Sie die erste kleine Gruppe produktiver Fälle. Gleichen Sie Eingänge, bestätigte Ziele und offene Ausnahmen ab. Wenn der Abgleich nicht stimmt, pausieren Sie weitere Schreibaktionen und untersuchen die Ursache.

Webhooks und Zeitpläne. Bei Webhooks gehört die Änderung der Empfängeradresse zum Plan. Bei zeitgesteuerten Abfragen gehört die Startposition dazu. Bei beiden müssen mögliche doppelte oder verspätete Ereignisse beherrscht werden. Verlassen Sie sich nicht darauf, dass ein Anbieterwechsel exakt zu einer scharfen Zeitgrenze ohne Überlappung erfolgt.

Umschaltprotokoll. Führen Sie ein kurzes Umschaltprotokoll mit den Maßnahmen und den beobachteten Ergebnissen. Es sollte festhalten, wann die alte Verarbeitung endete, wann die neue begann und welche Vorgänge während des Übergangs bearbeitet wurden. Das ist ein nützlicher Nachweis, wenn ein Kunde später nach einem einzelnen Vorgang fragt.

Kein einfacher Schalter. Ein Rückfall ist nicht einfach das erneute Einschalten des alten Szenarios. n8n kann inzwischen gültige Zielaktionen durchgeführt haben, die Make noch nicht kennt. Der Rückfallplan muss diese Ergebnisse erfassen und in die Fortsetzung einbeziehen.

Rückfallkriterien. Definieren Sie vorher Rückfallkriterien, etwa nicht erklärbare Ergebnisunterschiede oder eine nicht rechtzeitig beherrschbare Schnittstellenstörung. Halten Sie außerdem fest, welche Änderungen nach der Umschaltung eine automatische Rückkehr erschweren. Bereits versendete Nachrichten lassen sich nicht durch Rückspielen einer Workflow-Datei zurücknehmen.

Aufbewahrung und Stilllegung. Bewahren Sie alte Konfiguration und benötigte Nachweise für den vereinbarten Zeitraum auf, ohne unnötig dauerhaft aktive Zugänge zu behalten. Nach erfolgreicher Abnahme werden überflüssige Trigger, Konten und Verbindungen kontrolliert stillgelegt. Die Migration endet erst, wenn neue Betriebsverantwortung, Abgleich und Ausstieg aus dem alten Betrieb vollständig geklärt sind.

Umschaltfenster festhalten. Eine Rückkehr nach der Umschaltung bedeutet nicht, einfach den alten Zeitplan wieder einzuschalten. Der neue Workflow könnte bereits einige Aufgaben erstellt haben. Notieren Sie deshalb für das Umschaltfenster die Eingangsvorgänge, deren Zielreferenzen und den letzten eindeutig bestätigten Zustand. Erst nach diesem Abgleich lässt sich bestimmen, welche Vorgänge der alte Ablauf noch übernehmen darf.

Synthetisches Beispiel. Ein synthetischer Fall verdeutlicht den Unterschied: Von 40 eingegangenen Anfragen wurden 25 vollständig in n8n bearbeitet, fünf haben einen Kontakt, aber noch keine Aufgabe, und zehn wurden nicht begonnen. Ein pauschales Wiederholen aller 40 in Make könnte doppelte Aufgaben und widersprüchliche Kontaktänderungen auslösen. Die 25 abgeschlossenen Fälle werden ausgeschlossen, die fünf Teilfälle gezielt geklärt und die zehn offenen Fälle kontrolliert übernommen. Die genauen Zahlen sind frei gewählt; entscheidend sind die getrennten Zustände.

Die Tabelle zeigt die drei Zustände des synthetischen Beispiels und ihre Behandlung.

Freigabe und Ersatzweg. Legen Sie vorab fest, wer diese Rückkehr freigibt und welche Unterlagen dafür vorliegen müssen. Während der Klärung braucht der Fachbereich einen Ersatzweg für dringende Vorgänge. Nach der Rückkehr werden Mengen und Ergebnisse erneut geprüft. Ein technischer Schalter allein ist weder ein vollständiger Rückfallplan noch ein Nachweis, dass keine Arbeit verloren ging.

Übergangszeit. Bewahren Sie die alte Konfiguration nur so lange mit aktiven Verbindungen auf, wie der vereinbarte Übergang sie benötigt. Danach werden nicht mehr benötigte Zugänge entzogen und verbliebene offene Vorgänge ausdrücklich abgeschlossen oder übertragen.

Diese Seiten behandeln die Leistungsübersicht und die angrenzenden Entscheidungen für eine Migration von Make zu n8n:

• n8n-Agentur: Umsetzung und Betrieb von Unternehmensworkflows
• n8n, Make oder Power Automate: Entscheidung nach Prozess
• n8n-Fehlerbehandlung: Wiederholungen ohne doppelte Aktionen
• n8n-Projekt übergeben: Dokumentation, Tests und Eigentum

Für eine konkrete Ablaufprüfung reichen zunächst eine Prozessbeschreibung, die beteiligten Systeme und typische Ausnahmen. Mit modernagents besprechen.