Der Widerspruch zwischen digitalen Ambitionen und technischen Restriktionen

Immer mehr Unternehmen investieren intensiv in digitale Innovationen, KI-Initiativen und Cloud-Strategien, während sie gleichzeitig auf IT-Systemen operieren, die konzeptionell aus den 1990er Jahren stammen. Dieser Widerspruch entsteht nicht von ungefähr, sondern ist Ausdruck einer strukturellen Abhängigkeit. Alte (und bewährte) Systeme, die einst Stabilität und Effizienz brachten, sind zu digitalen Fesseln geworden. Für eine Welt der volatilen Veränderung und Agilität sind sie schlicht nicht geschaffen worden.

Je länger ein System im Einsatz ist, desto stärker verwurzelt es sich in der Organisation. Prozesse werden angepasst, Daten akkumulieren, Mitarbeiter werden geschult, und externe Systeme docken an. Was als rationale Investitionsentscheidung begann, mündet in einen strategischen Lock-in, der fundamentale Veränderungen nicht nur erschwert, sondern ökonomisch zunehmend irrational erscheinen lässt, da sie das laufende Geschäft gefährden könnten.

Der Begriff „Legacy-System“ verharmlost das Problem. Es geht nicht um veraltete Software, sondern um eine strukturelle Blockade, die Innovation verhindert, Agilität untergräbt und Unternehmen in einem Zustand permanenter technologischer Fremdbestimmung hält. Während Start-ups mit modernen, entkoppelten Architekturen in Wochen umsetzen, was etablierte Unternehmen in Jahren nicht bewältigen, vergrößert sich die Wettbewerbslücke kontinuierlich.

Lock-in als mehrdimensionales strategisches Risiko

Lock-in-Effekte manifestieren sich auf vier Ebenen, die sich gegenseitig verstärken:

• Technologisch dominieren monolithische Kernsysteme, wie ERP, CRM oder ECM, die gesamte IT-Landschaft. Um diese Zentralsysteme herum müssen sich alle anderen Anwendungen, Schnittstellen und Datenflüsse organisieren. Proprietäre Datenformate, undokumentierte Schnittstellen und herstellerspezifische Erweiterungen schaffen Abhängigkeiten, die sich über Jahre verhärten. Ein SAP-System mit hunderten kundenspezifischer Anpassungen, ein Siebel CRM mit jahrzehntelang gewachsenen Datenstrukturen oder ein IBM-Mainframe mit Millionen Zeilen COBOL-Code sind keine Werkzeuge mehr, sondern Infrastruktur, die nicht ersetzt, sondern nur umgangen werden kann.
• Ökonomisch führt die Sunk-Cost-Falle zu irrationalen Entscheidungen. Lizenzen, die für teures Geld angeschafft wurden, Jahrzehnte akkumulierter Anpassungsaufwand und die laufenden Wartungskosten erzeugen eine Investitionslogik, die Veränderung als Verlust interpretiert. Hinzu kommt die asymmetrische Verhandlungsposition. Anbieter wissen um die Wechselkosten und kalkulieren diese in ihre Preisgestaltung ein. Wartungsverträge mit 18-22% jährlicher Steigerung sind keine Ausnahme, sondern Standard in Lock-in-Situationen.
• Organisatorisch entstehen Wissensmonopole. Wenige Spezialisten beherrschen die Systeme, ihre Logiken und Eigenheiten. Diese Experten werden zu Single Points of Failure. Ihr Weggang gefährdet den Betrieb. Gleichzeitig fehlt das Know-how für Alternativen. Wer 20 Jahre SAP-Prozesse optimiert hat, kennt möglicherweise keine modernen API-first-Architekturen. Die Organisation ist kognitiv auf das bestehende System festgelegt.
• Psychologisch wirkt die „Never change a running system„-Mentalität als kultureller Stabilisator. Risikoaversion, die in kritischen Bereichen durchaus rational ist, wird zur generellen Blockadehaltung. Change-Resistenz wird durch negative Erfahrungen verstärkt. Jedes gescheiterte Migrationsprojekt bestätigt die Überzeugung, dass Systemwechsel gefährlich sind.

Diese Kombination macht Lock-in zu einem strategischen Risiko, das mit Abhängigkeiten in Lieferketten oder Energieversorgung vergleichbar ist. Allerdings bleibt technologische Abhängigkeit oft ein blinder Fleck im strategischen Risikomanagement.

