Vendor Lock-in beschreibt die wirtschaftliche und technische Abhängigkeit eines Kunden von einem einzelnen Anbieter, die einen Wechsel auf ein konkurrierendes Produkt unverhältnismäßig teuer, riskant oder zeitaufwendig macht. Der Begriff stammt aus der IT-Ökonomie und ist im B2B-Software-Kontext (SaaS-Plattformen, ERP-Systeme, Shop-Systeme, Cloud-Hyperscaler) zentral, weil ein einmal getroffenes Architektur-Investment dort oft auf fünf bis zehn Jahre angelegt ist.
Wie Vendor Lock-in entsteht
Lock-in ist selten das Ergebnis einer einzelnen Entscheidung. Er entsteht schichtweise, oft als Nebenwirkung von Komfort. Drei Hebel laufen typischerweise parallel und verstärken sich gegenseitig.
Der erste ist der Datenhebel. Sobald geschäftskritische Daten (Bestellhistorien, Kundenprofile, Konfigurations- und Vertragslogik) im proprietären Datenmodell eines Anbieters liegen, ist ein Exit nicht mehr nur eine technische Migration, sondern eine Datenrekonstruktion. Datenexport-Funktionen klingen auf dem Papier nach Freiheit, in der Praxis exportieren sie aber meist nur die Rohdaten, nicht die im System aufgebauten Beziehungen, Segmente und abgeleiteten Felder. Wer drei Jahre HubSpot-Lead-Scoring oder Salesforce-Validation-Rules kuratiert hat, hat nicht nur Datensätze, sondern eingespielte Logik, die nicht in einer CSV mitkommt.
Der zweite ist der Integrationshebel. Mit jedem Drittsystem, das auf APIs, Webhooks oder Datenformate des Anbieters trainiert wurde, wächst die Wechselrechnung. Das ist die typische Stelle, an der Lock-in-Risiko in Mittelstands-Architekturen unterschätzt wird: nicht das Kernsystem ist der Kern des Schadens, sondern das Dutzend integrierter Tools drumherum, die alle auf der API-Form des aktuellen Anbieters bauen.
Der dritte ist der Personalhebel. Sobald ein Team mehrjährige Expertise auf einer spezifischen Plattform aufgebaut hat (Salesforce-Apex-Entwickler, Shopify-Liquid-Theme-Spezialisten, SAP-Berater), sind die Wechselkosten nicht nur Code, sondern Wissenstransfer. Externe Agenturen, die mit der ablösenden Plattform vertraut sind, kosten in der Lernkurve. Interne Mitarbeiter:innen müssen umgeschult oder ersetzt werden. Bei seltenen Spezialisierungen ist der Markt zudem dünn und teuer.
Die vier typischen Erscheinungsformen
Vendor Lock-in ist kein einheitliches Phänomen. In der Praxis tauchen vier Spielarten auf, die jeweils einen anderen Ausgang haben.
Daten-Lock-in
Daten liegen in einem Schema, das es nur bei diesem Anbieter gibt. Datenmodelle wie Salesforces Custom Objects, Shopifys Metaobjects oder SAPs IDocs sind so spezifisch, dass ein 1:1-Export auf ein neutrales Format praktisch unmöglich ist. Die typische Folge: Migration heißt nicht „Daten verschieben", sondern „Daten interpretieren und neu modellieren".
API- und Format-Lock-in
Eine Plattform definiert eigene Schnittstellen-Konventionen, an die sich Integrationen anpassen müssen. Wenn der Anbieter API-Versionen abkündigt oder Rate-Limits ändert, fallen Integrationen ohne Vorwarnung aus. Konsequenz: jede Integration ist eine Wette auf die langfristige API-Stabilität des Anbieters.
Ökosystem-Lock-in
Der Anbieter bietet ein Bundle aus mehreren Produkten an, deren Wert vor allem in ihrer Integration miteinander liegt. Beispiele: die Salesforce-Suite (Sales Cloud, Service Cloud, Marketing Cloud, Commerce Cloud), Microsoft 365, das Adobe-Experience-Cloud-Ökosystem. Wer einmal zwei oder drei Bausteine nutzt, zahlt einen wachsenden Wechselpreis, weil jeder Einzelersatz die Bundle-Synergien aushebelt.
Vertraglicher Lock-in
Mehrjährige Verträge mit Vorab-Commitments, Mindestlaufzeiten oder umsatzabhängigen Lizenzen binden Kunden auch dann, wenn die Technik problemlos austauschbar wäre. Hier ist der Lock-in nicht im Code, sondern im Papier.
Warum Vendor Lock-in für den Mittelstand besonders relevant ist
Im Konzern-Umfeld wird Vendor Lock-in oft als kalkuliertes Risiko akzeptiert: Die schiere Größe macht Verhandlungsmacht, und Replatforming-Budgets im zweistelligen Millionenbereich sind in Ausnahmefällen darstellbar. Im Mittelstand kippt diese Rechnung. Ein wachstumsstarkes Unternehmen, dessen Lizenzen umsatzabhängig skalieren, bezahlt jeden eigenen Erfolg doppelt. Salesforce Commerce Cloud beispielsweise lizenziert für B2C über einen Prozentsatz des GMV (laut Salesforce-Listentarifen 1 % Starter, 2 % Growth, 3 % Plus). Wer auf 50 Millionen Euro GMV wächst, zahlt bei 1,5 % bereits 750.000 Euro Plattformgebühr pro Jahr, unabhängig davon, ob die Plattform in diesem Jahr neue Werte geschaffen hat.
Gleichzeitig fehlen dem Mittelstand die internen Spezialisten-Pools, mit denen Konzerne Lock-in-Schäden teilweise abfedern. Ein 80-Personen-Unternehmen kann sich keinen dauerhaften Salesforce-Architekt:innen-Pool leisten, der bei einem Plattformwechsel im Haus bleibt; eine externe Agentur an der Migration zu binden ist die Norm, mit den entsprechenden Risikoaufschlägen.
Konkretes Beispiel: Shopify und das Theme-Investment
Ein typisches Lock-in-Pattern aus dem D2C-Mittelstand: Ein Shop startet auf Shopify mit einem leicht angepassten Standard-Theme. Im Lauf von zwei bis drei Jahren wachsen aus Anpassungen vollständige Custom-Themes mit hunderten Stunden Frontend-Arbeit, geschrieben in Shopifys eigener Template-Sprache Liquid. Apps aus dem Shopify-App-Store sind tief integriert, oft mit Datenmodellen, die nur innerhalb der Plattform Sinn ergeben. Kundenservice-Workflows laufen über Shopify-Flow, das nirgendwo sonst existiert.
Beim Wechsel auf ein offenes System wie Shopware 6 oder ein Headless-Setup mit MedusaJS ist nicht primär die Datenmigration das Problem (Bestellungen und Kunden lassen sich exportieren), sondern die Rekonstruktion der über Jahre gewachsenen Logik. Realistisches Migrationsprojekt: zwölf bis vierundzwanzig Monate, abhängig von Custom-Tiefe. Genau dieser Zeitraum ist der eigentliche Preis des Lock-ins.
Strategien zur Vermeidung von Vendor Lock-in
Lock-in ist nicht binär. Es gibt keine Architektur, die völlig anbieterunabhängig ist, und es gibt selten gute Gründe, jede Lock-in-Quelle gleich konsequent zu vermeiden. Die Frage ist nicht „ob", sondern „wie viel" und „an welcher Stelle". Drei pragmatische Hebel:
- Open-Source-Fundament an der richtigen Schicht. Plattform/Runtime (Linux, PostgreSQL, Node.js, PHP, Redis) und das Anwendungssystem (Shopware 6, Mautic, EspoCRM, Strapi) sind die Schichten mit dem größten Lock-in-Hebel und gleichzeitig die mit reifen Open-Source-Alternativen. Die eigene Geschäftslogik ist per Definition deine.
- Daten-Souveränität als Default. Geschäftskritische Daten gehören in eine Datenbank, deren Schema du kontrollierst und exportieren kannst. Anbieter-spezifische Custom-Objekte sind ein Lock-in-Risiko, das im Frühstadium billig zu vermeiden, im Spätstadium aber teuer zu reparieren ist.
- API-Abstraktionsschichten. Wenn Drittsysteme an eine Anbieter-API gebunden sind, lohnt sich eine eigene Abstraktionsschicht (Adapter-Pattern, eigener Service-Layer), die die direkte Bindung kapselt. Die initiale Komplexität zahlt sich beim ersten Wechsel um ein Vielfaches aus.
Eine vierte Heuristik aus der Praxis: Commodity-Funktionen ruhig zukaufen, Differenzierungs-Funktionen selbst kontrollieren. Transactional Mail (über einen IP-Reputations-Anbieter), Code-Hosting oder DNS sind reine Commodity. Lock-in hier kostet wenig, weil die Migration einfach ist. Geschäftsmodell-prägende Funktionen (Shop-Logik, Pricing, Kundendatenmodell) gehören in einen Stack, dessen Kontrolle bei dir liegt.
Der KI-Effekt auf die Lock-in-Rechnung
Seit der breiten Verfügbarkeit produktionsreifer Coding-Agenten (Claude Code, Cursor, GitHub Copilot Coding Agent) verschiebt sich die ökonomische Balance zwischen proprietären und offenen Systemen. Der historisch wichtigste Vorteil proprietärer SaaS-Plattformen, dass die Wartungslast vom Anbieter übernommen wird, wird durch KI-gestützte Wartung an Open-Source-Stacks zunehmend egalisiert. Wenn ein Coding-Agent Dependency-Updates, CVE-Patches und Refactors weitgehend automatisiert abarbeitet, sinkt die laufende Wartungsrechnung eines selbstbetriebenen offenen Systems um einen Drittel bis die Hälfte. Damit wird der Preis des Lock-ins (eingeschränkte Verhandlungsposition, GMV-abhängige Lizenz, Anbieter-Pivot-Risiko) erstmals seit langem wieder klar lesbar.
Historischer Kontext: Wo der Begriff herkommt
Der Begriff Vendor Lock-in wurde Mitte der 1990er-Jahre im Kontext von Mainframe- und Enterprise-Software-Märkten geprägt und erlangte mit dem Aufstieg von Microsofts Office-Dominanz, IBMs DB2 und Oracles relationalen Datenbanken in den späten 1990ern breite Bekanntheit. Bekannt wurde der Begriff über Hal Varians und Carl Shapiros einflussreiches Buch Information Rules (1998), das Lock-in-Effekte als ökonomisch rationale Strategie sowohl für Anbieter als auch (in Grenzen) für Kunden beschrieb. Die Kernerkenntnis dieses Buchs ist bis heute relevant: Lock-in ist nicht per se Marktversagen, sondern ein erwartbares Resultat von Wechselkosten, das Anbieter strategisch nutzen und Kunden bewusst eingehen können. Im Cloud- und SaaS-Zeitalter (ab etwa 2010) hat sich der Begriff verlagert: weg von Software-Lizenzen, hin zu Daten-Hoheit und API-Bindung.
Abgrenzung zu verwandten Konzepten
Vendor Lock-in wird häufig mit zwei verwandten, aber unterschiedlichen Konzepten verwechselt.
Wechselkosten sind das ökonomische Maß, das jeder Wechsel mit sich bringt, auch zwischen zwei vollständig austauschbaren Anbietern. Lock-in entsteht, wenn diese Wechselkosten so hoch sind, dass ein wirtschaftlich rationaler Anbieterwechsel nicht stattfindet, obwohl er strategisch sinnvoll wäre.
Netzwerkeffekte beschreiben den Wertzuwachs einer Plattform durch jede zusätzliche Teilnahme (z. B. soziale Netzwerke, Marketplaces). Sie können Lock-in verstärken, sind aber konzeptionell verschieden: Ein Netzwerkeffekt belohnt das Bleiben, ein Lock-in bestraft den Wechsel.
Pfadabhängigkeit ist der breiteste der drei Begriffe und beschreibt allgemein die historische Bedingtheit gegenwärtiger Entscheidungen. Lock-in ist ein konkreter Fall von Pfadabhängigkeit, der sich auf eine spezifische Anbieterbeziehung bezieht.
Praktische Checkliste vor jedem größeren SaaS-Vertrag
Fünf Fragen, die vor jedem mehrjährigen Software-Commitment beantwortet sein sollten:
- Wie sehen die Datenexport-Funktionen aus? Nicht nur „gibt es einen Export", sondern: in welchem Format, welche Felder, welche Beziehungen, welche abgeleitete Logik wird mit-exportiert?
- Welche APIs sind offiziell stabil garantiert? Versioniert der Anbieter sauber, wie lange ist die Deprecation-Window für API-Versionen?
- Welche Lizenzmodelle skalieren mit Erfolg? GMV-, Nutzer- oder Transaktions-abhängige Modelle bedeuten, dass dein Wachstum den Anbieter belohnt, fair einkalkulieren.
- Wie groß ist der Spezialisten-Pool am Markt? Nischige Technologien bedeuten teure Expert:innen und schwierigere Agentur-Wechsel.
- Gibt es realistische Migrationspfade? Wenn keine Referenz-Migration in vergleichbarer Größe öffentlich dokumentiert ist, ist das ein Warnsignal.
Diese Fragen kosten in der Evaluierungsphase wenig und ersparen oft jahrelangen Schmerz. Wer sie nicht stellt, bezahlt sie später in der Replatforming-Rechnung.
Häufige Fragen zu Vendor Lock-in
Ist Open Source automatisch frei von Lock-in?
Nein. Auch Open-Source-Stacks erzeugen Wechselkosten. Wer fünf Jahre in einer Magento-1-Custom-Codebasis lebt, hat ähnliche Replatforming-Probleme wie ein SaaS-Kunde. Der entscheidende Unterschied ist die Verhandlungsposition: Niemand kann den Quellcode entziehen, das Datenmodell ändern oder eine Lizenz erfinden, die du nicht mehr erfüllst.
Wie viel Wechselkosten sind „normal"?
Für mittelständische E-Commerce-Replatformings liegt die übliche Größenordnung bei zwölf bis vierundzwanzig Monaten Projektlaufzeit und Engineering-Kosten im hohen sechs- bis siebenstelligen Eurobereich. Diese Zahlen sind keine fixen Marktdurchschnitte, sondern Erfahrungsmuster aus Projekten mit Custom-Logik mittlerer Tiefe.
Wann ist akzeptierter Lock-in wirtschaftlich sinnvoll?
Wenn die Plattform Funktionen liefert, deren Eigenentwicklung deutlich teurer wäre, und wenn das eigene Geschäftsmodell nicht durch GMV-skalierende Lizenzen unter Druck gerät. Standard-Beispiel: kleine Shops mit geringer Custom-Tiefe profitieren oft von Shopify; sobald der Umsatz dreistellige Tausend-Euro-Monate erreicht, kippt die Rechnung.
Welche Rolle spielt Composable Commerce?
Composable Commerce ist eine Architektur-Antwort auf Lock-in-Risiken: Statt einer monolithischen Plattform werden Best-of-Breed-Komponenten über offene APIs orchestriert. Dadurch ist jede Komponente prinzipiell ersetzbar, ohne dass das gesamte System neu aufgebaut werden muss, allerdings auf Kosten höherer Architektur-Komplexität.
Welche externen Standards reduzieren Lock-in?
Wherever offene Standards den proprietären Schnittstellen ebenbürtig sind, lohnt der Standard. Im E-Commerce-Kontext sind das vor allem REST/GraphQL-APIs, das JSON-LD-Format für strukturierte Daten und Standards wie OpenAPI für API-Dokumentation. Bei Cloud-Infrastruktur gehören Container-Standards (OCI) und Kubernetes zu den wichtigsten Lock-in-mindernden Standards.