Was passiert, wenn Ihr Automatisierungsanbieter morgen den Stecker zieht

Was passiert, wenn Ihr Automatisierungsanbieter morgen den Stecker zieht

Im Februar 2024 verkündete IFTTT, dass kostenlose Konten künftig auf drei aktive Applets begrenzt würden. Was als Standardpreiserhöhung daherkam, traf Tausende Anwender, die ihre Smart-Home-Steuerung, ihre Notification-Workflows und ihre Datenbrücken seit Jahren auf der Plattform aufgebaut hatten. Wer mehr als drei Automatisierungen brauchte, musste zahlen oder verlieren.

Im Sommer desselben Jahres stellte Integromat (zwischenzeitlich umbenannt in Make) seine alte Plattform endgültig ab. Wer nicht migriert hatte, sah seine Workflows verschwinden. Die Migration war lange angekündigt. Aber jeder, der schon einmal einen produktiven Flow umgezogen hat, weiß: das ist nicht trivial.

Beide Fälle sind harmlos im Vergleich zu dem, was passieren kann. Plattformen werden übernommen, eingestellt, ändern ihre Geschäftsmodelle. Das ist normal in einem Markt, der sich noch sortiert. Wer Geschäftsprozesse auf einer Plattform aufbaut, deren Existenz er nicht kontrolliert, sollte wissen, was passiert, wenn diese Plattform sich verändert.

Diese Frage stellt sich kaum jemand. Bis es zu spät ist.

Der Markt sortiert sich

Der Automatisierungsmarkt ist relativ jung. Zapier wurde 2011 gegründet, Make (damals Integromat) 2012, n8n 2019. Activepieces ist 2022 gestartet. Im selben Zeitraum sind dutzende kleinere Plattformen entstanden und wieder verschwunden. Workato, Tray.io, Boomi, Workiom, Bardeen, Pabbly. Manche existieren noch, manche wurden übernommen, manche wurden in andere Produkte integriert.

Das ist kein Zeichen eines kaputten Marktes. So funktionieren neue Märkte. Nur darf man bei solchen Strukturen nicht so tun, als wäre ein Anbieter eine Institution, die garantiert in zehn Jahren noch existiert. Selbst die Großen sind nicht sicher: Zapier hat 2024 öffentlich diskutiert, ob bestimmte Funktionen nur noch im Enterprise-Tarif verfügbar sein sollen. Make hat seine Preisstruktur seit der Übernahme durch Celonis 2020 mehrfach angepasst.

Bei Cloud-CRM oder ERP-Systemen ist das Risiko ähnlich, aber dort sind die Wechselkosten so hoch und das Bewusstsein so geschärft, dass man Vendor-Risk als Standardthema behandelt. Bei Automatisierung wird es übersehen, weil die Tools als hilfreich und unkompliziert gelten. Das stimmt für den Aufbau. Es stimmt nicht für den Ausstieg.

Die drei Wege, auf denen Anbieter Sie überraschen können

Übernahme und Strategiewechsel

Übernahmen klingen erstmal positiv: mehr Ressourcen, stabilerer Anbieter. In der Realität bringen sie oft Veränderungen, die Bestandskunden nicht passen. Funktionen werden eingestellt, weil sie nicht in die Strategie des Käufers passen. Preise werden angepasst, weil das Geschäftsmodell des Mutterkonzerns andere Margen verlangt. Connectoren verschwinden, weil sie nicht mehr gepflegt werden.

Ein typisches Muster: Plattform A wird von einem größeren Konzern gekauft, der bereits ein Konkurrenzprodukt hat. Innerhalb von zwei Jahren wird Plattform A in das Portfolio eingegliedert. Das bedeutet meistens: höherer Preis, weniger Innovation, irgendwann Ende des Standalone-Produkts.

Das ist nicht hypothetisch. Genau das ist dutzenden kleineren SaaS-Tools in den letzten zehn Jahren passiert. Es gibt keinen Grund anzunehmen, dass Automatisierungsplattformen davon ausgenommen sind.

Preisanpassungen