Ursachen, Folgen und Auswege

Strukturelle Ursachen für Lock-in-Effekte

Die Mechanismen, die Lock-in erzeugen, sind vielfältig und wirken kumulativ:

• Proprietäre Schnittstellen stellen das fundamentalste Hindernis dar. Während offene Standards wie REST, SOAP oder GraphQL Interoperabilität ermöglichen, setzen viele Unternehmensanwendungen auf geschlossene APIs mit herstellerspezifischer Dokumentation. SAP’s BAPI, Oracle’s Forms-Architektur oder Microsoft Dynamics‘ proprietäre Plug-in-Strukturen schaffen technische Abhängigkeiten, die nur mit erheblichem Reverse-Engineering-Aufwand zu überwinden sind. Noch schlimmer wird es, wenn gar keine Schnittstellen / APIs vorgesehen sind.
• Fehlende Datenportabilität verschärft das Problem. Daten sind nicht neutral gespeichert, sondern in systemspezifischen Strukturen organisiert. Ein CRM-System speichert Kundenbeziehungen nicht als standardisierte Entitäten, sondern in einem relationalen Modell, das eng mit der Geschäftslogik der Anwendung verwoben ist. Migration bedeutet nicht nur Datentransfer, sondern semantische Transformation. Dies ist ein Prozess, der fehleranfällig und aufwendig ist und viel Know-how erfordert.
• Monolithische Architekturen verhindern die schrittweise Modernisierung. Alles-oder-nichts-Systeme erlauben keine Ablösung einzelner Komponenten. Ein ERP-System kann nicht modulweise ersetzt werden. Es ist ein integrierter Block, bei dem Änderungen an einer Stelle Auswirkungen auf alle anderen haben.
• Komplexe Lizenzmodelle erzeugen ökonomische Abhängigkeiten. Named User, Concurrent User, Core-basierte Lizenzierung, Maintenance-Zwang bei Upgrades … Die Preisgestaltung ist bewusst intransparent und schafft Wechselbarrieren. Audit-Praktiken mancher Anbieter, die regelmäßig zu Nachforderungen führen, sind strategische Instrumente zur Kundenbindung. Andere Anbieter sichern ihre Position durch Verträge, die eine Nutzung von Daten durch Drittsysteme erschweren oder finanziell bestrafen.
• Know-how-Abhängigkeit schließlich manifestiert sich in zertifizierungspflichtigen Spezialisierungen. Ein SAP-Berater mit ABAP-Kenntnissen ist nicht automatisch ein Experte für moderne Microservices. Die Investition in systemspezifisches Wissen wird zur persönlichen Pfadabhängigkeit, die organisatorische Veränderungen erschwert.

Um den Lock-in aufzubrechen, bedarf es einer präzisen Analyse seiner Ursachen und der Kaskadeneffekte, die er auslöst.

Betriebswirtschaftliche Folgen

Die ökonomischen Konsequenzen von Lock-in-Effekten sind erheblich, werden häufig unterschätzt und gehen weit über reine Lizenzgebühren hinaus:

• Steigende Betriebskosten folgen einer exponentiellen Kurve. Legacy-Systeme benötigen spezialisierte Wartung, deren Stundensätze steigen, während die Verfügbarkeit qualifizierter Fachkräfte sinkt. Mainframe-Spezialisten mit COBOL-Kenntnissen erreichen wegen Knappheit Tagessätze jenseits von 2.000 Euro. Gleichzeitig steigen Lizenz- und Wartungskosten kontinuierlich.
• Innovationsverzögerungen haben direkte Umsatzeffekte. Handelsunternehmen, die sechs Monate und länger benötigen, um einen neuen Vertriebskanal zu integrieren, verlieren Marktanteile an agilere Wettbewerber. Durch technische Hypotheken entstehen gravierende Innovationsverluste, da IT-Budgets für Wartung statt für Weiterentwicklung aufgewendet werden.
• Verlust technologischer Souveränität bedeutet strategische Verwundbarkeit. Unternehmen werden zu Preisnehmern ohne Verhandlungsmacht. Oracle’s Cloud-Zwangsmigrationsstrategien, SAP’s Umstellung auf Subscription-Modelle oder Microsoft’s License-Compliance-Programme demonstrieren, wie Anbieter ihre Marktmacht nutzen. Die Abhängigkeit wird zur Einnahmequelle.
• Opportunitätskosten übersteigen typischerweise die direkten Kosten erheblich.
• Die Attraktivität als Arbeitgeber leidet, da Top-Mitarbeitende im Tech-Bereich mit modernen Stacks (Cloud, Microservices, KI-Frameworks) und nicht mit veralteten ERP-Masken arbeiten möchten.

