Vendor Lock-in: Wie Sie Ihre IT-Abhängigkeit reduzieren

Wer einmal tief in Microsoft 365, SAP oder Salesforce steckt, weiß: Raus ist schwerer als rein. Daten, Prozesse, Mitarbeiterwissen — alles wächst mit der Zeit in ein System hinein, das sich als alternativlos präsentiert. Genau das ist Vendor Lock-in. Und für viele österreichische Unternehmen ist es längst kein hypothetisches Risiko mehr, sondern gelebter Alltag.

Die gute Nachricht: Lock-in entsteht nicht über Nacht — und er lässt sich gezielt reduzieren.

Was Vendor Lock-in wirklich bedeutet

Vendor Lock-in bezeichnet die Situation, in der ein Unternehmen so tief von einem einzigen Anbieter abhängt, dass ein Wechsel unverhältnismäßig teuer, risikoreich oder schlicht unmöglich erscheint. Das klingt nach einem technischen Problem — ist aber in erster Linie ein wirtschaftliches.

Die drei klassischen Formen:

Daten-Lock-in

Ihre Daten liegen in proprietären Formaten, die ohne den Anbieter kaum nutzbar sind. SharePoint-Bibliotheken, Salesforce-Objekte, SAP-Datenstrukturen — alles funktioniert wunderbar im Ökosystem des Herstellers. Außerhalb davon beginnen die Probleme.

Prozess-Lock-in

Ihre Abläufe sind um das Tool herum gebaut. Teams kommuniziert über Teams, Genehmigungen laufen über Power Automate, Berichte kommen aus Power BI. Nicht weil das zwingend die beste Lösung ist, sondern weil es bereits so ist.

Skill-Lock-in

Ihre Mitarbeiter kennen SAP, aber kein alternatives ERP. Ihr IT-Team administriert Azure, aber kein anderes Cloud-Fundament. Das Wissen ist anbieterspezifisch — und damit selbst ein Abhängigkeitsfaktor.

Die wahren Kosten — was Ihr Anbieter nicht in der Preisliste zeigt

Microsoft 365 hat in den letzten Jahren mehrfach die Preise angehoben. Gleichzeitig hat die österreichische Datenschutzbehörde (DSB) festgestellt, dass Microsoft Nutzerdaten für eigene Zwecke verarbeitet — was nach DSGVO problematisch ist. Was das für Unternehmen bedeutet, wird oft erst beim nächsten Audit klar.

Bei SAP sind es die indirekten Zugriffsgebühren, die überraschend teuer werden. Wenn ein Drittsystem — etwa ein CRM oder ein Webshop — Daten in SAP schreibt, kann das eine Lizenzpflicht auslösen. Anwaltliche Stellungnahmen und Nachforderungen im sechsstelligen Bereich sind keine Seltenheit.

Salesforce bindet über AppExchange und proprietäre APIs an sich. Migration bedeutet: Daten exportieren (was funktioniert), Workflows nachbauen (was aufwändig ist), Integrationen neu verbinden (was teuer ist). Eine realistische Migration aus Salesforce dauert 6 bis 18 Monate — und das ist keine Schätzung von Außenstehenden, sondern von Unternehmen, die es getan haben.

Dazu kommen versteckte Wechselkosten, die in keiner TCO-Berechnung stehen: Schulungszeit für neue Tools, temporärer Produktivitätsverlust, externe Berater für die Datenmigration, paralleler Betrieb beider Systeme.

Open Source als strukturelle Antwort

Der Ausweg aus dem Lock-in ist kein einzelner Schritt — es ist eine Entscheidung über die Art der Abhängigkeiten, die man akzeptiert. Open-Source-Software bindet an niemanden. Der Quellcode ist offen, die Daten bleiben in Standardformaten, die Community entwickelt weiter — unabhängig von Unternehmensinteressen eines einzelnen Herstellers.

Das bedeutet nicht, dass Open Source kostenlos ist oder ohne Aufwand läuft. Aber die Abhängigkeit verschiebt sich: von proprietären Lizenzen hin zu eigenem Know-how oder einem Dienstleister, den man selbst wählt — und wechseln kann.

– Microsoft 365 → Nextcloud, Collabora Office, n8n (statt Power Automate)

– Salesforce → Odoo (ERP + CRM, Apache-Lizenz, selbst gehostet)

– SAP → Odoo (für KMU oft überraschend vollständig)

– GitHub / Azure DevOps → Forgejo (selbst gehostet, GitHub-API-kompatibel)

breida betreibt die eigene Infrastruktur mit diesen Tools — nicht als Experiment, sondern als produktive Umgebung. Was wir empfehlen, haben wir selbst im Einsatz.

Die Ausstiegsstrategie in der Praxis

Ein Unternehmen, das heute 200 Mitarbeiter in Microsoft 365 hat, wird das nicht bis nächsten Monat migrieren. Und das ist auch nicht das Ziel.

Schritt 1 — Audit: Was nutzen Sie wirklich? Nicht was lizenziert ist, sondern was täglich genutzt wird. Oft stellt sich heraus: 80 % des Betriebs hängen an E-Mail, Kalender und Dateispeicher — und genau das sind die am einfachsten ersetzbaren Funktionen.

Schritt 2 — Priorisierung: Welche Abhängigkeiten kosten am meisten? Wo sind die größten Risiken — rechtlich, betrieblich, finanziell? Das sind die Startpunkte.

Schritt 3 — Parallelbetrieb: Kein Big-Bang-Wechsel. Ein Team wechselt, ein Prozess migriert, eine Integration wird neu aufgebaut. Vier bis sechs Monate Parallelbetrieb sind normal und sinnvoll.

Schritt 4 — Standardisierung: Keine proprietären Formate mehr für neue Daten. ODF statt .docx, offene APIs statt Vendor-SDKs, CSV-Export als Pflicht im nächsten Tool-Vertrag.

Dieser Prozess ist mühsam — aber machbar. Und er zahlt sich aus: direkt über eingesparte Lizenzkosten, und langfristig als Verhandlungsposition gegenüber jedem künftigen Anbieter.

Was österreichische Entscheider konkret tun können

Das KMU Digital Programm der Wirtschaftskammer Österreich fördert Digitalisierungsprojekte mit bis zu 8.400 Euro — das schließt explizit auch Open-Source-Migrationen ein.

Die Datenschutzbehörde (DSB) hat in mehreren Bescheiden klargestellt: Die Nutzung von US-amerikanischen Cloud-Diensten ist nicht automatisch DSGVO-konform, nur weil der Anbieter Server in der EU betreibt. Der US Cloud Act spielt eine entscheidende Rolle — das ist kein theoretisches Risiko, sondern Gegenstand laufender Verfahren.

Wer sich heute mit Vendor Lock-in auseinandersetzt, tut es also nicht nur aus Kostengründen, sondern auch aus Compliance-Gründen.

Fazit

Vendor Lock-in ist selten eine bewusste Entscheidung — er entsteht durch viele kleine, pragmatische Entscheidungen über Jahre. Genau deshalb lässt er sich auch nur durch viele kleine, gezielte Gegenbewegungen abbauen. Der erste Schritt ist, überhaupt zu wissen, wo und wie tief die Abhängigkeiten sind.

Ein Audit kostet wenig. Die Überraschungen danach meistens mehr.