Zapier zu Make migrieren: Praxis-Guide für 2026

Ich habe in den letzten zwei Jahren mehrere Kunden-Workflows von Zapier zu Make.com migriert — meist Content-Pipelines, bei denen Branching- und Iterations-Logik aus Zapier herausgewachsen war. Das Pattern ist immer dasselbe: Zapier funktioniert, bis es nicht mehr funktioniert, und dann nicht auf eine teure, umständliche Weise.

Wenn Sie “Zapier zu Make migrieren” suchen, sind Sie wahrscheinlich gegen eine der drei Wände gelaufen: eine task-basierte Rechnung, die immer weiter klettert, einen Workflow, der echtes Branching oder Loops braucht, oder eine Debug-Session, in der Zapiers Logs Ihnen nichts Brauchbares gesagt haben. Dieser Guide geht die volle Migration durch: warum es sich lohnt, wann nicht, wie Konzepte zwischen den Plattformen mappen und eine 6-Schritt-Strategie, die die Produktion nicht bricht.

Vorab eine Warnung: das ist kein “Wechsel alles morgen”-Beitrag. Manche Zaps sollten bleiben. Manche sollten gar nicht existieren. Die Entscheidung trifft man pro Workflow, nicht pro Plattform.

Warum Teams von Zapier weg gehen

Vier Gründe tauchen in fast jeder Zapier-zu-Make-Migration auf, die ich gemacht habe.

Pricing-Modell-Mismatch. Zapier rechnet pro Task, wobei ein Task grob “eine Action lief” bedeutet. Make rechnet pro Operation, wobei eine Operation grob “ein Modul lief” ist. Klingt identisch, bis Sie reale Workflows anschauen. Ein einzelnes Make-Scenario mit Router, Filter und Iterator macht die Arbeit von zehn separaten Zaps. Sie zahlen für die Operationen darin, aber der Gesamt-Operation-Count liegt typisch 30 bis 60 Prozent unter dem äquivalenten Zap-Task-Count, weil Make Branching und Transformation erlaubt, ohne separate Workflows zu feuern.

Branching und Iteration. Zapier behandelt Loops und bedingte Branches immer noch als Second-Class Citizens. Paths existieren, aber sie sind starr. Loops sind möglich mit der Looping-by-Zapier-App, aber das ist ein Workaround, der Tasks verbrennt. Make behandelt Branching (Router) und Iteration (Iterator + Aggregator) als First-Class-Module. Wenn Ihr Workflow mehr als eine “wenn das, dann das”-Entscheidung hat, passt Make besser.

Visuelles Debugging. Makes Execution-Inspector zeigt Input, Output und Timing jedes Moduls für jeden Run. Sie klicken einen Bundle, sehen das exakte JSON, das rein- und rausging. Zapiers Task-History zeigt Stages, aber das Hineinbohren in einen einzelnen Schritt ist langsamer und manchmal opak. Beim Debugging eines produktiven Workflows um 23 Uhr zählt das.

Modul-Tiefe. Bei häufigen Apps (Gmail, Slack, Google Sheets, Notion) sind beide Plattformen ungefähr gleich. Bei komplexen APIs (HubSpot, Stripe, Airtable mit fortgeschrittenen Queries) bietet Make granularere Module. Sie kommen näher an die rohe API, ohne in einen Webhook-und-HTTP-Workaround zu kippen.

Datentransformation. Makes eingebauter Function-Editor (String, Math, Date, Array, Regex) ist reicher als Zapiers Formatter. Sobald Sie ein paar Workflows mit echter String-Manipulation oder Datums-Mathematik geschrieben haben, fühlt sich Zapiers Formatter beengt an.

Wann nicht migrieren

Migrieren kostet Zeit. Wenn keiner dieser Punkte zutrifft, sparen Sie sich die Stunden:

• Sie haben zwei oder drei einfache Zaps, die funktionieren. Die Migrations-Amortisation ist länger als die Restlebenszeit dieser Zaps.
• Ihr Team lebt in der Zapier-UI, und Umschulung kostet real. Make ist mächtiger, aber weniger fehlerverzeihend, und nicht-technische Operatoren spüren die Lernkurve.
• Sie hängen an einer Zapier-only-Integration. Erst Makes App-Liste prüfen. Wenn eine kritische Integration nur in Zapier ist und keine öffentliche API zum HTTP-Aufruf hat, ist Bleiben legitim.
• Sie evaluieren ohnehin Self-Hosting. Dann überspringen Sie Make und lesen Make.com vs. n8n für Produktivlasten. Self-hosted n8n ist ein anderes Kosten- und Kontrollmodell.