Die häufigste und harmloseste Variante. Eine Plattform erhöht ihre Preise um zwanzig oder dreißig Prozent. Sie können bleiben oder gehen. Wenn der Wechsel viel Aufwand bedeutet, bleiben Sie. Genau darauf setzen Anbieter.

Ein konkretes Beispiel aus der Praxis: Ein Unternehmen mit etwa 200 Mitarbeitern hatte rund achtzig produktive Workflows in Zapier. Als Zapier seine Preise spürbar anhob, war der Aufwand für eine Migration zu einer anderen Plattform höher als die Preiserhöhung über jeden vernünftigen Zeitraum. Sie zahlen heute deutlich mehr als vor zwei Jahren, ohne dass die Funktionalität entsprechend gewachsen wäre.

Das ist kein Vorwurf an Zapier. Sie machen ihren Job, ihr Geschäft auszubauen. Es ist ein Lernpunkt für Kunden: jede Automatisierung, die nicht trivial portierbar ist, ist eine Wette darauf, dass die Preisstruktur des Anbieters sich nicht ändert.

Funktionseinstellung

Manchmal verschwindet die Plattform nicht, sondern einzelne Funktionen. Ein Connector zu einem Drittanbieter wird abgekündigt, weil zu wenige Kunden ihn nutzen. Ein bestimmter Trigger-Typ wird durch einen anderen ersetzt. Eine Authentifizierungsmethode wird abgeschaltet.

Diese Änderungen brechen Workflows. Der Anbieter kommuniziert es vorher, in einer E-Mail, die im Posteingang untergeht. Wer aktiv arbeitet, bemerkt es. Wer einen Workflow vor zwei Jahren gebaut und seitdem nicht angefasst hat, merkt es, wenn er einen Tag nicht mehr läuft.

Was Lock-in bei Automatisierung wirklich bedeutet

Die Annahme: Workflows bestehen aus Logik, und Logik ist portabel. Falsch.

Ein Workflow in Zapier oder Make besteht aus mehreren Schichten:

Die Logik selbst. Wenn-Dann-Verzweigungen, Datentransformationen, Routing. Diese Schicht ist konzeptionell portabel. In der Praxis muss man sie aber neu aufbauen, weil jede Plattform ihre eigene Syntax und ihre eigenen Konzepte hat.

Die Connector-Spezifika. Wenn Sie in Zapier den HubSpot-Connector nutzen, hat dieser bestimmte Trigger und Aktionen mit bestimmten Feldern. Der HubSpot-Connector in Make hat ähnliche, aber nicht identische Funktionen. Das Mapping zwischen den beiden ist Handarbeit.

Die Authentifizierung. OAuth-Tokens, API-Schlüssel, Refresh-Logik. Diese sind plattformspezifisch und müssen bei jedem Wechsel neu konfiguriert werden. Bei zwanzig Workflows mit jeweils drei verbundenen Diensten sind das sechzig Verbindungen, die rebuild werden müssen.

Der Workflow-State. Was an Daten in der Plattform liegt: Verarbeitungshistorie, Fehlerprotokolle, manchmal auch Datenqueues, die mitten in der Verarbeitung hängen. Ein Wechsel bedeutet meistens: dieser Zustand ist weg.

Die operationelle Erfahrung. Welche Edge-Cases haben Sie über die letzten sechs Monate behoben? Welche Hacks haben Sie eingebaut, weil eine bestimmte Funktion nicht zuverlässig war? Diese Erfahrung ist nicht im Workflow dokumentiert. Sie ist im Kopf des Bauenden.

Wenn Sie wechseln, müssen Sie alle fünf Schichten neu aufbauen. Plus Sie verlieren das Vertrauen, dass das Neue verlässlich läuft, bis es eine Weile gelaufen ist.

Self-Hosting: Was die Versprechen wirklich bedeuten

n8n und Activepieces bieten beide Self-Hosting an. Das wird oft als Antwort auf Vendor-Lock-in präsentiert. Die Wahrheit ist gemischt.

