Vendor-Lock-in vermeiden: Anbieter vor dem Kauf prüfen

Der Moment, bevor Lock-in entsteht

Claudia steht kurz vor einer Entscheidung, die auf den ersten Blick unspektakulär wirkt. Der DACH-Industrieservice-Anbieter mit 42 Mitarbeitenden betreut Wartungsverträge für Maschinenbaukunden in der DACH-Region. Das Team verarbeitet etwa 600 Anfragen pro Monat, pflegt 280 aktive Wartungsverträge und arbeitet mit 14 SaaS-Werkzeugen. Ein neuer Anbieter verspricht, CRM, Angebotserstellung und Ticket-Eskalation in einem Paket zu verbinden. Für Claudia klingt das nach Entlastung. Für Mira aus Operations bedeutet es weniger Copy-and-paste. Für Jonas, den technischen Leiter, bedeutet es aber auch: Ein kritischer Workflow könnte in einem System verschwinden, das niemand außerhalb der Vendor-Oberfläche beschreiben kann.

Vor der Unterschrift fehlen vier Antworten: Welche Daten lassen sich exportieren? Welche Schnittstellen werden benötigt? Wer kontrolliert die Zugänge? Wie ließe sich der Ablauf ersetzen? Dieser Artikel behandelt diese Kaufentscheidung. Die konkrete Durchführung eines späteren Wechsels beschreibt der Cloud-Exit-Leitfaden.

Das Beispiel ist illustrativ, aber der Kontext ist real. Laut Eurostat nutzten 2025 52,74 Prozent der EU-Unternehmen bezahlte Cloud-Dienste. Bei kleinen Unternehmen lag der Anteil bei 49,3 Prozent, bei mittelgroßen Unternehmen bei 66,78 Prozent. Cloud und SaaS sind also keine Enterprise-Sonderfälle mehr. Sie sind Alltagsinfrastruktur für Unternehmen ab zehn Mitarbeitenden. Wer sie nutzt, muss nicht alles selbst betreiben. Aber er muss wissen, welche Abhängigkeit er bewusst eingeht.

Warum Lock-in meist eine stille Designentscheidung ist

Vendor-Lock-in wird oft so erzählt, als hätten Unternehmen den falschen Anbieter gewählt. Das ist zu flach. Viele Abhängigkeiten entstehen durch richtige Entscheidungen, die nicht als Architekturentscheidungen behandelt wurden: ein schneller Export in einem proprietären Format, eine Webhook-Kette ohne Vertrag, ein Identity-Setup mit zu vielen impliziten Berechtigungen, ein Managed Database Service ohne getesteten Restore-Pfad, eine Automatisierung, deren Logik nur in der Oberfläche eines Tools existiert.

Die stärkere Frage lautet deshalb nicht: "Welchen Anbieter sollten wir vermeiden?" Die stärkere Frage lautet: "Welche Abhängigkeit ist bewusst, dokumentiert, reversibel und die Entlastung wert?" Ein Zahlungsanbieter, ein CRM, ein Cloud-Dienst oder eine Workflow-Plattform kann sehr sinnvoll sein, wenn die Datenstruktur bekannt ist, Exporte getestet sind, Berechtigungen sauber dokumentiert werden und ein Ersatzpfad zumindest skizziert ist. Derselbe Dienst wird riskant, wenn er zum einzigen Ort wird, an dem Prozesswissen, Kundendaten, Berechtigungen und Betriebslogik zusammenlaufen.

Die EU/OECD-Notiz zum Wettbewerb im Cloud-Computing nennt typische Wechselhürden: Egress-Kosten, technische Barrieren, fehlende Interoperabilität, mangelnde Datenportabilität und Lizenzpraktiken. Das sind Marktmechanismen, aber im Alltag zeigen sie sich sehr konkret. Jonas kann eine Anwendung nicht umziehen, weil Ereignisse an proprietäre APIs gebunden sind. Mira kann einen Prozess nicht erklären, weil die Freigaberegeln in einem SaaS-Automation-Builder liegen. Claudia kann einem Großkunden keine belastbare Antwort geben, weil der Datenfluss nur als Admin-Screenshot existiert.