Für die volle Drei-Wege-Sicht auf DE: Make vs. n8n im Vergleich.

Zapier-Konzepte und ihre Make-Äquivalente

Das mentale Modell überträgt sich direkt. Das Vokabular wechselt.

Drei Punkte zur Hervorhebung. Filter in Make ist kein Modul zum Hineinziehen, sondern eine Eigenschaft auf der Verbindung zwischen zwei Modulen. Rechtsklick auf die Linie zwischen Modul 3 und 4, “Set up a filter”, fertig. Fühlt sich anfangs seltsam an, dann offensichtlich.

Router ersetzt Zapier-Paths. Er nimmt einen Input-Bundle und schickt ihn auf beliebig viele Branches mit eigenem Filter. Anders als Zapier-Paths kann ein Router in einem Router stehen, und Module nach dem Router können Branches wieder zusammenführen.

Data Store ersetzt sowohl Zapier Tables als auch Storage. Er ist schema-aware (Sie definieren Felder und Typen), persistent und aus jedem Scenario der Org abfragbar. Es gibt keinen direkten Import aus Zapier Tables — CSV-Export und Re-Upload einplanen.

Die 6-Schritt-Migrationsstrategie

Das ist die Sequenz, die ich für jede Kunden-Migration nutze. Sie ist absichtlich langweilig. Langweilig ist, was Produktion braucht.

1. Inventur. Alle aktiven Zaps auflisten. Nach Kritikalität gruppieren: produktiv-kritisch (Geld bewegt sich, Kundennachrichten gehen raus), operational (interne Notifications, Reports), nice-to-have (kosmetische Automatisierungen). Zapiers Dashboard erlaubt Export, oder Sie scrapen kleinen Accounts manuell. Jeden Zap mit den genutzten Integrationen taggen. Sie nutzen die Gruppierung in Schritt 5.

2. Pilot. Einen unkritischen Zap wählen. In Make nachbauen. 1-2 Wochen parallel laufen lassen. Der Parallel-Run ist entscheidend: nur so fangen Sie Edge Cases, die Test-Runs nicht abdecken (seltene Input-Formen, Rate-Limit-Verhalten, Zeitzonen-Eigenheiten).

3. Validierung. Outputs nebeneinander vergleichen. Error-Pfade explizit prüfen: einen absichtlichen Fehler triggern, prüfen, dass Makes Error-Handler ihn fängt, prüfen, dass das downstream-System dasselbe Ergebnis erhält wie von Zapier. Retry-Verhalten prüfen (Make retried nicht automatisch wie Zapier — mehr dazu unten).

4. Cutover. Den Zap deaktivieren. Make-Scenario aktivieren. 48 Stunden überwachen. Den Zap im Off-Zustand belassen, nicht löschen, damit Sie in 30 Sekunden zurückrollen können.

5. In Batches nach Connection migrieren. Wenn Sie sechs Gmail-Zaps haben, migrieren Sie alle sechs zusammen, sodass Sie die Gmail-Connection einmal authentifizieren und das Connection-Verhalten einmal testen. Genauso für Slack, Notion, Stripe. Batching nach geteilter Connection ist schneller als Batching nach Kritikalität.

6. Zapier abschalten. Sobald über einen vollen Billing-Zyklus nichts mehr aktiv ist, Subscription kündigen. Task-History vorher exportieren, falls Sie den Audit-Trail brauchen.

Eines mache ich immer in Schritt 2: für jeden migrierten Workflow eine einseitige Doku, die Trigger, Outputs, Failure-Modi und Rollback-Plan beschreibt. Zwei Monate später, wenn etwas Komisches passiert, ist diese Doku der Unterschied zwischen 10-Minuten-Fix und 2-Stunden-Archäologie.

Häufige Zap-Patterns übersetzen

Drei Patterns decken vielleicht 80 Prozent realer Zapier-Workflows ab.

“Neue Zeile in Sheets, sende E-Mail”. In Zapier: Google-Sheets-Trigger > Gmail-Action, vielleicht ein Formatter-Schritt dazwischen. In Make: Google-Sheets-“Watch Rows”-Trigger > Gmail-“Send an Email”-Action. Die Formatter-Arbeit wandert inline in das Body-Feld des Gmail-Moduls über Make-Funktionen — kein Zwischenmodul. Operation-Count: 2 pro Zeile, gleich Zapiers 2 Tasks.