Was Self-Hosting löst: Sie kontrollieren die Infrastruktur. Wenn der Anbieter morgen pleitegeht, läuft Ihre Instanz weiter, solange Sie sie betreiben. Sie haben Zugriff auf alle Daten, die durch Ihre Workflows fließen. Sie können nicht durch Preiserhöhungen überrascht werden, weil die Lizenz transparent ist.

Was Self-Hosting nicht löst: Die Workflows hängen weiterhin von Connectoren ab, die der Anbieter oder die Community pflegt. Wenn das n8n-Projekt den Salesforce-Connector nicht mehr aktualisiert, hilft Self-Hosting nicht. Sie sind weiterhin abhängig von einem externen Projekt und seiner Community.

Was Self-Hosting kostet: Server, Backups, Monitoring, Updates, Sicherheitspatches. Bei einer kleineren Installation reden wir über etwa zwei bis vier Stunden Wartung pro Monat, die jemand qualifiziert leisten muss. Das ist kein freier Mittagessen, sondern eine Verschiebung der Kosten von Lizenzen zu Personal.

In der Praxis ist Self-Hosting für Unternehmen sinnvoll, die bereits IT-Kompetenz haben oder bei denen der Datenschutz so kritisch ist, dass Cloud-Verarbeitung nicht infrage kommt. Für ein dreiköpfiges Beratungsbüro ist Self-Hosting fast nie die richtige Wahl, auch wenn es technisch möglich wäre.

Workflows von Anfang an portabel bauen

Sie können nicht jede Abhängigkeit eliminieren. Aber Sie können das Risiko minimieren, indem Sie beim Bau bestimmte Entscheidungen treffen.

Logik dokumentieren, nicht nur klicken

Visuelle Builder fühlen sich selbsterklärend an. Sind sie nicht. Das Diagramm zeigt Verbindungen, aber nicht, warum eine bestimmte Verzweigung existiert oder welcher Edge-Case dort behandelt wird.

Für jeden produktiven Workflow eine kurze Beschreibung in Markdown anlegen. Drei Abschnitte reichen: Was triggert den Workflow? Welche Schritte werden in welcher Reihenfolge ausgeführt? Welche Edge-Cases werden behandelt?

Diese Dokumentation hilft auch im Alltag, wenn jemand anderes den Workflow verstehen muss.

Datentransformationen vom Workflow trennen, wo möglich

Manche Plattformen bieten Code-Module an: ein JavaScript- oder Python-Snippet, das eine bestimmte Transformation durchführt. Wenn Sie diese Snippets in einer separaten Datei oder einem Repository dokumentieren, sind sie portabel, weil JavaScript JavaScript bleibt. Die Logik ist nicht im plattformspezifischen Visual-Editor versteckt.

Webhooks statt nativer Trigger, wo sinnvoll

Wenn Ihr CRM Webhooks unterstützt, lassen Sie den Webhook auf einen Endpunkt Ihrer Wahl zeigen. Wechseln Sie die Automatisierungsplattform, ändern Sie den Endpunkt im CRM, der Trigger funktioniert weiter. Das ist nicht immer möglich, aber wo es möglich ist, reduziert es die Migrationskosten erheblich.

Eine Plattform, nicht fünf

Versuchen Sie nicht, Ihr Risiko zu diversifizieren, indem Sie verschiedene Plattformen für verschiedene Anwendungsfälle nutzen. Das verdoppelt Ihre Lernkurve, Ihre Lizenzkosten und Ihre Komplexität, ohne das Risiko nennenswert zu reduzieren. Wenn eine Plattform ausfällt, bricht trotzdem ein Großteil Ihrer Automatisierung weg.

Eine Plattform tief beherrschen ist robuster als drei oberflächlich.

Geschäftslogik nicht in Workflows einbetten

Wenn Sie eine komplexe Berechnung haben, die für Ihr Geschäft kritisch ist, gehört diese Berechnung nicht in einen Workflow. Sie gehört in eine Funktion, die irgendwo läuft, in einer Sprache, die Sie unabhängig vom Tool kontrollieren. Der Workflow ruft diese Funktion auf.

