Cloud-Migration ist 2026 eine Platzierungsentscheidung pro Workload, kein Wettlauf in die Public Cloud. Ænix führt strukturierte Cloud-Migrationen durch — Public-Cloud-Repatriation, VMware-Exit und Greenfield-Aufbau einer Private Cloud —, bei denen das Ziel aus dem Workload abgeleitet und nicht vorab festgelegt wird.
Das Team, das Ihre Migration umsetzt, hat Cozystack entwickelt und pflegt es gemeinsam mit Maintainern anderer Unternehmen — die Open-Source-Plattform, auf der die meisten Private-Cloud-Migrationen landen. Bei Assessment, Planung der Reihenfolge und Umsetzung arbeiten wir Seite an Seite mit Ihren Engineers.
Passt zu: einer der Ænix-Plattformen — das Ziel richtet sich nach dem Käuferprofil. Wer Cloud an externe Kunden verkauft (Hoster, MSPs, Telcos, nationale Betreiber), landet auf der Public Cloud Platform; regulierte Organisationen, die Cloud für die eigenen Entwickler betreiben, auf der Private Cloud Platform, deren Developer-Self-Service-Schicht die interne PaaS ersetzt; GPU- und Inferenz-Bestände auf der AI Platform.
Wann eine Cloud-Migration sinnvoll ist
Eine Migration lohnt den Aufwand, wenn ein konkreter Auslöser dahintersteht. Die häufigsten im Jahr 2026:
- VMware-Exit unter dem Subscription-Druck von Broadcom — Preissteigerungen um das 2- bis 5-Fache bei der Verlängerung, aufgelöste ELAs und das verpflichtende VCF-Bundling treiben Infrastruktur-Teams zu einer Plattform, die sie selbst kontrollieren. Das Ziel beschreibt die VMware-Alternative, die Kohortenplanung entlang der Subscription-Laufzeiten der eigene VMware-Migrations-Hub.
- Public-Cloud-Repatriation aus Kosten- oder Souveränitätsgründen — dauerhaft laufende Workloads, die beim Hyperscaler günstig gestartet sind, werden mit wachsender Größe teuer, und Vorgaben zur Datenresidenz verlangen zunehmend kundenkontrollierte Infrastruktur. Siehe Cloud-Repatriation.
- Souveränitätsanforderungen — DORA, NIS2 und sektorale Vorschriften zwingen kritische Workloads auf Infrastruktur mit klarer Rechtszuständigkeit und nachvollziehbarem Audit-Trail. Siehe Datensouveränität.
- KI- und GPU-Wirtschaftlichkeit — dauerhafte Inferenz- und Trainings-Workloads sind auf eigenen GPUs bei vernünftiger Auslastung deutlich günstiger als auf gemieteter Hyperscaler-Kapazität. Siehe Sovereign AI.
- Greenfield-Projekte — eine neue Plattform ohne Altbestand, der abgelöst werden muss; hier lässt sich eine moderne Architektur ab dem ersten Tag auf einer Private-Cloud-Plattform umsetzen.
Treffen zwei oder mehr dieser Punkte zu, verstärkt eine strukturierte Migration den Nutzen. Trifft keiner zu und funktioniert Ihr aktuelles Setup gut, lautet die ehrliche Empfehlung „bleiben und optimieren“ — und die sprechen wir regelmäßig aus.
Wie Ænix eine Cloud-Migration angeht
Das Projekt ist bewusst in Stufen aufgebaut: Sie verpflichten sich schrittweise, und vor der kostspieligen Phase steht ein Entscheidungspunkt.
Platform Readiness Assessment (14 oder 28 Tage)
Vollständiges Inventar der Workloads, Klassifizierung (jetzt migrieren / später migrieren / bleiben / Re-Platforming), ehrliche TCO-Modellierung und eine schriftliche Zielarchitektur. Das ist die Methodik hinter jeder Migration; siehe Platform Readiness Assessment.
Pilot
Eine repräsentative Kohorte zieht auf die Zielplattform um und läuft parallel zur Quelle, bis sie validiert ist. So werden Architektur und Aufwandsschätzungen an realen Workloads überprüft, bevor die Migration in die Breite geht.
Aufbau und Migration (3–18 Monate)
Engineers von Ænix arbeiten in Ihrem Team mit, migrieren die Workloads Kohorte für Kohorte und geben ihr Wissen laufend weiter. Der Betrieb kann bei Ihnen bleiben oder als Managed Service weiterlaufen.
Raster für die Platzierung der Workloads
Das Assessment ordnet jeden Workload entlang zweier Achsen ein: wie gut er technisch auf eine private Plattform passt und was er dort kostet, wo er heute läuft. Aus diesem Raster ergeben sich vier Ergebnisse — jetzt migrieren (klarer technischer und wirtschaftlicher Gewinn), später migrieren (passt gut, aber Reihenfolge oder Verträge bestimmen den Zeitpunkt), Re-Platforming (muss vor dem Umzug neu entworfen werden) und bleiben (ist bereits am richtigen Ort). Die Strategie ist die Summe dieser Einzelentscheidungen, kein von oben vorgegebener Zielprozentsatz.
Was bleiben sollte, wo es ist
Ein ehrlicher Migrationsplan lässt Workloads in Ruhe, wenn ihr Umzug Risiko ohne Gegenwert bringt. Workloads mit starken, unvorhersehbaren Lastspitzen gehören oft in die Public Cloud, wo Elastizität günstig ist. Managed Services ohne On-Premises-Entsprechung sind einen Nachbau womöglich nicht wert. Anwendungen, die gerade neu geschrieben werden, sollten auf die neue Architektur warten, statt zweimal umzuziehen. Ænix verdient nicht an Hyperscaler-Partnerschaften und hat keinen Anreiz, mehr zu migrieren als nötig — deshalb empfehlen wir ohne Zögern, einen Workload dort zu lassen, wo er ist, wenn die Zahlen dafür sprechen.
Wie die Migration selbst abläuft
Die Umsetzung folgt einem Kohortenmodell statt eines einzigen Cutovers. Workloads werden nach Abhängigkeiten und Risiko zu Kohorten gruppiert, und jede Kohorte zieht auf die Zielplattform um, während die Quelle weiterläuft. Quelle und Ziel laufen parallel, bis die Kohorte validiert ist — funktional, bei der Performance und bei der Datenintegrität —, und erst dann wird die Quelle stillgelegt. Nichts wird abgeschaltet, nur weil die neue Umgebung funktionieren sollte.
Bei Beständen, die einen älteren Virtualisierungs-Stack verlassen, ist die Image-Konvertierung automatisiert: Der Containerized Data Importer von KubeVirt übernimmt die Images der virtuellen Maschinen in die Zielplattform, und bei Windows-Gästen werden die Gast-Tools vor dem ersten Start auf dem neuen Hypervisor bereinigt. Netzwerk und Storage werden neu entworfen statt kopiert — eine private Plattform auf Basis von Cilium und LINSTOR verhält sich anders als NSX und vSAN, und wer diesen Neuentwurf überspringt, schafft eine der häufigsten Ursachen für Instabilität nach der Migration.
Die Reihenfolge berücksichtigt, was Sie bereits bezahlt haben. Laufen Verträge oder Subscriptions noch, ziehen die betroffenen Kohorten zuletzt um, sodass der Plan nie zugesagte Ausgaben abschreiben lässt. Ein Bestand mit 100 Workloads ist typischerweise in Monaten migriert, nicht in Jahren; größere Bestände ziehen in Kohorten über einen längeren Zeitraum um, während die Quellumgebung Kohorte für Kohorte zurückgebaut wird.
Woran Cloud-Migrationen häufig scheitern
Die meisten gescheiterten Migrationen haben wenige gemeinsame Ursachen, und die Assessment-Phase ist dazu da, sie früh zu erkennen:
Keine ehrliche TCO vor dem Umzug. Hardware-Erneuerung, Kapazität des Plattform-Teams und die Lernkurve im Betrieb fehlen im Modell, und das Projekt gerät ins Stocken, wenn die Wirtschaftlichkeit anders ausfällt als versprochen.
Big-Bang-Cutover. „Alles an einem Wochenende umziehen“ übersteht die Begegnung mit einem gewachsenen Unternehmensbestand selten. Was funktioniert, ist eine Migration in Kohorten mit validiertem Parallelbetrieb.
Eine unzureichend aufgebaute Zielplattform. Workloads landen auf einer privaten Plattform, die nie für den Produktivbetrieb ausgelegt war; betriebliche Altlasten wachsen, und das Team gibt der Migration die Schuld, obwohl das eigentliche Problem die Reife des Ziels ist.
Ausgelassener Neuentwurf von Netzwerk und Storage. Wer Netzwerk und Storage des Ziels als Kopie der Quelle behandelt, handelt sich Instabilität ein. Beides wird für das Ziel neu entworfen.
Erst rechnen, dann entscheiden
Die Wirtschaftlichkeit einer Migration sieht im Abstrakten attraktiv aus und entscheidet sich in der Praxis an Details — Hardware-Erneuerung, Kapazität des Plattform-Teams und die Lernkurve im Betrieb verschieben das Ergebnis. Bevor Sie sich festlegen, modellieren Sie die Differenz mit den ROI- und TCO-Rechnern: Einsparungen beim VMware-Exit, TCO von Eigenbau gegenüber einer Ænix-Plattform, Unit Economics im Hosting und ROI von GPU-/KI-Inferenz, jeweils mit anpassbaren Eingaben und sofortigen Ergebnissen.
Ein durchgerechnetes Beispiel für eine gemischte Platzierung zeigt die Fallstudie Multi-Cloud-GPU für die Wissenschaft — dort war die richtige Antwort eine Mischung aus eigener GPU-Kapazität und beibehaltener Cloud, kein vollständiger Umzug in die eine oder andere Richtung. Sie müssen die Geschäftsführung überzeugen? Siehe den Leitfaden für CTOs.
Ænix hat Cozystack (ein CNCF-Sandbox-Projekt) entwickelt und pflegt es gemeinsam mit Maintainern anderer Unternehmen. Darauf aufbauend bietet Ænix drei Plattformen an — Public Cloud, Private Cloud und AI.