Der EU Data Act stärkt seit dem 12. September 2025 die Erwartungen an Wechsel und Portabilität bei Datenverarbeitungsdiensten. Ab dem 12. Januar 2027 sollen Wechselgebühren einschließlich bestimmter Egress-Gebühren entfallen. Das ist ein wichtiges politisches Signal. Es ersetzt aber keine Architektur. Ein Recht auf Wechsel dokumentiert nicht Ihre Feldlogik, Ihre Credentials, Ihre Automationen, Ihre Ausnahmen und Ihre Wiederherstellungstests. Dieser Artikel ist daher Marketing- und Architekturinformation, keine Rechtsberatung.

Die fünf Schichten von Anbieterabhängigkeit

Lock-in wird handhabbar, wenn Sie ihn in Schichten zerlegen. Für KMU ohne eigene Plattformabteilung reicht kein abstraktes "Wir wollen portabel bleiben". Das Team braucht Fragen, die Claudia kaufmännisch verstehen, Jonas technisch prüfen und Mira im Tagesprozess wiedererkennen kann. Die fünf Schichten sind Daten, APIs, Identität, Betriebslogik und Laufzeit.

Datenformate und Exporte. Ein Exportbutton ist kein Ausstiegspfad. Prüfen Sie, ob der Export Metadaten, IDs, Anhänge, Berechtigungen, Status, Historie und Schema-Bedeutung enthält. Ein CRM-Export ohne Aktivitäten und Genehmigungsstatus hilft wenig, wenn genau diese Informationen den Angebotsprozess erklären. Die PostgreSQL-Dokumentation zu pg_dump zeigt, warum ein konkreter Dump- und Restore-Test wertvoll ist: Daten werden nicht nur exportiert, sondern auf einer anderen Maschine oder Architektur wiederhergestellt. Trotzdem bleiben Anbieter-Erweiterungen, Authentifizierung, Trigger und Anwendungskopplung zu prüfen.

APIs und Ereignisse. Viele Teams prüfen, ob ein Anbieter eine API hat. Wichtiger ist, wie stabil der Vertrag ist. Gibt es Versionierung, Webhook-Wiederholungen, Rate-Limits, Fehlerantworten, Änderungsfristen und Testumgebungen? Wenn sieben produktive Integrationen an einem proprietären Eventmodell hängen, ist der Anbieterwechsel nicht nur ein Datenexport. Er ist ein Umbau der Betriebslogik.

Identität und Zugänge. Lock-in entsteht auch durch Berechtigungen. Wer besitzt Adminzugänge, Servicekonten, OAuth-Apps, API-Schlüssel, SSO-Regeln und Break-glass-Zugänge? Wenn Stefan, der externe Entwickler, die ersten Verbindungen mit persönlichen Credentials gebaut hat, ist das kein kleiner Schönheitsfehler. Es ist ein Betriebsrisiko. Zugang gehört ins Handover-Pack: Verantwortlicher, Zweck, Ablaufdatum, Rotation, Ersatzpfad.

Betriebslogik und Automatisierung. Workflows sind oft der unsichtbarste Teil. n8n dokumentiert Export und Import von Workflows sowie Source Control und Umgebungen. Das unterstützt eine gute Praxis: Workflow-Definitionen können sichtbar, reviewbar und versioniert werden. Aber exportierbares JSON allein ist noch Governance. Credentials, Umgebungsvariablen, Tests, Fehlerrouten, fachliche Owner und Review-Gates müssen mitgebaut werden.

Laufzeit und Infrastruktur. Kubernetes kann Abhängigkeit reduzieren, wenn Workloads containerisiert sind und eine portable Laufzeitschicht den Aufwand rechtfertigt. Die Kubernetes-Dokumentation beschreibt Kubernetes als portable, erweiterbare Open-Source-Plattform für containerisierte Workloads mit deklarativer Konfiguration und Automatisierung. Gleichzeitig ist Kubernetes kein vollständiges PaaS und kein Pauschalheilmittel. Für kleine Workloads kann es Overhead sein. Für geschäftskritische, containerisierte Anwendungen kann es eine Abstraktionsschicht sein, die Anbieterwechsel, Rollouts und Betrieb standardisierbarer macht.

Der Portabilitäts-Check vor dem Kauf

Der wichtigste Portabilitätscheck findet nicht im Migrationsprojekt statt. Er findet vor dem Kauf statt, bevor ein Dienst geschäftskritisch wird. Claudia braucht dafür keinen 80-seitigen Architekturbericht. Sie braucht ein kurzes Review-Gate, das jeder neue kritische Anbieter bestehen muss. Jonas prüft die technische Seite, Mira prüft die operative Realität, Claudia entscheidet, ob die Abhängigkeit die Entlastung wert ist.