Konkretes Beispiel: Eine Provisionsberechnung mit mehreren Stufen, abhängig von Kundengruppe und Vertragslaufzeit. Wenn diese Logik in einem Make-Szenario versteckt ist, hängen die Provisionen Ihrer Vertriebsmitarbeiter an Make. Bauen Sie die Berechnung in eine kleine HTTP-API, hosten Sie diese irgendwo stabil, der Workflow ruft die API auf. Wechseln Sie die Plattform, bleibt die Logik bestehen.

Das Export-Problem

Jede Plattform sagt, sie unterstütze Export. Was sie nicht sagt: was im Export tatsächlich enthalten ist.

Bei Make können Sie Szenarien als Blueprint exportieren. Der Blueprint enthält die Workflow-Struktur. Was er nicht enthält: die OAuth-Verbindungen, die Webhook-Endpunkte, die manuell hochgeladenen Dateien, die historischen Verarbeitungsdaten. Wenn Sie ein Backup des Workflows haben, haben Sie die Hälfte. Den Rest müssen Sie manuell rekonstruieren.

Bei Zapier ist es ähnlich. Bei n8n besser, weil Workflows als JSON exportierbar sind, was die Reproduzierbarkeit erhöht. Aber auch dort: Verbindungen sind nicht im Export enthalten, aus guten Sicherheitsgründen.

Was bedeutet das praktisch? Die Idee, einmal pro Quartal alle Workflows zu exportieren und das Backup wegzulegen, ist nicht falsch, aber sie löst das Problem nicht vollständig. Im Ernstfall können Sie aus dem Backup die Logik rekonstruieren. Die operative Verbindung zur restlichen Welt müssen Sie neu aufbauen.

Wer kontrolliert die Zugangsdaten?

Eine Frage, die oft erst auftaucht, wenn jemand das Unternehmen verlässt: wer hatte Zugriff auf den Automatisierungs-Account, und welche Verbindungen sind dort hinterlegt?

Ein Beispiel aus der Beratung: Ein Geschäftsführer rief mich an, weil seine wichtigsten Workflows seit drei Tagen nicht mehr liefen. Die Person, die alles eingerichtet hatte, war einen Monat zuvor ausgeschieden. Die Workflows waren in deren persönlichem Make-Account, mit deren persönlichen OAuth-Verbindungen zu Salesforce, HubSpot und Slack. Als sich das Salesforce-Token erneuerte, brach alles zusammen. Niemand außer der ausgeschiedenen Person hatte Zugriff, um es wieder einzurichten.

Die Lösung war, einen neuen Account aufzubauen, den Workflow zu rekonstruieren, alle Verbindungen neu zu autorisieren. Drei Tage Aufwand für jemanden, der das Tool nicht kannte. Vermeidbar, wenn von Anfang an ein Team-Account genutzt worden wäre, mit dokumentierten Verbindungen und mehreren Administratoren.

Empfehlung:

Nutzen Sie immer einen Geschäfts-Account, nie einen privaten. Mindestens zwei Personen sollten Administrator-Rechte haben. Verbindungen sollten unter einem unternehmensweiten Service-Account stehen, nicht unter dem privaten Konto eines Mitarbeiters. Bei Mitarbeiterwechsel: prüfen, ob Verbindungen unter deren Namen laufen, und entsprechend übertragen.

Diese Hygiene ist langweilig. Sie wird unterschätzt, bis sie fehlt.

Wann Sie wirklich migrieren sollten

Migration ist Aufwand. Eine Migration aus reinen Lock-in-Sorgen, ohne konkreten Anlass, ist meistens ineffizient. Es gibt aber Situationen, in denen Sie nicht warten sollten.

Wenn der Anbieter offiziell ankündigt, eine für Sie kritische Funktion einzustellen. Das ist die klare Linie. Sie haben in der Regel sechs bis zwölf Monate Zeit. Nutzen Sie davon die ersten drei für die Planung, nicht die letzten.