Organisatorische und psychologische Aspekte

Die kulturellen Dimensionen von Lock-in sind wirkmächtig:

Change-Resistenz entsteht aus rationaler Vorsicht. IT-Projekte haben hohe Misserfolgsquoten. Diese Erfahrung prägt das organisatorische Lernen. Wer mehrere gescheiterte Migrationen erlebt hat, entwickelt Skepsis gegenüber Veränderungsprojekten.

Risikoaversion wird durch Anreizsysteme verstärkt. CIOs werden für Stabilität belohnt. Innovation ist da eher seltener im Fokus. Während ein funktionierendes Legacy-System keine Anerkennung garantiert, sorgt ein ausgefallenes System für Kritik. Diese Asymmetrie führt zu konservativen Entscheidungen, die kurzfristig rational, langfristig aber destruktiv sind.

Wissensmonopole schaffen informelle Machtstrukturen. Mitarbeiter, die als einzige ein System verstehen, genießen Arbeitsplatzsicherheit und Einfluss. Sie haben wenig Anreiz, ihr Wissen zu dokumentieren oder Alternativen zu unterstützen. Diese Dynamik blockiert die Modernisierung von innen.

Kompetenzvakuum bei Alternativen verschärft die Situation. Fachbereiche kennen nur die Logik ihrer aktuellen Systeme und können Anforderungen nicht systemunabhängig formulieren. IT-Abteilungen fehlt häufig die Erfahrung mit modernen Architekturen. Externe Berater haben Eigeninteressen, die nicht zwingend mit der organisatorischen Souveränität des Kundenunternehmens übereinstimmen.

Lock-in und die Innovations-Warteschleife

Die Beziehung zwischen Lock-in und Innovationen ist nicht linear, sondern selbstverstärkend:

Unternehmen in Lock-in-Situationen verschieben Innovationsprojekte mit der Begründung, zunächst die technische Basis modernisieren zu müssen. Gleichzeitig wird die Modernisierung verschoben, weil die Ressourcen für den laufenden Betrieb und die Wartung gebunden sind. Dieser Teufelskreis führt zu einem organisatorischen Wartemodus, bei dem man auf den richtigen Zeitpunkt, die bessere Technologie oder den günstigeren Anbieter wartet. Der Markt entwickelt sich in dieser Zeit aber weiter.

Die psychologische Wirkung ist destruktiv. Teams internalisieren die Einschränkungen ihrer Systeme und zensieren sich selbst. In Kenntnis dessen, was das eigene System kann oder viel mehr nicht kann, werden Ideen erst gar nicht mehr artikuliert. Innovation wird dabei nicht aktiv verhindert, sondern ist strukturell unmöglich.

Besonders problematisch ist der Effekt auf digitalaffine Mitarbeitende. High-Performer verlassen Organisationen, die mit veralteten Technologien arbeiten. Der Fachkräftemangel verschärft sich nicht trotz, sondern wegen der Legacy-Systeme. Der resultierende Brain Drain verstärkt die technologische Rückständigkeit weiter.

Moderne Technologien als Entkopplungsinstrumente

Die technologische Entwicklung der letzten Jahre bietet Lösungsansätze, die Lock-in nicht durch Revolution, sondern durch graduelle Entkopplung überwinden:

API-basierte Integration schafft Abstraktionsschichten zwischen Systemen. Enterprise Service Bus (ESB), API Gateways und Integration Platform as a Service (iPaaS) ermöglichen es, Legacy-Systeme hinter standardisierten Schnittstellen zu verbergen. Moderne Ansätze erlauben es, Datenflüsse unabhängig vom Ursprungssystem zu orchestrieren. Das Legacy-System bleibt operational, verliert aber seine dominierende Stellung.

