01 Lösung · Cloud-Exit und Migration
Cloud-Migration in beide Richtungen: erst rechnen, dann umziehen
Ob Workloads aus der Public Cloud zurück ins eigene Rechenzentrum gehören oder umgekehrt, entscheidet keine Haltung, sondern eine Rechnung pro Workload. Wir legen sie offen, migrieren anschließend in die passende Richtung und betreiben das Ergebnis. Der Einstieg ist das Cloud-Exit- und TCO-Assessment, nicht der Umzug.
Erstgespräch buchen- Einstieg
- Cloud-Exit- und TCO-Assessment: Kostenmodell nach Verursacher, Szenarien, Austrittsfähigkeit.
- Erfahrung
- Über 100 Migrationen in drei Jahren. Ein CTO führt in der ganzen Laufbahn ein bis fünf durch.
- Vorgehen
- Fünf Phasen, Go/No-Go an jedem Übergang, Rückfallweg je Dienst. Kein Stichtag, an dem alles kippt.
- Danach
- Betrieb 24/7 aus derselben Hand: Rufbereitschaft, Patch- und Eskalationsmanagement.
02 Ausgangslage
Die Entscheidung fällt fast immer ohne Zahlen
Cloud rein oder Cloud raus wird als Grundsatzfrage verhandelt. Entschieden wird sie pro Workload, und dafür fehlt meistens die Rechnung.
„Die Rechnung wächst schneller als die Last."
Egress, Cross-AZ-Traffic und Premium-Support-Tiers stehen in keiner Planung, tauchen aber jeden Monat auf. Laut Flexera State of the Cloud 2026 gelten 29 Prozent der Cloud-Ausgaben als verschwendet.
„Ob wir überhaupt rauskönnen, weiß niemand."
Die Erhebung von BEREC und Beltug fand in unter 5 Prozent der Cloud-Verträge brauchbare Exit-Klauseln. Was ein Wechsel technisch kostet, hat vorher niemand gerechnet.
„Wir machen das zum ersten Mal."
Ein CTO führt in der gesamten Laufbahn ein bis fünf Migrationen durch. Jede Falle auf dem Weg ist für Ihr Team neu, und der Bestand läuft nebenher weiter.
Keiner dieser Sätze ist ein Versagen. Sie sind das normale Ergebnis davon, dass eine Migrationsentscheidung neben dem Tagesgeschäft getroffen werden soll.
03 Die Lösung
Wir verkaufen keine Richtung, wir rechnen beide
Ein Anbieter für den ganzen Weg: analysieren, migrieren, betreiben. Alles ist einzeln buchbar, und wenn ein Workload in der Public Cloud richtig liegt, sagen wir das.
Cloud-Exit- und TCO-Assessment
Der risikoärmste Einstieg: Kostenmodell nach Verursacher, TCO-Szenarien für Public Cloud, Private Cloud und eigenes Rechenzentrum, dazu eine priorisierte Maßnahmenliste. Egress und Support-Tiers sind darin eigene Posten.
Bewertung je Workload statt Grundsatzentscheidung
Kosten, Compliance und Performance werden pro Workload bewertet. Das Ergebnis ist oft eine Hybrid-Cloud-Lösung als dauerhafte Zielarchitektur und keine Bewegung in nur eine Richtung.
Austrittsfähigkeit in Zahlen
Was ein Exit technisch und finanziell kostet, steht vor der Entscheidung fest: Datenvolumen, Egress, Abhängigkeiten von proprietären Diensten, Restlaufzeiten und Ausstiegsklauseln.
Migration ohne Stichtag
Kein Wochenende, an dem alles kippt: Ihr Bestand läuft weiter, migriert wird Service für Service, und jeder Schritt hat einen Rückfallweg.
Zielplattform ohne neuen Lock-in
Proxmox, KVM oder Kubernetes auf Debian, in deutschen Rechenzentren oder Ihrem eigenen. Alles Open Source, Ihre Konfigurationen liegen als Git-Repositories bei Ihnen.
Betrieb aus derselben Hand
Nach der Migration übernehmen wir den Betrieb: 24/7 mit Rufbereitschaft, Monitoring und Alerting, Patch- und Eskalationsmanagement. Wer am Ende betreibt, plant anders.
04 So läuft es ab
Fünf Phasen. An jedem Übergang können Sie aussteigen.
Vor jeder Phase steht eine Go/No-Go-Entscheidung. Bis zur Migration ist nichts Produktives umgestellt.
Phase 01
Analyse
Wir sehen uns an, was tatsächlich läuft. Nicht was in der Doku steht. Hier entstehen Kostenmodell und TCO-Szenarien.
Phase 02
Zielbild
Vorschlag mit Kosten und Risiken, je Workload eine Empfehlung. Hier fällt die erste Go/No-Go-Entscheidung.
Phase 03
Testumgebung
Wird gebaut und belastet, während Ihr Bestand unangetastet weiterläuft.
Phase 04
Migration
Service für Service, mit Rückfallweg. Kein Stichtag, an dem alles kippt.
Phase 05
Betrieb
24/7, Monitoring, Patch- und Eskalationsmanagement, laufende Beratung.
In den dokumentierten Projekten lagen zwischen erstem Spatenstich und abgeschalteter Altumgebung zwei bis sechs Monate, je nach Landschaft.
05 Belege
Drei Wege raus, dokumentiert mit Stack
Ausgewählt, weil sie unterschiedliche Ausgangslagen zeigen: Kostenexplosion beim Hyperscaler, Performance-Problem in Azure, komplette Altlandschaft.
Textbroker Selbst gebaute AWS-Umgebung mit über 50 Services, dann verließen die Schlüsselpersonen das Unternehmen. Nach dem Exit 75 Prozent weniger Plattform- und Servicekosten bei unveränderter Verfügbarkeit. Das ist der höchste in unseren Projekten dokumentierte Wert, ein Einzelfall und kein Versprechen. Debian · Apache2 · Percona · MariaDB · GitLab 
Innotech Die Anwendung lief in Azure, mit massiven Performance-Problemen und einer Kostenkurve, die nur nach oben zeigte. Zwei Monate vom ersten Spatenstich bis zur neuen Produktivumgebung auf Private Cloud, danach 24/7 mit Patch- und Eskalationsmanagement. Proxmox · Debian · HAProxy · PostgreSQL · Redis 
Social Wave Nach der Übernahme von MeinHotspot zwei Aufgaben gleichzeitig: die Altplattform absichern und daneben eine neue Container-Plattform aufbauen. In sechs Monaten war die komplette Altinfrastruktur migriert und abgeschaltet. Kubernetes · Traefik · Velero · CephFS · MySQL 06 Ehrlich gesagt
Vier Einwände, die Sie gerade haben
„Rechnet sich ein Exit bei uns überhaupt?"
Das ist genau die Frage des Assessments. Manche Workloads liegen in der Public Cloud richtig: stark schwankende Last, kurze Laufzeit, Dienste ohne Entsprechung außerhalb. Bei stabiler Grundlast sieht die Rechnung meistens anders aus. Welche Ihrer Workloads wohin gehören, steht am Ende der Analyse.
„Wir wollen Kosten senken, aber nicht umziehen."
Dann fangen wir damit an. Rechtegrößen, ungenutzte Ressourcen, Speicherklassen, Datenwege und Commitment-Modelle heben oft genug, ohne dass eine einzige Maschine den Anbieter wechselt. Wie das im Alltag aussieht, steht in unseren Artikeln zu Kostenmanagement in der Cloud und zur Kontrolle über die Cloud-Kosten.
„Steht der Betrieb während der Migration still?"
Nein, genau das vermeidet das Vorgehen. Es gibt keinen Stichtag, an dem alles kippt. Ihr Bestand läuft weiter, migriert wird Service für Service, und jeder Schritt hat einen Rückfallweg. Die Testumgebung trägt Last, bevor der erste produktive Dienst umzieht.
„Dann sind wir hinterher von euch abhängig."
Nur wenn wir Sie auf eine eigene Plattform zögen. Tun wir nicht. Der Stack ist Open Source und CNCF-nah, jeder kompetente Dienstleister kann ihn übernehmen, und Ihre Konfigurationen liegen als Git-Repositories bei Ihnen. Nach unserem Engagement ist Ihr Team eigenständiger, nicht abhängiger.
07 Fasttrack-Analyse
Fünfzehn Minuten mit jemandem, der Ihren Job hatte
Im Team sitzen Leute, die selbst CTO waren. Bringen Sie die Workloads mit, die Ihre Rechnung treiben, und Sie bekommen eine Einschätzung, ob sich ein Exit lohnt. Wir sagen regelmäßig, dass jemand nichts ändern soll.
15 Minuten · kein Vertriebstermin · Termin direkt im Kalender
08 Häufige Fragen
Was Sie sonst noch wissen wollen
Sollen wir in die Public Cloud oder wieder heraus?
Was kostet ein Cloud-Exit und welche Egress-Kosten fallen an?
Ändert der EU Data Act etwas an den Wechselgebühren?
Wie lange dauert eine Cloud-Migration?
Auf welche Zielplattform wird migriert?
Übernehmt ihr auch eine Migration von AWS zu Azure?
Wie senken wir Cloud-Kosten ohne Architekturänderung?
Wird die Umgebung nach der Migration auch betrieben?
09 Wissen · Cloud-Exit und Kostenanalyse
Zum Weiterlesen
Die Grundlagen zu Cloud-Kosten, TCO und Exit stehen ausführlich im Wissensbereich.