Wenn die Preisstruktur sich so verändert, dass Sie deutlich mehr zahlen, ohne mehr Wert zu erhalten. Hier ist es eine Rechnung: Was kostet die Migration, was sparen Sie über die nächsten zwei Jahre? Wenn die Migration sich in unter zwölf Monaten amortisiert, lohnt es sich.

Wenn Sie Compliance-Anforderungen haben, die der aktuelle Anbieter nicht erfüllt. DSGVO-Anforderungen, ISO-Zertifizierung, branchenspezifische Vorgaben. Hier geht es nicht um Bequemlichkeit, sondern um regulatorische Notwendigkeit.

Wenn der Anbieter mehrfach durch Stabilitätsprobleme aufgefallen ist. Ein Ausfall ist normal. Drei in einem Quartal, jeweils mehrere Stunden, sind ein Signal.

Was eine Migration kostet

Erfahrungswerte aus Projekten, die ich begleitet habe:

Ein einfacher Workflow (Trigger, zwei bis drei Schritte, eine Datenquelle) lässt sich in drei bis vier Stunden migrieren, inklusive Test. Das gilt, wenn jemand beide Plattformen kennt. Wer eine der beiden lernt, braucht das Mehrfache.

Ein mittelkomplexer Workflow (Verzweigungen, mehrere Datenquellen, Datentransformation) braucht oft einen ganzen Tag pro Workflow. Die meiste Zeit geht in das Testen der Edge-Cases, die im Original über Monate aufgetaucht sind und nicht dokumentiert wurden.

Komplexe, geschäftskritische Workflows können mehrere Tage brauchen, mit zusätzlichem Parallelbetrieb für eine Übergangsphase, in der beide Systeme laufen, um Fehler zu erkennen, bevor sie den Geschäftsbetrieb stören.

Bei einem Portfolio von zwanzig Workflows reden wir realistisch über zwei bis vier Wochen Vollzeitarbeit, je nach Komplexität. Das ist die ehrliche Zahl, nicht die Demo-Zahl.

Eine Migration in vier Phasen

Wenn die Entscheidung gefallen ist, hilft eine strukturierte Vorgehensweise. Was ich Kunden empfehle:

Phase 1: Bestandsaufnahme

Listen Sie jeden produktiven Workflow auf. Klassifizieren Sie nach Kritikalität: Was passiert, wenn dieser Workflow eine Woche nicht läuft? Manche Workflows sind verzichtbar oder lassen sich manuell überbrücken. Andere stoppen den Geschäftsbetrieb. Diese Klassifizierung bestimmt die Reihenfolge.

Dokumentieren Sie für jeden Workflow: Trigger, Schritte, verbundene Dienste, bekannte Edge-Cases. Wenn Sie diese Dokumentation noch nicht haben, jetzt ist der Zeitpunkt, sie zu erstellen. Sie ist auch unabhängig von der Migration wertvoll.

Phase 2: Pilot

Migrieren Sie zwei oder drei einfache, nicht-kritische Workflows zuerst. Das hat zwei Zwecke: Sie lernen die neue Plattform an realen Beispielen kennen, und Sie identifizieren systematische Probleme früh, bevor Sie kritische Workflows angefasst haben.

Lassen Sie diese Pilot-Workflows mindestens zwei Wochen produktiv laufen, parallel zum Original, bevor Sie den nächsten Schritt machen.

Phase 3: Hauptmigration

Migrieren Sie die mittelkritischen Workflows. Für jeden: zuerst auf der neuen Plattform aufbauen, dann mit Testdaten validieren, dann parallel zum Original laufen lassen, dann Original abschalten. Diese Sequenz ist langsamer als ein Direktwechsel, aber sie verhindert die typische Migrationskatastrophe, in der man am Tag X umschaltet und am Tag X+1 feststellt, dass drei Edge-Cases nicht funktionieren.

Phase 4: Kritische Workflows

Zum Schluss die Workflows, deren Ausfall den Geschäftsbetrieb stören würde. Hier ist Parallelbetrieb über mindestens vier Wochen Pflicht. Das kostet doppelte Lizenzgebühren in dieser Phase, aber es ist deutlich günstiger als ein Ausfall.