Data Fabric und Data Mesh Konzepte lösen die Datenproblematik. Statt Daten physisch zu migrieren, werden sie virtualisiert und über semantische Modelle zugänglich gemacht. Entsprechende Tools schaffen eine Datenabstraktionsschicht, die unabhängig von der physischen Speicherung operiert. Daten können so aus Legacy-Systemen gelesen, in modernen Formaten bereitgestellt und für KI-Anwendungen nutzbar gemacht, ohne dass das Ursprungssystem verändert werden müsste.

Low-Code-Orchestrierung demokratisiert die Systemintegration. Low-Code-Plattformen ermöglichen es Fachabteilungen unabhängig von knappen IT-Ressourcen, Workflows zu erstellen, die Legacy-Systeme einbinden, ohne deren Innenleben zu verstehen. Die Abhängigkeit von spezialisierten Entwicklern sinkt, während die Geschwindigkeit der Umsetzung steigt.

KI-gestützte Migration reduziert das technische Risiko grundlegend. Machine-Learning-basierte Tools analysieren Legacy-Code, identifizieren Abhängigkeiten und generieren Migrationspfade automatisiert. Speziallösungen können z.B. COBOL in Java transformieren, undokumentierte APIs rekonstruieren oder Datenmigrationsskripte generieren. Was früher manuelle Sisyphusarbeit war, wird zunehmend automatisierbar.

Systematische Entkopplung statt Revolution

Technische Entkopplung

Der erste Schritt aus dem Lock-in ist die Schaffung einer Integrationsarchitektur, die als Puffer zwischen Legacy und Zukunft fungiert:

Die Implementierung eines API-Gateway-Layers standardisiert den Zugriff auf Legacy-Systeme. Alle externen Zugriffe erfolgen über dokumentierte REST- oder GraphQL-APIs, die intern beliebige Protokolle nutzen können. Dies entkoppelt Konsumenten vom Ursprungssystem und schafft Migrationsfähigkeit.

Semantic Layer übersetzen zwischen verschiedenen Datenmodellen. Ein Customer Data Platform (CDP) kann Kundendaten aus CRM, ERP und E-Commerce harmonisieren und als einheitliche Customer-360-View bereitstellen. Dabei ist es unerheblich, wo die Daten physisch liegen.

Architektonische Repositionierung

Die mittelfristige Transformation erfordert eine architektonische Neuausrichtung:

Domain-Driven Design strukturiert die Organisation nach Geschäftsprozessen statt nach technischen Systemen. Bounded Contexts definieren klare Grenzen zwischen Bereichen wie Order Management, Customer Service oder Billing. Jeder Context kann technologisch unabhängig entwickelt werden. Das Legacy-System wird zu einem Context unter vielen.

Microservices-Migration erfolgt selektiv und risikobasiert. Nicht alle Funktionen müssen ausgelagert werden. Beginnen Sie mit Bereichen, die hohe Innovationsgeschwindigkeit benötigen oder frequente Änderungen erfordern. Ein Product Catalog Service kann aus dem ERP extrahiert werden, um schnelle Produkteinführungen zu ermöglichen. Das Kernbuchhaltungssystem kann vorerst bleiben.

CQRS-Pattern (Command Query Responsibility Segregation) trennt Lese- und Schreiboperationen. Legacy-Systeme bleiben System of Record für Transaktionen, während moderne Read-Modelle für Analytik, Reporting und KI-Anwendungen optimiert werden. Dies reduziert Last auf Legacy-Systemen und ermöglicht Innovationen im Lese-Pfad.

Quantifizierung der Stillstandskosten

Die betriebswirtschaftliche Rechtfertigung für die Modernisierung erfordert erweiterte Kalkulationsmodelle:

Eine Opportunitätskostenberechnung muss obligatorisch werden. Es muss Klarheit darüber herrschen, was es z.B. kostet, eine neue Geschäftsidee nicht umzusetzen, weil das System dies nicht unterstützt? Es muss Bewusstsein darüber entwickelt werden, welcher Umsatz entgeht, weil Markteinführungszeiten zu lang sind? Diese Kosten erscheinen nicht in der GuV, sind aber real und müssen berücksichtigt werden, um von einem Ausgaben- zu einem Investitions-Denken zu kommen.

