Vendor-Lock-in erkennen und vermeiden

Was Vendor-Lock-in für dich bedeutet

Vendor-Lock-in heisst: Du kannst einen Anbieter, eine Plattform oder eine Technologie nicht mehr wechseln, ohne dafür unverhältnismässig viel zu zahlen, zu riskieren oder umzubauen. Du bleibst nicht, weil die Lösung die beste ist, sondern weil das Weggehen zu teuer geworden ist. Darin steckt der ganze Unterschied. Eine gute Bindung entsteht aus Zufriedenheit, ein Lock-in aus fehlenden Alternativen.

Meistens steckt keine böse Absicht dahinter. Manchmal schon, oft aber ist es einfach das Ergebnis von Entscheidungen, die im Moment bequem waren und die niemand auf ihre Spätfolgen abgeklopft hat. Wer beim Projektstart nur auf Tempo und Preis schaut, baut sich die Falle selbst. Deshalb gehört das Thema auf den Tisch, bevor der erste Vertrag unterschrieben ist, und nicht erst an dem Tag, an dem du raus willst.

Die vier Arten von Vendor-Lock-in

Lock-in ist kein einzelnes Problem. Es fächert sich in vier Formen auf, die meist gemeinsam auftreten, aber jeweils eigene Ursachen und eigene Gegenmittel haben. Wer sie auseinanderhalten kann, sieht im konkreten Fall schneller, wo er wirklich festsitzt.

Plattform-Lock-in entsteht, wenn deine Anwendung tief in die proprietären Dienste einer Plattform verwoben ist. Stell dir vor, deine Software läuft auf einer Cloud und stützt sich dort auf eine Spezialdatenbank, die es nur bei diesem Anbieter gibt, dazu auf seinen hauseigenen Login-Dienst und seine eigenen Funktionen für Hintergrundjobs. Jede dieser Bequemlichkeiten spart heute Arbeit und verzahnt dich morgen mit der Plattform. Ein Umzug heisst dann nicht, ein paar Dateien zu kopieren, sondern grosse Teile der Anwendung neu zu bauen.

Code-Lock-in betrifft den Quellcode. Gehört er dir nicht, darfst du nicht hineinschauen, oder versteht ihn ausser dem ursprünglichen Team niemand, dann hast du ein Problem. Selbst rechtliches Eigentum nützt wenig, wenn der Code undokumentiert und verschachtelt ist und an exotische Werkzeuge hängt, die kaum jemand beherrscht. Das Tückische: Es fällt oft erst auf, wenn ein neuer Dienstleister einen Blick ins Repository wirft und abwinkt.

Daten-Lock-in unterschätzen KMU am häufigsten. Deine Kunden, Aufträge, Rechnungen und Verläufe sind das Wertvollste im ganzen System. Kannst du sie nicht in einem brauchbaren, offenen Format herausziehen, bist du gefangen. Ein System, das nur PDF-Ausdrucke oder eine zerfledderte CSV ausspuckt, hält deine eigene Substanz als Geisel. Beim Wechsel zählt nicht, ob ein Export-Knopf existiert, sondern ob das Ergebnis vollständig, strukturiert und woanders wieder einlesbar ist.

Anbieter-Lock-in ist die menschliche und vertragliche Ebene. Das Wissen über dein System sitzt in einem einzigen Unternehmen, manchmal in einem einzigen Kopf. Lange Kündigungsfristen, exklusive Wartungsklauseln oder Zugangsdaten, die dem Anbieter gehören, schnüren das enger zu. Erhöht dieser eine Anbieter die Preise, wird langsam oder verschwindet vom Markt, hast du keinen Plan B.

Woran du Vendor-Lock-in früh erkennst

Die gute Nachricht: Lock-in kündigt sich fast immer an. Du musst nur wissen, worauf du achtest, und die Fragen stellen, solange du noch Verhandlungsmacht hast. Also vor und während der Zusammenarbeit, nicht erst, wenn du schon gehen willst.

Das erste Zeichen ist eine ausweichende Antwort auf die Eigentumsfrage. Frag direkt: Gehört mir der Quellcode, und bekomme ich ihn jederzeit ausgehändigt? Wer hier herumdruckst, auf Lizenzmodelle verweist oder den Code zum Betriebsgeheimnis erklärt, sagt dir zwischen den Zeilen, dass du nur ein Nutzungsrecht kaufst, keine Substanz.

Das zweite Zeichen ist fehlende oder veraltete Dokumentation. Kann dir niemand sagen, wie das System aufgebaut ist, wo es läuft, welche Dienste es nutzt und wie ein neuer Entwickler es zum Laufen bringt, dann lebt dieses Wissen nur in ein paar Köpfen. Genau das ist Anbieter-Lock-in in Reinform. Doku ist kein Luxus, sondern deine Versicherung für den Tag, an dem die Zusammenarbeit endet.

Das dritte Zeichen sind Zugangsdaten, die nicht dir gehören. Laufen Domain, Hosting, Datenbank und Repository auf den Accounts des Anbieters statt auf deinen, hast du im Streitfall keinen Zugriff auf dein eigenes Produkt. Eigene Accounts, zu denen du den Dienstleister nur einlädst, drehen das Verhältnis um.

Das vierte Zeichen ist Intransparenz beim Export. Bitte früh um einen vollständigen Datenexport und sieh dir an, was zurückkommt. Strukturierte, offene Formate sind ein gutes Zeichen. Ausreden oder Bruchstücke sagen dir ebenso klar, woran du bist. Das hängt eng damit zusammen, warum viele SaaS-Projekte scheitern: selten an den grossen technischen Fragen, fast immer an den unscheinbaren Versäumnissen bei Eigentum, Doku und Daten.

Wie Code-Eigentum, Doku und offene Standards schützen

