Cloud Exit: Wann sich die Rückkehr auf eigene Server mehr lohnt als die Public Cloud

Die entscheidende Frage lautet deshalb nicht, welche Seite in jeder Zeile gewinnt. Entscheidend ist, welche Zeilen für den konkreten Workload den größten Anteil an den Gesamtkosten haben. Viele Teams diskutieren zu lange über Serverpreise und zu kurz über Datenverkehr, Datenbankbetrieb und Personalbindung.

Versteckte Kosten und Risiken, die Business Cases gern ausblenden

Ein sauberer Exit-Case muss mehr enthalten als Infrastruktur und Migration. Drei Kostenblöcke werden regelmäßig unterschätzt: Parallelbetrieb, Resilienz und Betriebswissen. Parallelbetrieb ist teuer, weil Daten synchron gehalten, Deployments doppelt abgesichert und Rollback-Pfade offen bleiben müssen. Resilienz kostet, weil Redundanz im Eigenbetrieb nicht mit einem Häkchen im Portal entsteht. Betriebswissen kostet, weil Know-how nicht sofort verfügbar ist, nur weil Hardware bestellt wurde.

Hinzu kommt ein Risiko, das in Excel kaum sichtbar wird: organisatorische Fragmentierung. Wenn Plattformteam, Security, Netzwerk und Applikationsteam unterschiedliche Zielbilder haben, wird der Exit langsamer und teurer. Dann entstehen Wartezeiten, Sonderlösungen und politische Kompromisse, die später als technische Schulden zurückkommen.

Auch Compliance kann die Rechnung drehen. Nicht jede Umgebung braucht formale Nachweise auf hohem Niveau. Wenn aber Auditierbarkeit, Protokollierung, Schlüsselmanagement oder Datenlokation im Eigenbetrieb neu aufgebaut werden müssen, steigt der Aufwand spürbar. Standards sind nur dann relevant, wenn sie Architektur und Betrieb tatsächlich verändern. Genau dann gehören sie früh in die Kalkulation.

Klare Warnung: Wer Backup, Wiederherstellung und Desaster-Recovery erst nach der Migrationsentscheidung konkretisiert, hat den Business Case noch nicht verstanden.

Welche Workloads zuerst raus sollten und welche besser bleiben

Wenn ein Exit sinnvoll ist, dann selten flächendeckend. Die erste Welle sollte wirtschaftlich relevant, technisch überschaubar und betrieblich beherrschbar sein. Wer mit einem politisch sichtbaren, aber komplexen System startet, verbrennt Vertrauen und Zeit.

Zuerst prüfen würde ich Workloads mit drei Eigenschaften: hohe und konstante Grundlast, spürbarer Datentransfer, geringe Plattformbindung. Dazu gehören oft interne Datenplattformen, Batch-Verarbeitung, dauerlaufende Backend-Dienste oder APIs mit viel externer Ausleitung. Solche Systeme nutzen die Elastizität der Public Cloud oft weniger, als sie dafür bezahlen.

In der Public Cloud lassen würde ich Systeme mit unvorhersehbaren Peaks, globaler Reichweite, kurzen Produktzyklen oder tiefer Bindung an Plattformdienste. Dort ist der Preisaufschlag häufig der Gegenwert für Geschwindigkeit, Reichweite oder geringeren Betriebsaufwand. Das ist nicht billig, aber oft vernünftig.

Die Reihenfolge für die Auswahl ist simpel und hart:

1. Struktureller Kostendruck vor bloß hoher Rechnung
2. Geringe Plattformbindung vor architektonischer Eleganz
3. Beherrschbares Migrationsfenster vor theoretischem Einsparpotenzial
4. Überschaubares Geschäftsrisiko vor symbolischer Wirkung

Wenn ein Workload bei Punkt zwei oder drei schwach aussieht, nicht migrieren. Dann ist eher eine sauberere Zielarchitektur oder eine Private-Cloud-Betriebsstrategie als mittelfristiges Zielbild sinnvoll. Nicht als Schnellschuss.

Ein konkreteres Muster aus dem Mittelstand: Ein Unternehmen wollte wegen stark gestiegener Cloud-Kosten mehrere Systeme zurückholen. Nach der Bewertung blieben das kundennahe Frontend, das Identitätssystem und ein Event-Stack in der Public Cloud. Migriert wurden nur Batch-Verarbeitung, interne APIs und ein datenintensiver Reporting-Teil.

