Viele Unternehmen starten mit Zapier, weil es einfach zu bedienen ist. Sobald die Anzahl der Automatisierungen wächst oder komplexere Logik gefragt ist, wird die Suche nach einer Zapier Alternative jedoch schnell konkret. Make bietet mehr Kontrolle, oft niedrigere Kosten und die Möglichkeit, Daten auf EU-Servern zu verarbeiten. Dieser Leitfaden zeigt, wie eine Migration strukturiert gelingt.

Warum Unternehmen von Zapier zu Make wechseln

Kosten: Tasks vs. Credits

Zapier zählt jede einzelne Aktion in einem Zap als Task und berechnet danach den Plan. Make zählt stattdessen Credits, wobei ein Standard-Modul in der Regel einen Credit verbraucht, unabhängig davon, wie viele Datenfelder verarbeitet werden. Die Einheit hiess bis August 2026 noch Operation. Bei Szenarien mit vielen Datenpunkten pro Ausführung (zum Beispiel Verarbeitung eines ganzen Datensatzes mit mehreren Feldern) kann das bei Make günstiger ausfallen, da nicht jedes Feld einzeln zählt. Ein direkter Preisvergleich lohnt sich immer anhand deines eigenen Automatisierungsvolumens, da beide Anbieter unterschiedliche Plan-Stufen mit unterschiedlichen Limits führen. Prüfe die aktuellen Preise auf den offiziellen Seiten von Make und Zapier, Stand September 2026.

Mehrstufige Logik

Zapier bildet Verzweigungen über Paths ab, Make bietet dafür einen Router mit beliebig vielen Zweigen und Filtern pro Zweig. Zusätzlich bringt Make einen Iterator für Arrays und Aggregatoren zum Zusammenführen mehrerer Bundles mit, wofür in Zapier oft zusätzliche Zaps oder Formatter-Schritte nötig sind.

Datenschutz und EU-Server

Make betreibt Infrastruktur mit Serverstandorten in der EU, was für Unternehmen mit strengen Datenschutzanforderungen relevant ist. Zapier ist primär in den USA gehostet. Für Schweizer und europäische Unternehmen kann das ein entscheidendes Argument bei der Wahl der Plattform sein, unabhängig von Funktionsumfang oder Preis.

Konzept-Übersetzung: Zapier zu Make

Die folgende Tabelle hilft, bestehende Zaps gedanklich in Make-Szenarien zu übersetzen.

‍

‍

Diese Übersetzung ist eine Orientierung, kein exaktes 1:1-Mapping. Manche Zaps lassen sich in Make sogar mit weniger Schritten abbilden, da Router und Iterator mehr Logik in einem einzigen Modul bündeln.

Migrationsplan in 6 Schritten

Schritt 1: Inventar erstellen

Liste alle aktiven Zaps auf, inklusive Trigger, verwendeter Apps, Häufigkeit der Ausführung und geschäftlicher Kritikalität. Diese Übersicht ist die Grundlage für alle weiteren Entscheidungen und zeigt oft auch ungenutzte oder doppelte Zaps auf, die gar nicht migriert werden müssen.

Schritt 2: Priorisierung

Nicht alle Zaps müssen gleichzeitig migriert werden. Sortiere nach geschäftlicher Wichtigkeit und Komplexität. Einfache, unkritische Zaps eignen sich gut als erste Testfälle, um Erfahrung mit Make zu sammeln, bevor du kritische Abläufe anfasst.

Schritt 3: Nachbau in Make

Baue jedes Szenario in Make neu auf, statt zu versuchen, eine Zap-Konfiguration direkt zu importieren. Nutze dabei die Gelegenheit, Logik zu vereinfachen, etwa durch einen Router statt mehrerer paralleler Zaps oder durch eingebaute Funktionen statt externer Formatter-Dienste. Für einfachere Zaps lässt sich dieser Schritt AI-gestützt beschleunigen: Eine AI erfasst die Zap-Logik strukturiert und erzeugt daraus einen Make-Blueprint, den du über die Make API importierst. Details dazu im Abschnitt „Lässt sich die Migration mit AI automatisieren?“ weiter unten.

Schritt 4: Parallelbetrieb

Lass den bestehenden Zap und das neue Make-Szenario für einen definierten Zeitraum parallel laufen, wobei nur einer der beiden tatsächlich produktive Aktionen ausführt (zum Beispiel per Filter deaktiviert) und der andere nur zu Testzwecken protokolliert. So lassen sich Ergebnisse vergleichen, ohne doppelte Datensätze oder doppelte Benachrichtigungen zu riskieren.

Schritt 5: Cutover