Die erste Frage lautet: Welche Daten müssen herauskommen, damit der Prozess weiterarbeiten kann? Nicht nur Kundennamen und E-Mail-Adressen, sondern Status, Anhänge, Freigaben, interne Notizen, Zuordnungen, IDs, Historie und Löschinformationen. Für diesen DACH-Industrieservice-Anbieter bedeutet das: Wenn ein Angebotsworkflow 600 Anfragen im Monat steuert, muss der Export mehr enthalten als Kontakte. Er muss zeigen, welche Anfrage in welchem Zustand ist, wer entschieden hat und welche Folgeaktion offen bleibt.

Die zweite Frage lautet: Welche Logik darf nicht im Tool verschwinden? Manche Regeln können bewusst im Tool liegen. Kritische Prozesslogik sollte aber dokumentiert, versioniert oder exportierbar sein. Wenn ein Rabatt ab einer bestimmten Wartungsvertragsklasse gilt, wenn eine Anfrage mit Maschinenstillstand anders eskaliert wird oder wenn ein Enterprise-Kunde zusätzliche Nachweise verlangt, darf diese Logik nicht nur aus Checkboxen in einem Vendor-Builder bestehen.

Die dritte Frage lautet: Wer besitzt Zugang, Dokumentation und Review? Ein Anbieterwechsel scheitert oft nicht an einem Datenformat, sondern an fehlendem Besitz. Niemand weiß, welches Servicekonto produktiv ist. Niemand hat den API-Schlüssel rotiert. Niemand kennt die letzte Schemaänderung. Deshalb gehört jede geschäftskritische Abhängigkeit in eine Abhängigkeitskarte: Owner, Daten, API, Credentials, Backup, Fehlerpfad, Exporttest, Ersatzoption.

Portable Architektur für kleine Teams

Portabilität bedeutet für KMU nicht, dass jedes System selbst gehostet werden muss. Das wäre oft schlechter Betrieb. Portable Architektur bedeutet, dass die wichtigsten Abhängigkeiten bewusst gewählt und mit Ausstiegsschlüssel betrieben werden. Managed Services dürfen Arbeit abnehmen, solange sie nicht das einzige Gedächtnis des Unternehmens werden.

Ein pragmatischer Stack für kleine Teams beginnt mit offenen Schnittstellen und dokumentierten Datenmodellen. APIs werden nicht nur "angebunden", sondern als Verträge behandelt: Version, Zweck, Datenfelder, Fehlerverhalten und Owner. Datenmodelle werden erklärt, nicht nur in Adminmasken konfiguriert. Wo Daten geschäftskritisch sind, braucht es einen Export- und Restore-Test. Wo Workflows geschäftskritisch sind, braucht es eine exportierbare oder zumindest nachvollziehbare Definition.

Infrastructure as Code ist der nächste Wiederholbarkeitsanker. Wenn Server, Netzwerke, Kubernetes-Manifeste, Rollen oder Automationsläufe in Git liegen, entstehen Review, Historie und Wiederaufbaupfad. Das ist keine Enterprise-Disziplin. Für ein Unternehmen mit 35 bis 45 internen Nutzern pro Woche ist es oft genau der Unterschied zwischen "Jonas erinnert sich" und "das System ist aus bekannter Revision rekonstruierbar".

Container und Kubernetes kommen dort ins Bild, wo Laufzeitportabilität den Aufwand rechtfertigt. Ein kleines Formular oder ein einmaliger Bericht braucht kein Cluster. Ein Kundenportal mit 240.000 Datensätzen, Integrationen zu CRM und Ticketing und klarer Weiterentwicklungsperspektive kann von einer portablen Laufzeitschicht profitieren. Planfold kann hier auf Kubernetes-Betrieb und cloud-native Delivery mit CKA- und CKAD-gestützter Kompetenz verweisen. LFCS unterstützt die Linux-Systembasis. Diese Zertifizierungen sind Fähigkeitsnachweise, keine Compliance-Badges.