Die Risikoquantifizierung macht versteckte Kosten verständlich. Dabei geht es z.B. um die Frage, was der monetäre Wert des Business-Continuity-Risikos ist, wenn nur noch ein oder zwei Mitarbeiter ein System verstehen. Dabei können versicherungsmathematische Methoden Klarheit schaffen.

Value Stream Mapping identifiziert, wo Modernisierung den höchsten Business Value liefert. Nicht alle Systeme sind gleich wichtig. Fokussieren Sie auf kritische Pfade, die direkt kundenwertschöpfend sind oder Compliance-Risiken bergen.

Risikoreduzierte Modernisierung durch KI

Moderne Tools reduzieren Migrationsrisiken erheblich:

• KI-gestützte Code-Analyse dokumentiert automatisiert, was über Jahre undokumentiert blieb. Tools scannen Code, identifizieren Abhängigkeiten, rekonstruieren Datenflüsse und generieren Architekturdiagramme. Fertige Tools für diese Zwecke liefern Transparenz als Grundlage für Entscheidungen.
• Shadow Mode Deployment erlaubt ein risikofreies Testen. Neue Systeme laufen eine Zeit lang parallel zu alten und erhalten dieselben Inputs. Die Ergebnisse werden verglichen, aber nicht produktiv verwendet. Diskrepanzen werden analysiert, bis die Ergebnisse übereinstimmen. Erst dann erfolgt der Schwenk.
• Feature Flags ermöglichen graduelle Rollouts. Neue Funktionalität kann zunächst für einen kleinen Teil der User aktiviert und dann schrittweise erweitert werden. Bei Problemen erfolgt ein sofortiges Rollback.

Die Angst vor der Migration muss durch Technologie gemindert werden. Dies wandelt ein unkalkulierbares Risiko in einen planbaren Übergang um.

Strategische Governance

Nachhaltige Entkopplung erfordert eine organisatorische Verankerung und eine Strategie, die sich ausschließlich an den langfristigen Unternehmenszielen orientiert:

Das Architecture Board etabliert dabei Entscheidungsstrukturen. Ein interdisziplinäres Gremium aus IT, Fachbereichen und Management definiert Architekturprinzipien, bewertet Technologieentscheidungen und verhindert neue Lock-ins. Dabei ist wichtig, dass dieses Gremium Entscheidungskompetenz nicht nur eine beratende Funktion hat.

Architecture Decision Records dokumentieren das Warum und die Entstehung von Entscheidungen. ADRs halten fest, welche Alternativen betrachtet wurden, welche Kriterien relevant waren und warum eine bestimmte Lösung gewählt wurde. Dies verhindert, dass zukünftige Generationen dieselben Fehler wiederholen, weil der Kontext vergessen wurde. Gleichzeitig kann man sich vom Gedanken „es wurde noch niemand gefeuert, weil er IBM eingekauft hat“ lösen.

Eine Skills Development Pipeline baut systematisch Kompetenzen auf. Wenn das Ziel „Digitalisierung“ lautet, müssen Mitarbeiter entsprechend weitergebildet werden. Entsprechende Qualifizierungsmaßnahmen schaffen Know-how für Alternativen.

Souveränität ist auch eine Frage der Architektur

Digitale Zukunftsfähigkeit ist untrennbar mit architektonischer Beweglichkeit verbunden. Lock-in-Effekte sind keine technischen Altlasten, sondern strategische Fesseln.

Moderne Technologien, methodische Ansätze und veränderte ökonomische Rahmenbedingungen machen eine Entkopplung aber realisierbar. API-basierte Integration, Data Fabric, KI-gestützte Migration und modulare Architekturen sind keine futuristischen Konzepte mehr, sondern erprobte Praktiken mit nachweisbarem ROI.

Lock-in überwindet man nicht durch bessere Software, sondern durch veränderte Governance, klare Priorisierung und den Mut, kurzfristige Stabilität für langfristige Souveränität einzutauschen.

Unternehmen, die diese Transformation aktiv gestalten, rekultivieren ihre strategische Handlungsfähigkeit, reduzieren strukturelle Risiken und schaffen Räume für Innovationen, die in verkrusteten Systemlandschaften nicht existieren können.

Die Frage ist nicht, ob Unternehmen ihre Lock-ins lösen müssen. Die Frage ist, ob sie es rechtzeitig tun, bevor die Opportunitätskosten des Wartens die Investitionskosten der Veränderung bei weitem übersteigen.