Nach erfolgreichem Parallelbetrieb: Original abschalten, Backup behalten, mindestens drei Monate.

Wann Lock-in akzeptabel ist

Nicht jede Abhängigkeit ist ein Problem. Es gibt Fälle, in denen Sie lieber tief in einer Plattform sitzen, als künstlich Portabilität sicherstellen zu wollen.

Wenn die Plattform tief in Ihre Wertschöpfung integriert ist und der Wechsel unrealistisch teuer wäre. SAP. Salesforce. Microsoft 365. Hier ist Lock-in real, aber das Verhältnis aus Aufwand und Risiko macht es vertretbar, solange der Anbieter stabil ist.

Wenn die plattformspezifischen Funktionen einen echten Wettbewerbsvorteil liefern. Manche Aufgaben lassen sich nur in einer bestimmten Plattform sinnvoll lösen. Wenn Make eine Funktion hat, die n8n nicht hat, und diese Funktion für Sie kritisch ist, ist Lock-in der bewusste Preis für die Funktion.

Wenn Sie keine ernsthaften Compliance-Anforderungen haben und der Anbieter etabliert ist. Für viele Unternehmen ist Zapier eine vernünftige Wahl, auch mit allen Lock-in-Risiken. Die Plattform funktioniert, das Pricing ist transparent, die Wahrscheinlichkeit, dass Zapier in den nächsten fünf Jahren verschwindet, ist gering.

Die strategische Frage ist nicht: wie vermeide ich jede Abhängigkeit? Die Frage ist: welche Abhängigkeiten kann ich akzeptieren, und welche müssen aktiv reduziert werden?

Die Frage, die Sie sich vor jedem Workflow stellen sollten

Bevor Sie den nächsten Workflow bauen: was passiert, wenn diese Plattform in zwei Jahren nicht mehr existiert oder sich grundlegend ändert?

Drei Möglichkeiten:

Die Antwort ist "ich rekonstruiere den Workflow in einem anderen Tool, das dauert ein paar Stunden". Akzeptables Risiko.

Die Antwort ist "ich verliere drei Wochen Arbeit und ein paar produktive Tage". Tragbar, aber dokumentieren Sie zumindest die Logik.

Die Antwort ist "der Geschäftsbetrieb ist gestört, wir brauchen Wochen, um das aufzubauen". Das ist eine Plattform-Wette. Treffen Sie sie bewusst, oder bauen Sie den Workflow anders.

Diese Frage beim Bau zu stellen ist deutlich günstiger als die Antwort später zu finden.

Was die meisten Unternehmen falsch einschätzen

Vendor-Risk wird in Automatisierung systematisch unterschätzt, weil die Tools so leicht zu bedienen sind. Man baut etwas in zwei Stunden, das früher zwei Wochen Entwicklungszeit gekostet hätte. Die Tatsache, dass es leicht war, suggeriert, dass es austauschbar wäre. Ist es nicht.

Die meisten Unternehmen haben über die Jahre ein Portfolio von Automatisierungen aufgebaut, in dem mehrere Mitarbeiterjahre an Erfahrung stecken. Diese Erfahrung ist nicht im Code dokumentiert. Sie ist im Tool versteckt, in den Workflows, in den Köpfen der Bauenden.

Lock-in ist die Steuer, die Sie auf diese Erfahrung zahlen, wenn der Anbieter sie kennt und Sie nicht.

Der gangbare Weg ist nicht, jede Abhängigkeit zu eliminieren. Das ist überzogen und ineffizient. Der gangbare Weg ist, die Abhängigkeiten bewusst zu wählen, sie zu dokumentieren, und an den richtigen Stellen Brücken zu bauen, die im Notfall genutzt werden können.

Wer wissen möchte, wie sein eigenes Automatisierungs-Portfolio aussieht und wo die kritischen Abhängigkeiten liegen, beantwortet das im kostenlosen Automations-Check in etwa 30 Minuten.