Sobald das Make-Szenario zuverlässig die erwarteten Ergebnisse liefert, schaltest du es produktiv und deaktivierst den entsprechenden Zap. Prüfe unmittelbar nach dem Umschalten die ersten Ausführungen genau, bevor du zum nächsten Zap übergehst.

Schritt 6: Dokumentation

Halte fest, welches Szenario welchen Zap ersetzt, welche Connections neu eingerichtet wurden und welche Besonderheiten beim Nachbau aufgetreten sind. Diese Dokumentation erleichtert spätere Wartung erheblich und ist bei einem Wechsel der zuständigen Person unverzichtbar.

‍

Lässt sich die Migration mit AI automatisieren?

Eine Frage, die bei Migrationsprojekten regelmässig auftaucht: Lässt sich die Migration über MCP (Model Context Protocol) automatisieren, sodass eine AI die Szenarien direkt von Zapier nach Make verschiebt? Die kurze Antwort nach Prüfung von Zapier MCP, Make MCP und der Make API: Ein fertiges Ein-Klick-Tool dafür gibt es Stand September 2026 nicht. Beide MCP-Angebote lösen ein anderes Problem, als man auf den ersten Blick vermuten könnte.

Zapier MCP (zapier.com/mcp, docs.zapier.com/mcp) verbindet einen AI-Assistenten mit über 9'000 Apps und mehreren Zehntausend Aktionen. Es führt Aktionen aus, zum Beispiel eine Nachricht in Slack senden, eine Zeile in Google Sheets anlegen oder einen Datensatz in einem CRM aktualisieren. Es liest aber keine bestehenden Zap-Definitionen aus und exportiert sie nicht. Eine frühe Zusatzfunktion namens „Next Gen Zap workflows“ lässt eine AI aus einer Beschreibung heraus neue Zaps bauen, das hilft bei einer Migration nach Make jedoch nicht, weil das Ergebnis wieder ein Zap ist.

Make MCP existiert in zwei Varianten, die oft verwechselt werden. Der Make MCP Server macht deine Make-Szenarien für eine AI aufrufbar: Sie kann Szenarien ausführen und, auf bezahlten Plänen, Szenarien sowie zugehörige Connections, Webhooks und Data Stores einsehen und verändern. Der Make MCP Client funktioniert umgekehrt: Er erlaubt einem Make-Szenario, Tools auf externen MCP-Servern zu nutzen, etwa GitHub oder PayPal. Keine der beiden Varianten ist als Migrationswerkzeug dokumentiert oder liest Zapier-Konfigurationen.

Was tatsächlich funktioniert, ist ein indirekter Weg über die Make API v2. Die API erlaubt es, ein neues Szenario direkt per Blueprint-JSON anzulegen (POST /scenarios mit Blueprint, Team-ID und Scheduling als Parameter), statt jedes Modul einzeln in der Oberfläche zusammenzuklicken. Ein realistischer AI-gestützter Ablauf sieht deshalb so aus:

1. Zap-Logik strukturiert erfassen: Auf Team- oder Enterprise-Plänen bietet Zapier einen JSON-Export bestehender Zap-Workflows an (unter Account-Einstellungen, nicht über MCP). Dieses Format ist nicht als offene Schnittstelle für Drittanbieter dokumentiert, lässt sich aber als Ausgangspunkt nutzen, um einer AI Trigger, Schritte und Feldverknüpfungen eines Zaps vorzulegen. Auf Free- und Professional-Plänen bleibt nur die manuelle Beschreibung jedes Schritts.
2. AI erzeugt einen Make-Blueprint: Aus der strukturierten Beschreibung generiert eine AI ein Blueprint-JSON nach dem Make-Schema (Flow-Array mit Modulen, Mapping-Ausdrücken, Routern für Verzweigungen).
3. Import über die Make API: Der generierte Blueprint wird per API-Aufruf als neues Szenario angelegt, statt von Hand gebaut zu werden.
4. Manuelle Nacharbeit: Connections, Webhook-URLs und Tests bleiben Handarbeit, dazu weiter unten mehr.

Wie viel Zeit das spart, hängt stark von der Komplexität ab. Bei einfachen bis mittleren Zaps mit wenigen Standard-Apps kann dieser Ansatz den reinen Nachbau-Aufwand (Schritt 3 des Migrationsplans) grob geschätzt um 30 bis 50 Prozent reduzieren, weil das Zusammenklicken der Module entfällt. Auf die gesamte Migration gerechnet, inklusive Connections, Tests und Cutover, ist die realistische Einsparung deutlich kleiner, eher im Bereich von 15 bis 25 Prozent der Gesamtzeit. Diese Werte sind eine vorsichtige Einschätzung, keine belastbare Kundenzahl, und sollten pro Projekt geprüft werden.