Workflow-Automation folgt demselben Muster. n8n oder ähnliche Orchestrierung kann sehr wertvoll sein, wenn Workflows sichtbar, exportierbar, überwacht und mit Fehlerpfaden versehen sind. Ein n8n-Workflow, der Rechnungsdaten, Ticketstatus oder Angebotsentwürfe bewegt, braucht Owner, Logs, Testdaten, Umgebungsvariablen und einen menschlichen Freigabepunkt dort, wo Risiko entsteht. Automatisierung ohne Review verschiebt Lock-in nur von einem SaaS-Tool in einen anderen unsichtbaren Ablauf.

Vom Tool-Kauf zum Eigentumsmodell

Dieser DACH-Industrieservice-Anbieter muss nicht alle Anbieter austauschen. Das wäre weder realistisch noch sinnvoll. Das Ziel ist ein Eigentumsmodell: Welche Teile der digitalen Maschine gehören dem Unternehmen als Wissen, Daten, Code, Dokumentation und Betriebsverfahren, und welche Entlastung wird bewusst eingekauft?

Vor dem Review sieht der Angebotsworkflow so aus: Eine Anfrage kommt ins CRM, ein SaaS-Automation-Tool prüft Wartungsvertrag und Maschinentyp, erzeugt eine Aufgabe für Mira und bereitet eine Angebotsvorlage vor. Wenn eine API ausfällt, sieht Mira nur, dass die Aufgabe fehlt. Jonas weiß, dass irgendwo ein Webhook existiert, aber nicht, welche Felder ihn auslösen. Stefan hat den ursprünglichen Workflow gebaut, aber sein Vertrag läuft bald aus. Claudia kann einem Großkunden nicht sauber erklären, wie Anfrage, Kundendaten, Freigabe und Angebot zusammenhängen.

Nach 30 Tagen sieht derselbe Workflow anders aus. Die drei kritischsten Datenflüsse sind dokumentiert. Die beiden riskantesten API-Abhängigkeiten haben Owner, Feldliste, Fehlerverhalten und Kontaktadresse des Anbieters. Der wichtigste Angebotsworkflow hat eine exportierte Definition, ein kurzes Ablaufdiagramm, einen manuellen Fallback, einen Review-Termin und eine Liste der Credentials. Mira weiß, wo sie prüfen kann, ob ein Vorgang hängt. Jonas weiß, welche Teile portabel sind und welche nicht. Claudia kann sagen: "Wir nutzen diesen Anbieter bewusst, und hier ist unser Handover-Pack."

Die Zahlen bleiben illustrativ. 240.000 Kundendatensätze, 1,8 TB Projekt- und Serviceunterlagen, 7 produktive Integrationen und 9 Automationen sind keine Planfold-Kundendaten. Sie sind ein realistisches Modell für die Art von Komplexität, die in KMU entsteht, lange bevor jemand "Plattformteam" sagt. Der Nutzen liegt nicht in einer garantierten Ersparnis. Der Nutzen liegt in Entscheidungsfähigkeit: Das Unternehmen weiß, wo es abhängig ist, warum es abhängig ist und was ein Wechsel oder Handover bedeuten würde.

Das ist auch die Stelle, an der Datenlokalisierung und Portabilität zusammenlaufen. Wenn Sie nicht wissen, wo Daten liegen, wer sie verarbeitet, wie sie exportiert werden und welche Workflow-Zustände daran hängen, können Sie keine belastbare Anbieterentscheidung treffen. Portabilität ist deshalb keine Cloud-Spezialfrage. Sie ist eine Eigentumsfrage.

Wie Planfold Portabilität in den Betrieb einbaut

Planfold behandelt Portabilität nicht als Notfallordner, sondern als Betriebsdisziplin. Das passt besonders für Mittelstand und Solo-Founder-Teams mit 10 bis 100 Mitarbeitenden, die keine eigene Plattformabteilung haben. Die Aufgabe ist nicht, jede Verantwortung intern zu verlagern. Die Aufgabe ist, das Sorglospaket so zu bauen, dass der Ausstiegsschlüssel erhalten bleibt.

Plan bedeutet: Abhängigkeiten, Datenflüsse, Zugänge, Exportformate und provider-spezifische Logik auditieren. Welche Systeme tragen Umsatz, Kundenkommunikation, Projektwissen oder Betrieb? Welche API-Verträge sind dokumentiert? Welche Backups wurden wirklich wiederhergestellt? Welche Credentials hängen an Personen? Welche Kunden- oder Compliance-Fragen könnten morgen kommen? Das Ergebnis ist keine Angstliste, sondern eine priorisierte Abhängigkeitskarte.