Danach gab es keinen spektakulären Bruch, sondern eine saubere Verschiebung der Kostenstruktur: Die laufenden Plattformkosten sanken, der Datenausgang verlor an Gewicht und das Team musste nur für einen begrenzten Teil des Stacks zusätzlichen Betriebsaufwand übernehmen. Der Kompromiss blieb sichtbar, weil Identität, Frontend und ereignisgetriebene Komponenten weiter in der Cloud liefen und damit zwei Betriebswelten koordiniert werden mussten. Intern galt der Teil-Exit trotzdem als Erfolg, weil die Einsparung nicht an einem riskanten Vollausstieg hing und die Migration ohne produktnahe Architekturänderung auskam.

Umsetzungslogik und Mindestanforderungen für den Zielbetrieb

Ein belastbarer Exit beginnt nicht mit Beschaffung, sondern mit einer Abhängigkeitskarte. Welche Datenflüsse verlassen die Plattform, welche Dienste sind proprietär, welche Betriebsfunktionen sind heute implizit im Cloud-Angebot enthalten? Erst wenn diese Karte sauber ist, lässt sich die Zielumgebung realistisch planen.

Danach trägt in der Praxis eine klare Reihenfolge:

1. Workload segmentieren: trennen zwischen portablen Kernkomponenten und cloudnahen Resten.
2. Zielbetrieb definieren: Monitoring, Backup, Patching, IAM, Netzwerk, Logging und Bereitschaftsdienst vor der Migration festlegen.
3. Pilot migrieren: einen wirtschaftlich relevanten, aber technisch überschaubaren Workload zuerst verlagern.
4. Parallelbetrieb begrenzen: klare Fristen setzen, damit Doppelstrukturen nicht zur Dauerlösung werden.
5. Nachkalkulieren: nach 3, 6 und 12 Monaten prüfen, ob TCO und Betriebsqualität die Annahmen bestätigen.

Gerade Schritt vier wird oft weich formuliert. Das ist ein Fehler. Ohne harte Fristen bleibt der Parallelbetrieb länger bestehen, als irgendjemand geplant hat. Dann frisst er den erwarteten Vorteil auf.

Wer auf eigene Server zurückgeht, braucht keinen Luxus, aber ein belastbares Fundament. Dazu gehören standardisierte Provisionierung, reproduzierbare Konfiguration, zentrales Logging, Metriken, Alarmierung, getestete Backups und dokumentierte Wiederherstellung. Wenn diese Elemente erst nach dem Umzug entstehen sollen, ist die Reihenfolge falsch.

Besonders kritisch ist die Datenebene. Datenbanken, Objektablagen und Replikation sind selten der Teil, den man nebenbei ersetzt. Sobald Datenkonsistenz, Wiederherstellungszeiten oder Verschlüsselung unklar bleiben, sollte der Exit gestoppt oder enger zugeschnitten werden. Viele Projekte scheitern nicht an Compute, sondern an Datenhaltung und Betriebsmodell.

Die eigentliche Warnung lautet deshalb anders, als sie in Budgetrunden oft verkauft wird: Cloud Exit ist kein Sparprogramm, sondern eine Betriebswette. Sobald der Rückzug intern nur als Kostenhebel erzählt wird, werden Risiken systematisch kleingerechnet. Security erwartet mehr Kontrollen, das Plattformteam mehr Automatisierung, der Fachbereich keine Unterbrechung und Finance sofort sinkende Kosten. Diese Gleichung geht selten auf.

Meine klare Position: Wenn der Business Case nur unter Idealbedingungen trägt, sollte er gestoppt werden. Ein robuster Exit überlebt konservative Annahmen zu Migration, Personal, Redundanz und Parallelbetrieb. Tut er das nicht, ist die Public Cloud trotz hoher Rechnung oft die billigere Fehlentscheidung.

Die streitbare Marktbeobachtung dazu: Wer heute reflexhaft einen vollständigen Cloud Exit fordert, hat in vielen Fällen nicht zu viel Cloud eingekauft, sondern zu wenig Betriebsdisziplin aufgebaut.

Noch deutlicher: Viele Unternehmen sollten nicht aus der Cloud aussteigen, sondern zuerst aufhören, sie wie ein unkontrolliertes Rechenzentrum mit Premium-Aufschlag zu betreiben. Das ist unpopulär, aber meistens näher an der Realität als die Erzählung vom überteuerten Cloud-Modell.

Vertretbar ist ein Exit dann, wenn die Kriterien zusammenpassen: konservativ positiver 36-Monats-TCO, geringe Plattformbindung, klar definierter Zielbetrieb, begrenzter Parallelbetrieb und ein Workload, dessen Geschäftsrisiko während der Migration beherrschbar bleibt. Fehlt einer dieser Punkte, sollte die Entscheidung nicht heroisch klingen, sondern schlicht vertagt oder auf einen kleineren Teil-Exit begrenzt werden.