“Webhook, Filter, Slack-Nachricht”. In Zapier: Webhook-Catch > Filter > Slack-Post. In Make: Custom-Webhook-Trigger > Filter (auf der Verbindung gesetzt) > Slack-“Create a Message”-Action. Der Filter verbraucht in Make keine Operation. Drei Zapier-Tasks werden zu zwei Make-Operationen.

“Schedule, API-Call, Bedingung, Notion-Update”. Hier zieht Make davon. In Zapier bräuchten Sie einen Schedule-Trigger, eine HTTP-Action, Paths für die Bedingung und separate Branches mit jeweils eigener Notion-Action. In Make: Schedule-Trigger > HTTP-Request > Router mit Filtern auf jedem Branch > Notion-Actions. Sauberer zu lesen, billiger im Lauf, und Sie können die Branches danach mergen, falls Sie einen finalen Logging-Step brauchen.

Bei KI-Workflows (OpenAI-, Anthropic-Calls) handhaben beide Plattformen das einfache “Text rein, Text raus”-Pattern problemlos. Sobald Sie über eine Liste iterieren wollen mit KI-Calls pro Item, ist Make näher an n8ns Flexibilität. Wenn Sie LLM-Anbieter vergleichen, deckt Claude API vs. OpenAI für Business-Automatisierung ab, welcher zu welcher Automation-Form passt.

Kostenrechnung, die wirklich trägt

Echte Zahlen aus den veröffentlichten Preisen, 2026.

Die Übersetzung ist nicht 1:1. Ein Zapier-Task ist ein Action-Schritt. Eine Make-Operation ist ein Modul-Run, und ein Scenario hat typisch drei bis sechs Module. Also: 1.000 Workflows pro Monat, jeder mit einem Trigger plus zwei Actions, sind 1.000 Task-Äquivalente auf Zapier, aber rund 3.000 bis 4.000 Operationen auf Make (Trigger-Modul mitgerechnet).

Worked Example: 1.000 Workflows pro Monat. Auf Zapier Professional sind das 1.000 von 2.000 Tasks, also 73 $/Monat. Auf Make Core mit 4.000 Operationen sind Sie locker im 10.000-Op-Bucket, also 10,59 $/Monat. Mit wachsendem Volumen wird die Lücke grösser, weil Make-Per-Op-Pricing schneller fällt als Zapier-Per-Task.

Wo es kippt: wenn Ihre Make-Scenarios 10+ Module haben (schweres Branching, Iteration, viele Transformationen), klettert der Operation-Count schnell. Ein 12-Modul-Scenario, das 1.000-mal monatlich läuft, sind 12.000 Ops und schiebt Sie in den nächsten Make-Tier. Meist immer noch günstiger als Zapier auf dem Volumen, aber nicht in der Marge, die einfache Mathematik suggeriert.

Die Stolpersteine, vor denen niemand warnt

Dinge, die ich vor der ersten Migration gerne gewusst hätte.

Error-Handling ist Ihre Aufgabe. Zapier retried fehlgeschlagene Tasks im Hintergrund. Make nicht. Wenn ein HTTP-Call mit 500 fehlschlägt, scheitert das Scenario, der Bundle ist verloren, Sie kriegen eine E-Mail. Sie müssen explizit eine Error-Handler-Route an jedes potenziell fehlschlagende Modul hängen, entscheiden zwischen Retry, Ignore oder Dead-Letter-Queue. Nicht überspringen.

Rate-Limits sind ebenfalls Ihre Aufgabe. Zapier throttelt Requests an externe APIs basierend auf Plan-Limits und API-Spezifika. Make läuft so schnell, wie die API erlaubt — heisst: Sie können Rate-Limits schneller treffen als auf Zapier. Bei APIs mit engen Limits (HubSpot, Shopify Admin) explizite Sleep-Module ergänzen oder die Max-Operations-pro-Intervall am Scenario konfigurieren.

Webhook-URLs ändern sich. Jeder migrierte Webhook-Trigger bekommt eine neue Make-URL. Sie müssen jedes Upstream-System (Stripe, Ihre eigene App, Drittanbieter), das die alte Zapier-URL ansprach, aktualisieren. Spreadsheet aller Webhooks führen — alte URL, neue URL, welche Upstream-Systeme darauf zeigen. Jeden Upstream einzeln cutovern.

Zeitzonen-Quirks bei Scheduled Triggers. Zapier und Make erlauben beide eine Zeitzone am Schedule. DST interpretieren sie nicht immer gleich. Jeden Scheduled Trigger nach Migration prüfen — besonders bei Edge-of-Day-Zeiten (23:50, 00:10), wo DST-Sprünge einen Job zweimal laufen lassen oder einen Tag überspringen.

