Software-Strategie

Vendor-Lock-in vermeiden: Austauschbarkeit als Architekturprinzip

Der wahre Preis eines Tools steht nicht auf der Preisseite, sondern in der Antwort auf eine Frage: Was kostet es, wieder herauszukommen? Wer Austauschbarkeit von Anfang an mitdenkt, verhandelt aus Stärke — und migriert im Ernstfall in Wochen statt Jahren.

Autor Julien MarschallVeröffentlicht 2026-07-31Lesezeit 6 Min.

Vendor-Lock-in entsteht selten durch böse Absicht und fast immer schleichend: Ein Tool wird eingeführt, Daten fliessen hinein, Prozesse wachsen darum herum, Sonderfelder und Automationen docken an. Drei Jahre später verdoppelt der Anbieter die Preise oder stellt eine Kernfunktion ein — und die nüchterne Analyse ergibt: Ein Wechsel würde sechsstellig kosten. Genau mit dieser Rechnung kalkulieren Anbieter. Wechselkosten sind Verhandlungsmacht, und zwar die des Verkäufers.

Exit-Kosten gehören in jede Tool-Entscheidung

Die übliche Bewertung vergleicht Lizenzpreis, Funktionsumfang und Einführungsaufwand. Was fast immer fehlt, ist die vierte Spalte: die Exit-Kosten — der geschätzte Aufwand, um Daten, Prozesse und Integrationen in ein Nachfolgesystem zu überführen. Diese Zahl muss keine Kommastelle haben; schon die Einordnung „ein Wochenende", „ein Projekt" oder „praktisch unmöglich" verändert Entscheidungen. Ein Tool, das 20 Prozent günstiger ist, aber keinen brauchbaren Export bietet, ist häufig das teurere Angebot.

Datenexport: die erste Frage vor dem Kauf

Daten sind der Teil eines Systems, der sich nicht neu schreiben lässt. Deshalb ist die Exportfähigkeit das härteste Einzelkriterium. Vor jeder Einführung gehört geprüft:

  • Vollständigkeit: Kommen alle Daten heraus — auch Anhänge, Historien, Kommentare und Sonderfelder — oder nur die Kerntabellen?
  • Format: CSV, JSON oder SQL-Dump sind weiterverarbeitbar; ein proprietäres Binärformat ist wertlos
  • Weg: Selbstbedienung per Knopf oder API — oder nur auf Anfrage beim Support, im teuersten Tarif, gegen Gebühr?
  • Praxis-Test: Export einmal im Jahr tatsächlich durchführen und stichprobenartig prüfen — ein nie getesteter Export ist wie ein nie getestetes Backup

Offene Standards schlagen proprietäre Eleganz

Wo es einen etablierten Standard gibt, ist er die Versicherung gegen Abhängigkeit: SQL statt proprietärer Abfragesprache, OIDC/SAML statt Anbieter-Login, S3-kompatibler Objektspeicher, iCal für Termine, offene E-Mail-Protokolle statt geschlossener Messaging-Silos. Der Standard ist manchmal etwas unbequemer als die hauseigene Speziallösung des Anbieters — aber jede Stunde, die er kostet, kauft die Freiheit, den Anbieter zu wechseln, ohne die Anwendung neu zu denken. Faustregel: Proprietäre Features nutzen, wo sie klaren Mehrwert bringen, aber nie im Fundament.

Abstraktionsschichten: Austauschbarkeit im eigenen Code

In selbst entwickelter Software entscheidet die Architektur über den Lock-in. Wer den Zahlungsanbieter, den E-Mail-Versand oder das KI-Modell an hundert Stellen direkt aufruft, hat hundert Migrationsbaustellen. Wer stattdessen eine schmale eigene Schnittstelle definiert — „sende Rechnung", „erzeuge Text" — und den Anbieter dahinter kapselt, tauscht später genau eine Datei. Gerade bei KI-Modellen ist das aktuell der relevanteste Fall: Preise, Qualität und Anbieter verschieben sich im Monatsrhythmus. Ein Adapter-Layer macht aus einem strategischen Risiko eine Konfigurationszeile.

Austauschbarkeit ist kein Misstrauensvotum gegen einen Anbieter, sondern eine Verhandlungsposition: Wer nachweislich wechseln kann, bekommt bessere Preise, besseren Support und ehrlichere Roadmap-Antworten — und muss deshalb meist gar nicht wechseln.

Nicht alles muss austauschbar sein

Das Gegenextrem ist genauso teuer: Wer jede Komponente hinter drei Abstraktionsschichten versteckt und nur den kleinsten gemeinsamen Nenner aller Anbieter nutzt, baut langsamer, komplexer und schlechter. Die pragmatische Linie: Kerndaten und Kernprozesse — Kunden, Aufträge, Finanzen — brauchen harte Exit-Optionen. Bei Randsystemen wie dem Umfrage-Tool oder dem Whiteboard reicht die Gewissheit, dass die Daten exportierbar sind und der Verlust verschmerzbar wäre. Lock-in ist erlaubt, wo er billig ist, und verboten, wo er existenziell wird.

Der Exit-Plan als lebendes Dokument

Für die drei bis fünf kritischsten Systeme lohnt ein einseitiger Exit-Plan: Wo liegen die Daten, wie kommen sie heraus, welche Alternativen existieren, was wäre der grobe Migrationsaufwand? Dieses Dokument kostet einen Nachmittag im Jahr und verwandelt jede künftige Preiserhöhungs-Mail von einer Drohung in eine Rechenaufgabe. Verträge lassen sich zusätzlich absichern: Exportpflicht bei Vertragsende, Datenherausgabe in offenem Format und Übergangsfristen gehören in jede Verhandlung mit strategischen Anbietern.

Kein System ist für die Ewigkeit gewählt. Wer Datenexport prüft, Standards bevorzugt und die wenigen kritischen Abhängigkeiten kapselt, behält die einzige Eigenschaft, die in der Tool-Landschaft dauerhaft zählt: die Fähigkeit, morgen anders zu entscheiden als gestern.

Tool-Stack mit Exit-Option statt Abhängigkeit

Wir prüfen Ihre kritischen Systeme auf Lock-in-Risiken, definieren Exit-Pläne und bauen Abstraktionsschichten dort ein, wo sie sich wirklich rechnen.

Architektur-Check anfragen →

Häufige Fragen

Ist Vendor-Lock-in immer schlecht?
Nein. Lock-in ist der Preis für Integrationstiefe und Komfort — die Frage ist, ob er bewusst eingegangen wird. Kritisch wird es, wenn Kerndaten oder Kernprozesse ohne Exit-Option in einem proprietären System liegen und der Anbieter das bei Preisverhandlungen weiss.
Was ist der wichtigste einzelne Schutz gegen Lock-in?
Der regelmässig getestete Datenexport in einem offenen, dokumentierten Format. Wer seine Daten jederzeit vollständig und maschinenlesbar herausbekommt, kann fast jedes Tool ersetzen — es kostet dann Projektaufwand, aber keine Substanz.
Lohnt sich eine Abstraktionsschicht für jedes Tool?
Nein, das wäre Overengineering. Abstraktion lohnt sich dort, wo ein Anbieterwechsel realistisch und teuer wäre: Zahlungsanbieter, Versand, KI-Modelle, Cloud-Dienste. Bei Randsystemen mit gutem Datenexport reicht die Export-Option als Absicherung.