Cloud ist nicht gleich Cloud: Wie die Abstraktionsebene über den Aufwand des Exits entscheidet

Infrastruktur: Technisch austauschbar – organisatorisch beherrschbar

Infrastructure as a Service beschränkt sich im Kern auf die Bereitstellung technischer Ressourcen wie Rechenleistung, Speicher und Netzwerkinfrastruktur. Die Verantwortung für Applikationen, Datenstrukturen und Geschäftslogiken verbleibt weitgehend beim Unternehmen.

Diese Trennung ist für den Exit entscheidend. Beim Anbieterwechsel müssen zwar Systeme migriert und Betriebsumgebungen neu aufgebaut werden, die grundlegende Struktur der Applikationen bleibt jedoch erhalten. Daten behalten ihre Bedeutung, weil sie nicht durch plattformspezifische Funktionen oder Anwendungskontexte geprägt sind, sondern durch unternehmenseigene Modelle und Prozesse.

Der Wechsel ist damit primär eine technische und organisatorische Aufgabe. Er erfordert Planung, Koordination und Ressourcen, verändert jedoch nicht die Art und Weise, wie das Unternehmen arbeitet. Die Abhängigkeit vom Anbieter betrifft nur den Betrieb, nicht die Logik des Geschäfts. Sie ist daher vergleichsweise gering.

👉 Infrastruktur ermöglicht Skalierung und Flexibilität, ohne die Architektur oder die Prozesse des Unternehmens tiefgreifend zu prägen. Der Exit ist aufwendig, aber strukturell beherrschbar, weil das Unternehmen die Kontrolle über Applikationen und Datenmodelle behält.

Plattform: Wenn technische Entscheidungen strategische Wirkung entfalten

Platform as a Service verschiebt die Verantwortung weiter vom Unternehmen zum Anbieter. Neben der reinen Infrastruktur werden zentrale technische Bausteine genutzt, etwa Datenbankdienste, Laufzeitumgebungen oder Integrationskomponenten. Diese Dienste geben nicht nur technische Möglichkeiten vor, sondern definieren den Rahmen, in dem Softwareanwendungen entwickelt und betrieben werden.

Applikationen werden dadurch nicht „proprietär“ gestaltet. Vielmehr orientieren sich Architektur- und Designentscheidungen an den Funktionen und Standards der jeweiligen Plattform. Datenmodelle, Schnittstellen und Verarbeitungslogiken entstehen innerhalb dieses Rahmens, weil er Effizienz, Skalierbarkeit und Betriebssicherheit verspricht.

Dieses Setting hat Konsequenzen für den Exit. Zwar lassen sich Applikationen grundsätzlich portieren. Funktionen, die innerhalb der Plattform selbstverständlich verfügbar sind – etwa bestimmte Datenbankmechanismen, Event- oder Messaging-Strukturen oder integrierte Sicherheits- und Identitätsdienste – müssen jedoch bei einem Wechsel entweder nachgebildet oder neu konzipiert werden.

Der Wechsel betrifft damit nicht nur den Betrieb, sondern die Struktur der Apps selbst. Was technisch als Plattformwechsel erscheint, wird organisatorisch zu einem Architekturprojekt. Der Aufwand liegt weniger im Transfer von Daten oder Code als in der Wiederherstellung der Funktionslogik unter anderen technischen Voraussetzungen.

👉 Für Unternehmen bedeutet das: Entscheidungen, die auf Plattformebene getroffen werden, wirken strategisch, auch wenn sie operativ motiviert sind. Die Wahl einer Plattform bestimmt nicht nur Effizienz und Geschwindigkeit der Entwicklung, sondern auch die Komplexität eines späteren Wechsels.

Software: Wenn Anwendungen die Organisation strukturieren

Software as a Service unterscheidet sich grundlegend von Infrastruktur- und Plattformdiensten. Das Unternehmen nutzt hier nicht lediglich technische Ressourcen oder Entwicklungsumgebungen, sondern Softwareanwendungen, in denen Geschäftsprozesse, Entscheidungslogiken und Datenstrukturen unmittelbar und zunächst standardisiert abgebildet sind.