Wo dieser Ansatz bricht

• Custom-Code-Schritte: Code-by-Zapier-Blöcke in JavaScript oder Python müssen inhaltlich verstanden und in Make-Logik oder ein eigenes Modul übersetzt werden. Eine AI kann das vorschlagen, das Ergebnis muss aber geprüft werden.
• Zapier-eigene Formatter-Logik: Nicht jede Formatter-Funktion hat eine direkte Entsprechung in Make. Fehlübersetzungen fallen oft erst bei der Ausführung mit echten Daten auf.
• Paths mit komplexen Bedingungen: Verschachtelte Verzweigungslogik in einen Router mit mehreren Filtern zu übersetzen, ist fehleranfällig, wenn eine AI sie ungeprüft übernimmt.
• OAuth-Connections sind immer manuell: Weder die Make API noch ein MCP-Server kann eine neue OAuth-Autorisierung ohne Browser-Interaktion einer Person herstellen. Das bleibt in jedem Szenario Handarbeit.
• Tests mit Echtdaten: Ob ein generiertes Szenario korrekt funktioniert, zeigt sich erst im Parallelbetrieb mit echten Datensätzen, siehe Schritt 4. Das lässt sich nicht automatisieren, nur beschleunigt vorbereiten.
• Rate Limits beim Blueprint-Import: Die Make API begrenzt Anfragen je nach Plan auf 60 bis 1'000 pro Minute. Für einzelne Szenarien ist das kein Thema, bei einer Massenmigration vieler Dutzend Zaps auf einmal kann es die Geschwindigkeit des automatisierten Imports limitieren.

Für Unternehmen mit einer grösseren Anzahl ähnlich aufgebauter Zaps kann dieser AI-gestützte Weg den Aufwand spürbar senken. Bei wenigen oder sehr unterschiedlichen Zaps überwiegt oft der Aufwand, die Logik erst sauber zu erfassen, gegenüber dem Zeitgewinn beim eigentlichen Bau.

Typische Stolperfallen bei der Migration

• Webhook-URLs ändern sich: Jede Webhook-Adresse in Make unterscheidet sich von der in Zapier verwendeten. Alle Systeme, die aktiv Daten an die alte Zapier-Webhook-URL senden (zum Beispiel ein Webformular oder eine externe App), müssen auf die neue Make-Adresse umgestellt werden.
• OAuth-Verbindungen müssen neu autorisiert werden: Bestehende Verbindungen zu Google, Microsoft, CRM-Systemen und anderen Apps lassen sich nicht aus Zapier übernehmen. Jede Connection muss in Make erneut über den jeweiligen Login-Flow autorisiert werden.
• Zeitzonen: Zeitgesteuerte Zaps und Make-Szenarien können unterschiedliche Standard-Zeitzonen verwenden. Prüfe bei jedem zeitgesteuerten Szenario explizit die hinterlegte Zeitzone, um Verschiebungen bei Ausführungszeiten zu vermeiden.
• Formeln und Datenverarbeitung: Formatter-Schritte aus Zapier lassen sich meist, aber nicht immer, 1:1 in Make-Funktionen übersetzen. Komplexere Formeln (etwa verschachtelte Bedingungen) solltest du einzeln testen, statt sie blind zu übernehmen.

Kostenvergleich: Rechenbeispiel

Angenommen, ein Unternehmen führt monatlich rund 8'000 einzelne Aktionsschritte über mehrere Zaps aus, wobei jeder Durchlauf im Schnitt vier Aktionsschritte umfasst (das entspricht rund 2'000 Ausführungen). Bei Zapier zählt jeder der 8'000 Aktionsschritte als eigener Task, was einen entsprechend höheren Tarif-Plan erfordert. Bei Make verbraucht ein vergleichbares Szenario mit denselben vier Schritten in der Regel vier Credits pro Ausführung, also ebenfalls rund 8'000 Credits bei 2'000 Ausführungen, sofern jeder Schritt einem eigenen Modul entspricht. Der Unterschied zeigt sich vor allem dort, wo ein einzelnes Make-Modul mehrere Datenpunkte auf einmal verarbeitet (zum Beispiel ein Iterator mit anschliessender Sammel-Aktion), während Zapier dafür mehrere Tasks separat zählen würde. Für eine verlässliche Einschätzung solltest du dein eigenes Automatisierungsvolumen anhand der aktuellen Plan-Tabellen beider Anbieter durchrechnen, da sich Staffelungen und Limits ändern können.

✨ AI generated content