Cloud Exit lohnt sich vor allem bei stabiler Dauerlast, hohem Egress, geringer Plattformbindung und belastbarer Betriebsreife. Entscheidend sind Portabilität, ein konservativer 36-Monats-TCO und die Frage, ob ein selektiver Rückzug auf eigene Server wirtschaftlich sinnvoller ist als der Verbleib in der Public Cloud.
Ein Cloud Exit ist dann vernünftig, wenn ein Workload berechenbar, teuer und portabel geworden ist. Gemeint sind stabile Last, spürbare Egress-Kosten, wenig Bindung an proprietäre Plattformdienste und ein Team, das Betrieb nicht verklärt. Wer nur auf eine hohe Cloud-Rechnung reagiert, entscheidet oft zu früh. Dann wird aus einer Kostenkorrektur ein Umbau, der intern mehr Reibung erzeugt als Einsparung.
Die unbequeme These: Viele Unternehmen haben kein Cloud-Problem, sondern ein Disziplinproblem. Rightsizing, Reservierungen, Speicherbereinigung und eine härtere Auswahl verwalteter Dienste wirken oft schneller als der Rückzug auf eigene Server. Ein Exit ist keine elegante Abkürzung für schwaches FinOps.
Die erste Frage ist nicht, ob Server billiger sind. Entscheidend ist, ob der Workload portabel ist. Portabel heißt hier: Er lässt sich ohne funktionalen Neubau in eine eigene Umgebung verlagern. Sobald Datenbank, Messaging, Identität oder Sicherheitslogik tief an proprietäre Dienste gebunden sind, wird aus einem Exit ein Replatforming-Projekt. Dann kippt die Rechnung schnell.
Genau an dieser Stelle werden Business Cases gern schöngerechnet. Eine hohe Cloud-Rechnung allein taugt nicht als Vergleich, wenn auf der Gegenseite nur Hardware, Rack und ein grober Colocation-Preis stehen. Im Eigenbetrieb kommen Lizenzen, Backup- und Monitoring-Werkzeuge, Betriebsaufwand, Bereitschaft, Patching und fast immer ein Migrationsfenster mit Parallelbetrieb dazu. Wer das ausblendet, vergleicht keine zwei Betriebsmodelle, sondern eine fertige Plattform mit einer halben Einkaufsliste.
Ein realistischer Kandidat für Cloud Exit sieht meist unspektakulär aus: dauerlaufende Backend-Systeme, interne APIs, datenintensive Verarbeitung, Batch-Jobs oder Plattformen mit hohem Datenaustausch. Gerade diese langweiligen Workloads sind oft die besten Kandidaten. Das ist kein Makel, sondern ein Signal für geringe Migrationskomplexität.
Schlechte Kandidaten erkennt man ebenfalls schnell: stark schwankende Last, globale Frontends mit unvorhersehbaren Peaks, produktnahe Experimente oder Systeme, deren Wert gerade aus cloudnahen Diensten entsteht. Dort ist die Cloud nicht nur Infrastruktur. Sie ist Teil des Produkts.
Wenn die Diskussion intern schon ideologisch geführt wird, ist Vorsicht angebracht. „Alles zurück“ ist meist genauso unklug wie „alles in die Cloud“. Wirtschaftlich sinnvoll ist fast immer die selektive Entscheidung pro Workload.
Vor einer Entscheidung sollten vier Bedingungen nüchtern geprüft werden: technische Austauschbarkeit der Kernkomponenten, struktureller statt nur temporärer Kostendruck, ein klar definierter Zielbetrieb mit Eigentümern und Runbooks sowie ein Migrationspfad, den das Geschäft tatsächlich toleriert. Fehlt nur eine dieser Bedingungen, wird aus einer Kostenmaßnahme schnell ein Umbau mit offenem Ende.
Statt mehrere Prüfstrecken nebeneinander aufzubauen, reicht eine kompakte Matrix mit drei Feldern. Fällt eines davon klar negativ aus, sollte der Workload in der Public Cloud bleiben oder dort zuerst optimiert werden.
| Prüffeld | Go-Signal | Stoppsignal |
| Portabilität | Standardkomponenten reichen, keine Produktänderung nötig | Wesentliche Plattformdienste müssten funktional ersetzt werden |
| Wirtschaftlichkeit | Dauerlast, Egress oder verwaltete Dienste treiben die Kosten strukturell | Der Vorteil entsteht nur unter optimistischen Annahmen |
| Betriebsreife | Monitoring, Backup, Patching, Runbooks und Verantwortlichkeiten sind etabliert | Der Zielbetrieb hängt an manuellen Routinen oder Einzelpersonen |
Diese Matrix ist absichtlich streng. Ein Cloud Exit scheitert selten an der Beschaffung von Hardware. Er scheitert daran, dass aus einer Kostenmaßnahme still ein Betriebs- und Architekturprogramm wird. Dann steigen Aufwand, Risiko und politische Reibung gleichzeitig.
Ein Punkt wird in Managementrunden gern verdrängt: Teilweiser Exit schlägt Vollausstieg in vielen Fällen deutlich. Datenintensive oder berechenbare Lasten können auf eigener Infrastruktur wirtschaftlich sein, während Frontends, Integrationen oder cloudnahe Dienste in der Public Cloud bleiben. Wer alles zurückholen will, folgt oft eher einem Narrativ als einer belastbaren Kostenlogik.
Operativ landet die Diskussion dann schnell bei DevOps & Private Cloud statt bei abstrakten Multi-Cloud-Parolen. Das ist meist der sinnvollere Blick. Die eigentliche Frage lautet nicht, welche Wolke man bevorzugt, sondern welches Betriebsmodell den Workload mit vertretbarem Aufwand trägt.
Für die Entscheidung helfen harte Schwellen mehr als allgemeine Prinzipien. Ein Go ist plausibel, wenn der Workload über Monate relativ konstant läuft, die Zielarchitektur auf Standardkomponenten basiert und der erwartete Vorteil auch bei 15 bis 25 Prozent Mehrkosten im Migrationsprojekt noch positiv bleibt. Ein Prüffall liegt vor, wenn nur ein Teil des Stacks portabel ist oder wenn Einsparungen fast vollständig an einem einzelnen Kostenblock hängen. Ein Stopp ist angezeigt, wenn die Rechnung nur mit perfekter Auslastung, minimalem Personalaufwand oder unrealistisch kurzer Migration aufgeht.
Ich habe in Bewertungsrunden öfter gesehen, dass Teams ihre eigene Betriebsreife zu optimistisch einschätzen. Solange Incident-Management, Patch-Fenster und Kapazitätsplanung nicht als Routine funktionieren, ist ein Exit kein Kostenhebel, sondern ein Risikohebel. Das klingt hart. Es spart später trotzdem Geld.
Monatsrechnungen aus dem Cloud-Portal reichen nicht. Für eine belastbare Entscheidung braucht es ein 36-Monats-TCO-Modell. Sonst wirken Migration, Parallelbetrieb, Beschaffung und Betriebsaufbau kleiner, als sie später sind. Genau dort sterben viele vermeintlich gute Business Cases.
Methodisch ist die Richtung klar: Verglichen werden müssen vollständige Betriebsmodelle, nicht nur Infrastrukturpreise. Die FinOps Foundation ist dafür als Denkrahmen nützlich, weil sie Kosten entlang von Nutzung, Architektur und Verantwortung betrachtet. Für Sicherheits- und Resilienzaufwand ist NIST oft hilfreicher als Hersteller-Marketing, weil dort sichtbar wird, welche Kontrollen im Eigenbetrieb tatsächlich Arbeit erzeugen.
Public Cloud umfasst nicht nur Compute, Storage und Backups, sondern auch Egress, Managed Services, Support und internen Betriebsaufwand.
Eigene Server umfassen nicht nur Hardware, sondern ebenso Virtualisierung, Storage, Netzwerk, Redundanz, Colocation oder Rechenzentrum, Strom, Wartung, Lizenzen, internen Betrieb, Migration, Parallelbetrieb und einen Risikopuffer.
Das folgende Beispiel ist bewusst als illustratives Szenario zu lesen, nicht als allgemeine Schwelle. Es zeigt, wie ein stabiler datenintensiver Workload über 36 Monate wirtschaftlich kippen kann.
Bei einem mittelgroßen SaaS-Anbieter mit dauerhaft laufender Datenverarbeitung und hohem ausgehendem Datentransfer lag die eigentliche Reibung nicht bei Compute, sondern bei Egress, verwalteter Datenbank und dem Aufwand für den Parallelbetrieb während der Migration. Genau diese drei Blöcke entscheiden in der Praxis öfter als die Serverpreise.
| Kostenblock über 36 Monate | Public Cloud | Eigene Server |
| Compute | 252.000 € | 96.000 € |
| Storage und Backups | 72.000 € | 54.000 € |
| Egress und Netz | 156.000 € | 24.000 € |
| Managed Services | 162.000 € | 42.000 € |
| Interner Betriebsaufwand | 54.000 € | 114.000 € |
| Hardware, Redundanz, Colocation | 0 € | 165.000 € |
| Migration und Parallelbetrieb | 0 € | 90.000 € |
| Gesamt | 696.000 € | 585.000 € |
In diesem Szenario liegt der Eigenbetrieb über drei Jahre niedriger. Das ist relevant, aber noch kein Freifahrtschein. Wenn sich die Migration zieht, zusätzliche Redundanz nötig wird oder der interne Betrieb teurer ausfällt, schrumpft der Vorteil schnell. Ein Exit sollte nur starten, wenn der Vorteil auch unter konservativen Annahmen stehen bleibt.
Aus typischen Bewertungsprojekten lässt sich ein Muster sauber beobachten: Nicht Compute allein kippt die Rechnung, sondern die Kombination aus Egress, verwalteter Datenbank und dauerhaftem Grundrauschen. Fehlt dieser Mix, ist der Exit-Fall oft schwächer, als die erste Rechnung vermuten lässt.
Für Management-Entscheidungen reicht oft ein kurzer Blick auf die dominanten Kostentreiber. Dort zeigt sich, ob ein Exit strukturell sinnvoll ist oder nur nach Sparmaßnahme aussieht.
Lassen Sie uns Ihr Projekt, den technischen Kontext und sinnvolle nächste Schritte besprechen. Ein kurzes Gespräch reicht oft aus, um Risiken, Umfang und Richtung einzuordnen.
So starten wir
24h
Nach Ihrer Nachricht melden wir uns mit einem Gesprächstermin und einer ersten Einschätzung. Wir helfen zu entscheiden, ob Bauen, Integrieren, Automatisieren oder ein einfacherer Einstieg sinnvoll ist.
So starten wir
24h
Nach Ihrer Nachricht melden wir uns mit einem Gesprächstermin und einer ersten Einschätzung. Wir helfen zu entscheiden, ob Bauen, Integrieren, Automatisieren oder ein einfacherer Einstieg sinnvoll ist.
| Kostentreiber | Public Cloud meist stärker | Eigene Server meist stärker |
| Stabile Grundlast | laufende Compute-Kosten | Kapitalbindung bleibt planbar |
| Hoher Datenausgang | Egress-Gebühren | Netz und Transit günstiger planbar |
| Verwaltete Dienste | Komfort mit Aufpreis | mehr Betriebsaufwand intern |
| Schwankende Last | Elastizität als Vorteil | Überprovisionierung droht |
| Schnelle Produktänderungen | hohe Änderungsfähigkeit | mehr Abstimmung und Vorlauf |
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.
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.
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:
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.
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:
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.
Vor allem bei stabiler Dauerlast, hohem ausgehendem Datenverkehr, geringer Plattformbindung und einem Team mit belastbaren Betriebsprozessen.
Nein. Erst wenn nach Optimierung in der Public Cloud weiterhin ein struktureller Kostennachteil bleibt, wird Cloud Exit zur ernsthaften Option.
Weil Migration, Parallelbetrieb, Beschaffung, Redundanz und interner Betriebsaufwand sonst systematisch zu klein wirken.
Ja. Häufig ist es wirtschaftlicher, nur stabile oder datenintensive Workloads auf eigene Infrastruktur zu verlagern und cloudnahe Dienste in der Public Cloud zu belassen.