Data-Store-Migration. Kein Import aus Zapier Tables. Nach CSV exportieren, ins von Ihnen designte Make-Schema transformieren, importieren. Bei jeder Tabelle über ein paar hundert Zeilen ein kleines Skript schreiben statt Handarbeit.

Gespeicherte Authentifizierung. Connections übertragen sich nicht. Jede OAuth-Connection (Google, Slack, Notion) muss in Make neu authentifiziert werden. Das in Schritt 5 geschlossen erledigen, nicht stückweise.

Die erste Stunde auf Make

Wenn Sie Make noch nie genutzt haben, hier das Minimum zur Kalibrierung.

1. Ein Team anlegen (nicht nur ein persönlicher Workspace). Teams haben echtes Rollen-Management auch im Einstiegs-Tier.
2. Ein Hello-World-Scenario bauen: Schedule-Trigger jede Stunde, HTTP-“Make a request” auf https://httpbin.org/get, Tools-“Set variable” um ein Feld aus der Response zu parsen. Manuell einmal laufen lassen. Execution-Inspector öffnen und durch jeden Modul-Input/Output-Bundle klicken.
3. Nach dem HTTP-Modul einen Router mit zwei Branches und unterschiedlichen Filtern ergänzen. Beobachten, welche Bundles welchen Pfad nehmen. Das ist das mentale Modell für alles Weitere.
4. Einen Data Store mit drei Feldern anlegen. Modul, das eine Zeile schreibt. In einem zweiten Scenario mit “Search records” abfragen. Das sind 80 Prozent aller Storage-Arbeit, die Sie je machen werden.
5. Die Execution-History des Scenarios anschauen. Dort verbringen Sie die meiste Debug-Zeit. Bookmarken.

Eine Stunde davon bevor Sie echte Migrations-Arbeit anfassen, spart später viel Geknüpel.

Wann Make überspringen und direkt zu n8n

Make ist die richtige Antwort für die meisten Teams, die Zapier verlassen. Sie ist nicht die richtige Antwort für alle.

Direkt zu n8n, wenn eines dieser Punkte zutrifft:

• Self-Hosting ist Pflicht. DSGVO-Constraints, air-gapped Umgebungen oder strenge Datenresidenz-Regeln, die SaaS-Verarbeiter ausschliessen. Make ist nur SaaS.
• Sie brauchen Custom-Code-Nodes als First-Class-Citizen. Make hat das Tools-Modul und Sie können auf eigene HTTP-Funktionen ausschellen, aber n8ns Code-Node läuft JavaScript oder Python inline und passt code-first-Teams besser.
• Lange laufende Workflows mit schwerem Branching und tausenden Executions am Tag. n8n skaliert besser, wenn Sie selbst hosten — Sie kontrollieren die Ressourcen.
• Sie wollen Workflows in Git versionieren. n8n exportiert Workflow-JSON sauber. Make hat Blueprint-Export, aber weniger ergonomisch für Git-Workflows.

Für alles andere ist Make der reibungsärmere Pfad. Volle Vergleichsmatrix in Make.com vs. n8n für Produktivlasten, und das migrate-Pendant für n8n: Zapier zu n8n migrieren.

Welche Wahl für Sie?

Kurzform.

• Auf Zapier bleiben, wenn Sie weniger als fünf einfache Workflows haben, das Team nicht-technisch ist und Kosten kein Schmerzpunkt sind.
• Zu Make migrieren, wenn Sie Branching, Iteration, besseres Debugging und vorhersagbare Kosten im Volumen brauchen. Deckt die meisten Teams jenseits des Hobby-Stadiums ab.
• Direkt zu n8n, wenn Sie Self-Hosting, Custom-Code oder schwere Skalierung auf eigener Infrastruktur brauchen.

Was Sie auch wählen — fahren Sie die 6-Schritt-Strategie. Parallel-Run, Validieren, Cutover, Batchen, Abschalten. Den Parallel-Run zu überspringen ist der häufigste Weg, eine Migration in der Produktion zu zerlegen — und der teuerste, wovon man sich erholen muss.

Wenn Sie die Migration nicht selbst stemmen wollen: ein externer KI-Engineer mit Make-/n8n-Erfahrung macht den Cutover tageweise; bei strategischen Plattform-Entscheidungen lohnt eine Session mit einem erfahrenen Berater.

Weiterführende Artikel

• Make.com vs. n8n für Produktivlasten
• Make vs. n8n im Vergleich (Kurzform)
• Claude API vs. OpenAI für Business-Automatisierung
• n8n KI-Agent-Workflows
• n8n selbst hosten: Docker, Postgres, DSGVO-konform