Unfold bedeutet: die erste portable Schicht bauen. Das kann ein dokumentiertes Datenmodell sein, ein Git-Repository für Infrastrukturdefinitionen, ein Kubernetes- oder Container-Deployment dort, wo Laufzeitportabilität sinnvoll ist, ein n8n-Workflow mit Export, Owner, Fehlerpfad und Review oder eine DACH-Hosting-Option, wenn Governance und Kundenanforderungen das verlangen. Managed Convenience bleibt erlaubt. Sie wird nur nicht mehr blind gekauft.

Resonate bedeutet: den Ausstiegspfad aktuell halten. Quartalsweise Review der Top-5-Abhängigkeiten. Export- und Restore-Tests. Rotation von Servicekonten. Monitoring für kritische Automationen. Handover-Pack für Kundennachweise. Protokollierte menschliche Freigaben bei risikoreichen Entscheidungen. So bleibt Portabilität nicht ein Projektartefakt, sondern Teil des Betriebs.

Planfold kann Architektur für Portabilität, dokumentierte Ausstiegspfade, Kubernetes-Betrieb, n8n-Automation, Infrastructure as Code, DACH-first oder vertrauenswürdige Hosting-Optionen und Compliance-Readiness-Evidenz unterstützen. Planfold ersetzt keine Rechtsberatung, keine Datenschutzbewertung, keine formale Compliance-Zertifizierung und kein Kundenaudit. Genau diese Grenze ist wichtig: Technische Architektur kann Nachweise liefern und Review erleichtern. Die rechtliche Bewertung bleibt bei den zuständigen Fachleuten.

Ein 30-Tage-Startplan gegen stillen Lock-in

Sie müssen nicht mit einer Migration starten. Starten Sie mit Sichtbarkeit. Ein 30-Tage-Plan reicht, um aus einem diffusen Lock-in-Gefühl eine belastbare Arbeitsliste zu machen.

Woche 1: Abhängigkeiten kartieren. Listen Sie die 20 wichtigsten Tools, Cloud-Dienste, Datenbanken, Automationen und Integrationen. Markieren Sie die fünf Abhängigkeiten, bei denen ein Ausfall, Preissprung oder Anbieterwechsel den Betrieb am stärksten treffen würde. Für jede markieren Sie Owner, Datenart, Nutzerkreis, Verträge, Integrationen und kritische Fristen.

Woche 2: Exporte und Zugang prüfen. Testen Sie nicht alle Systeme. Wählen Sie die wichtigste Datenquelle und den wichtigsten Workflow. Exportieren Sie Daten, prüfen Sie Felder, Metadaten, Anhänge und Status. Prüfen Sie Adminzugänge, Servicekonten, API-Schlüssel, SSO-Regeln und Backup-Status. Dokumentieren Sie Lücken ohne Schuldzuweisung.

Woche 3: einen kritischen Workflow entkoppeln. Nehmen Sie den Workflow, bei dem der größte Schaden durch Unsichtbarkeit entsteht. Schreiben Sie den Ablauf auf, sichern Sie die Feldliste, benennen Sie einen Owner, definieren Sie einen Fehlerpfad und prüfen Sie, ob die Logik exportiert oder versioniert werden kann. Wenn Automatisierung beteiligt ist, bauen Sie eine menschliche Freigabe dort ein, wo Risiko entsteht.

Woche 4: Review-Rhythmus festlegen. Portabilität stirbt, wenn sie nie wieder angesehen wird. Legen Sie eine quartalsweise Prüfung fest: Top-5-Abhängigkeiten, Exporte, Zugangseigner, Backup-Status, Ersatzpfad, offene Risiken. Das muss keine schwere Governance sein. Es muss wiederholbar sein.

Wenn Sie diesen Plan ernst nehmen, ist das Ergebnis nicht Anbieterfeindlichkeit. Es ist bessere Einkaufs- und Architekturdisziplin. Sie können weiterhin Managed Services nutzen. Sie können weiterhin Cloud kaufen. Sie können weiterhin SaaS einsetzen. Der Unterschied ist: Die Abhängigkeit hat einen Namen, einen Owner, einen Exportpfad, einen Fehlerpfad und einen Review-Termin.

Planen. Entfalten. Souverän bleiben.