Der wirksamste Schutz ist kein Trick, sondern eine Haltung, die durchs ganze Projekt zieht. Sie ruht auf drei Säulen.

Der Code gehört dir und liegt bei dir. Nicht als Klausel im Vertrag, sondern real: in einem Repository unter deiner Kontrolle, in das du jederzeit hineinschauen kannst und das so geschrieben ist, dass auch ein fremdes Team es übernehmen könnte. Sauberer, lesbarer Code ist kein ästhetisches Detail. Er ist die Bedingung dafür, den Anbieter wechseln zu können, ohne von vorne anzufangen. Was bei der Code-Frage genau zu klären ist, steht in der Übersicht, wem der Code gehört und wie eine saubere Übergabe aussieht.

Die Dokumentation macht das System übergebbar. Eine brauchbare Übergabe-Doku beschreibt die Architektur, die genutzten Dienste, das Aufsetzen einer Entwicklungsumgebung, die Abläufe für Inbetriebnahme und Betrieb und die bekannten Schwachstellen. Der Test ist simpel: Könnte ein neuer Entwickler allein damit das System verstehen und betreiben? Wenn ja, bist du frei. Wenn nein, sitzt du fest.

Offene Standards halten die Türen offen. Wo immer es geht, baut ein System auf verbreiteten, herstellerunabhängigen Technologien auf statt auf proprietären Speziallösungen. Eine Standard-Datenbank statt eines exklusiven Cloud-Dienstes, ein gängiges Framework statt eines Nischenwerkzeugs, offene Schnittstellen statt geschlossener Formate. Das verbietet die bequemen Plattformdienste nicht, verlangt aber, dass du jede solche Entscheidung bewusst triffst und weisst, was sie dich im Ernstfall kostet. Diese Abwägung steckt mitten in der Frage, ob du selbst baust, eine Agentur nimmst, No-Code wählst oder ins Produktstudio gehst.

Genau hier trennt sich ein Anbieter, der Produkte nicht nur baut, sondern selbst betreibt, von einer reinen Agentur. Wer eigene Produkte wie Wortfreunde und Reazon über Jahre selbst weiterentwickelt und am Laufen hält, kennt den Schmerz schlecht übergebbarer Systeme aus erster Hand und baut von Anfang an so, dass eine Übergabe möglich bleibt. Bei Individualsoftware für KMU heisst das konkret: dein Code, deine Accounts, eine Doku, mit der ein anderes Team weiterarbeiten könnte.

Wann sich der Aufwand gegen Lock-in nicht lohnt

Nicht jedes System braucht denselben Aufwand. Bei einem kleinen internen Tool, das ohnehin in zwei Jahren ersetzt wird, lohnt sich der Vollausbau mit Architektur-Doku und Replatforming-Plan kaum. Und ein bewusst gewählter Plattformdienst kann die richtige Wahl sein, solange du den Preis im Ernstfall kennst und akzeptierst. Eine fertige SaaS-Standardlösung von der Stange ist sogar fast immer eine Art Lock-in, und trotzdem oft genau richtig, wenn sie billiger und schneller ist als alles Eigene.

Gefährlich wird es erst, wenn ein System über Jahre dein Geschäft trägt und du trotzdem keinen Zugriff auf Code, Accounts und Daten hast. Die Faustregel: Je länger ein System leben soll und je mehr von deinem Geschäft daran hängt, desto mehr zahlt sich Unabhängigkeit aus. Bei einem Wegwerf-Prototyp kannst du Lock-in bewusst in Kauf nehmen.

Was eine gute Übergabe konkret enthält

Ob du eine Zusammenarbeit beginnst oder beendest, eine konkrete Checkliste hilft. Beim Start kostet sie wenig, beim Wechsel sehr viel, wenn sie fehlt.

• Vollständiges Repository inklusive Historie, kein gezippter Schnappschuss.
• Alle Zugangsdaten und Accounts für Hosting, Domain, Datenbank und Drittdienste, idealerweise von Beginn an auf deinen Namen.
• Vollständiger, strukturierter Datenexport in offenen Formaten, getestet auf Wiedereinlesbarkeit.
• Betriebs- und Architektur-Doku, mit der ein neues Team das System aufsetzen und betreiben kann.
• Liste der Abhängigkeiten: welche externen Dienste das System braucht, was sie ungefähr kosten und wie man sie ersetzen könnte.

Wurde von Anfang an sauber gearbeitet, ist diese Übergabe eine Sache von Tagen. Wurde nie an sie gedacht, frisst das Rekonstruieren der Doku und das Entwirren der Abhängigkeiten schnell Wochen, manchmal mehr, als eine teilweise Neuentwicklung gekostet hätte. Genau das macht Lock-in so teuer: Die Rechnung kommt spät, dafür umso grösser.

Freiheit als Bauprinzip

Vendor-Lock-in ist kein Schicksal, sondern die Folge von Entscheidungen, die du beeinflussen kannst. Wer von Anfang an darauf besteht, den Code zu besitzen, die Accounts zu kontrollieren, eine brauchbare Doku zu verlangen und auf offene Standards zu setzen, kauft sich die wichtigste Eigenschaft jeder Software: die Freiheit, sie weiterzugeben. Diese Freiheit kostet beim Bauen ein bisschen zusätzliche Disziplin und zahlt sich an dem Tag aus, an dem du sie brauchst.

Prüf deine bestehenden Systeme an den Warnzeichen oben, stell die Eigentumsfrage, bitte um einen Testexport. Innerhalb eines Nachmittags weisst du, wie frei du wirklich bist. Und wenn du für ein neues Vorhaben abschätzen willst, was eine saubere Basis kostet, hilft dir der Blick darauf, was ein MVP kostet, die richtigen Treiber von Anfang an einzuplanen.