Unternehmensdaten werden dabei nicht isoliert gespeichert. Sie sind Teil eines funktionalen Gesamtzusammenhangs. Ihre Bedeutung ergibt sich aus der Art, wie die App sie verarbeitet, miteinander verknüpft und in Prozesse einbettet.

Mit der Zeit werden die Standards konfiguriert, erweitert und an individuelle Abläufe angepasst. Die Software übernimmt zunehmend Funktionen, die zuvor organisatorisch geregelt waren. Die Grenze zwischen IT-System und Organisation wird unscharf. Mit der Zeit bilden Workflows, Berechtigungen, Automatisierungen und Auswertungen die gesamte konkrete Arbeitsweise des Unternehmens ab.

Beim Exit zeigt sich die Konsequenz. Zwar lassen sich Daten regelmäßig exportieren, ihre wirtschaftliche Nutzbarkeit hängt jedoch davon ab, ob ihre Bedeutung außerhalb der Anwendung rekonstruierbar ist. Prozesse, die bislang implizit im System abgebildet waren, müssen nun – weil die gesonderte Dokumentation im Unternehmen selbst regelmäßig fehlt – explizit beschrieben werden. Entscheidungen, die die Software bislang automatisiert getroffen hat, müssen neu verortet werden.

Der Wechsel einer SaaS-Lösung ist daher kein reines Migrationsprojekt. Er betrifft Abläufe, Verantwortlichkeiten und Steuerungsmechanismen. Der Aufwand liegt weniger im technischen Transfer als in der Entflechtung einer über Jahre gewachsenen Struktur, in der Software und Organisation eng miteinander verwoben sind.

👉 Für Unternehmen bedeutet das: SaaS schafft nicht nur Effizienz, sondern strukturiert das Unternehmen mit. Diese Bindungswirkung ist kein Fehlverhalten, sondern die logische Folge intensiver Nutzung. Sie lässt sich nicht vollständig vermeiden – aber sie muss verstanden und gesteuert werden, wenn ein späterer Wechsel realistisch möglich bleiben soll.

Fazit

Cloud ist nicht gleich Cloud. Der Aufwand und das Risiko eines Anbieterwechsels hängen maßgeblich davon ab, auf welcher Ebene Cloud-Leistungen genutzt werden. Während Infrastruktur vor allem den Betrieb betrifft, prägen Plattformen die Architektur und SaaS-Anwendungen zunehmend die Organisation selbst. Mit jeder Abstraktionsebene verändert sich damit auch die Intensität der Abhängigkeit.

Warum diese Abhängigkeiten häufig erst beim Exit sichtbar werden, habe ich im ersten Beitrag dieser Reihe näher erläutert. Der vorliegende Beitrag zeigt, wodurch sie sich bei den jeweiligen Ebenen konkret unterscheiden und warum sie sich nicht allein durch vertragliche Regelungen beherrschen lassen.

Die hier dargestellten Zusammenhänge basieren auf meiner vertieften Auseinandersetzung mit Cloud-Wechseln und Exit-Szenarien im Rahmen meines Beitrags zum

👉 Fachbuch „Compliance-Handbuch EU Data Act“ – ISBN 978-3-452-30432-2

Die Analyse verbindet rechtliche Vorgaben mit der technischen und organisatorischen Realität von Unternehmen – genau an dieser Schnittstelle entstehen in der Praxis die entscheidenden Risiken.

Dies ist der zweite Beitrag einer Reihe –

👉 Link zu Beitrag 1: „Cloud-Wechsel: Warum gute Verträge allein nicht vor Abhängigkeit schützen“
https://trenchant-legal.de/cloud-wechsel-warum-gute-vertraege-allein-nicht-vor-abhaengigkeit-schuetzen/
Hier gehe ich noch näher auf die Aspekte zum Wechsel von SaaS-Anbietern ein.

👉 Beitrag 3: Cloud-Wechsel: Offene Schnittstellen, Metadaten, Informationen – Neue Pflichten der Anbieter nach Data Act
https://trenchant-legal.de/cloud-wechsel-offene-schnittstellen-metadaten-informationen/