OpenStack-Migration — ein kohortenbasiertes Playbook für den Umstieg auf Cozystack 2026

OpenStack ist in Telekommunikations- und Großunternehmens-Infrastrukturen nach wie vor weit verbreitet. Für die Modernisierung gibt es kein Patentrezept: Ein ausgereiftes OpenStack im Telco-Maßstab mit tiefem Support durch eine Hersteller-Distribution ist eine ganz andere Migration als ein mittelgroßes Unternehmen, das Upstream-OpenStack mit einem kleinen Betriebsteam fährt. Beide können auf Cozystack umsteigen; Phasenplanung und Risikoprofil unterscheiden sich jedoch erheblich.

Wo OpenStack weiterhin funktioniert (und das sagen wir auch)

Bevor wir über Migration sprechen, zunächst ehrlich der Gegenfall. OpenStack bleibt die richtige Antwort für:

• NFV-Umgebungen von Tier-1-Telcos, in denen die Hersteller-Distribution (Red Hat OSP, Mirantis, Canonical, Wind River) noch Support-Laufzeit hat und die VNF-Zertifizierung OpenStack-spezifisch ist
• Sehr große Bestände (>1.000 Nodes) mit tiefem OpenStack-Know-how, bei denen sich die betriebliche Komplexität bereits amortisiert hat
• Government Clouds, in denen OpenStack die vergaberechtlich vorgeschriebene Plattform ist (einige Ausschreibungen des öffentlichen Sektors in EU-Mitgliedstaaten und im APAC-Raum)
• Bestehende Investitionen im Jahr 2–3 eines fünfjährigen Rollouts, bei denen die Migrationskosten die Kosten des Weiterbetriebs übersteigen würden

Für alle anderen lohnt sich in der Regel eine ernsthafte Bewertung der Modernisierung.

Was OpenStack-Betreiber zur Migration drängt

Drei Treiber bestimmen die Diskussion 2026:

1. Lebenszyklus der Hersteller-Distributionen

Red Hat lenkt Kunden von OSP (OpenStack Platform) zu OpenShift-basierten Angeboten. Andere Distributionen (Mirantis, Canonical) sind weiter am Markt, doch die Anbieterlandschaft für OpenStack-Distributionen konsolidiert sich. Prüfen Sie die Supportdaten in Ihrem eigenen Vertrag: Bei vielen Deployments aus der Mitte der 2020er-Jahre fallen sie in die nächsten Jahre.

2. Fachkräftemangel

OpenStack-Know-how wird knapper. Neue Engineers lernen Kubernetes, nicht das Komponentenmodell aus Nova/Neutron/Cinder/Keystone. Betreiber mit tiefer OpenStack-Erfahrung gehen in den Ruhestand oder wechseln in andere Rollen. Einstellen wird schwieriger, Halten ebenso.

3. Grenze des Servicekatalogs

Der Kernumfang von OpenStack ist IaaS (Compute, Netzwerk, Storage). Verwaltete Datenbanken (Trove), Container-Orchestrierung (Magnum) und moderne Servicefamilien (Managed Kafka, S3-Äquivalent im großen Maßstab, GPU-as-a-Service, AI Inference) lassen sich entweder nur umständlich anflanschen oder liegen ganz außerhalb der Plattform. Für Betreiber, deren Kunden oder interne Teams zunehmend Services in Plattformqualität erwarten, fällt OpenStack ohne erheblichen zusätzlichen Engineering-Aufwand zurück.

Komponenten-Mapping

Für OpenStack-Betreiber, die Cozystack bewerten, gilt folgende kanonische Übersetzung:

Die meisten OpenStack-Engineers empfinden das Betriebsmodell von Cozystack als einfacher, sobald sie die Kubernetes-Lernkurve genommen haben — weniger bewegliche Teile, deklarativer, integrierte Observability. Die Lernkurve selbst ist allerdings real: 4–8 Wochen gezieltes Training pro Engineer, länger für fachliche Tiefe.

Migrationsphasen in Kohorten

Phase 0 — Assessment (14 oder 28 Tage)

Bestandsaufnahme des OpenStack-Deployments:

• Nutzung Service für Service — welche OpenStack-Services Sie tatsächlich verwenden (Nova / Neutron / Cinder fast immer, alles andere variiert)
• Workload-Inventar — Anzahl der Instanzen, Betriebssystem-Mix, vCPU-/RAM-/Disk-Profile, Kritikalitätsstufe
• Netzwerk-Inventar — Subnetze, Security Groups, Floating IPs, Konfigurationen externer Netze, Octavia-Load-Balancer
• Storage-Inventar — Cinder-Volume-Typen, Aufbewahrung von Snapshots, Nutzung von Swift-Buckets
• Mandantenfähigkeit — Hierarchie aus Projects und Domains, benutzerdefinierte Rollen, RBAC-Richtlinien
• Integrationen — VNF-Zertifizierungen der Hersteller, Observability-Anbindungen, CI/CD-Pipelines, ITSM-Werkzeuge

Ergebnis: ein Migrationsplan mit Workload-Kategorien (jetzt migrieren / später migrieren / bleiben / neu architekturieren), Risikomarkierungen und Optionen für die Phasenplanung.

Phase 1 — Cozystack-Fundament (2–4 Monate)

Hardwarebeschaffung (oder in späteren Phasen Wiederverwendung der Kapazität, die OpenStack freigibt). Die Cozystack-Plattform wird auf neuer Hardware parallel zum bestehenden OpenStack aufgebaut. Das Cilium-Networking wird gegen jene OpenStack-Netzwerkkonfigurationen validiert, die übertragen werden sollen. LINSTOR-Storage wird im großen Maßstab in Betrieb genommen. Föderierte Identität (Keycloak + IdP des Kunden).

Das Tenant-CRD-Modell wird so entworfen, dass es sich sauber aus der Project-/Domain-Hierarchie von OpenStack ableiten lässt. Jedes OpenStack-Project der obersten Ebene wird typischerweise zu einem Cozystack-Tenant, verschachtelte Projects werden zu verschachtelten Tenants.

Endzustand: Die Cozystack-Plattform läuft, ist intern validiert und bereit für das Onboarding der Workloads.

Phase 2 — Betriebswerkzeuge (2–3 Monate)

Observability-Stack (VictoriaMetrics + VictoriaLogs), integriert in das SIEM des Kunden. Backup/DR mit Velero plus anwendungsspezifischen Mustern. Runbook-Bibliothek. Rufbereitschaft. Incident-Response-Prozess. GitOps-Deployment-Workflow (standardmäßig Flux, Argo CD auf Wunsch des Kunden).

Endzustand: Werkzeuge in Produktionsbetriebsqualität sind vorhanden, die Schulung des Teams läuft.

Phase 3 — Workload-Migration in Kohorten (4–12 Monate)

Es migrieren jeweils Kohorten von 50–200 Instanzen. Pro Kohorte:

1. Image-Konvertierung — OpenStack-Glance-Images werden in ein KubeVirt-kompatibles Format konvertiert. Die meisten KVM-basierten OpenStack-Images lassen sich mit qemu-img convert und kleinen Metadatenanpassungen umwandeln. In Windows-Instanzen werden virtio-Treiber injiziert.
2. Netzwerk-Mapping — OpenStack-Subnetze auf Cilium ClusterPool + NetworkPolicies, Security Groups auf NetworkPolicies, Octavia-Load-Balancer auf MetalLB + Ingress Controller.
3. Storage-Migration — Die Daten der Cinder-Volumes werden nach LINSTOR migriert. Die Snapshot-Historie wird je nach Aufbewahrungsrichtlinie übernommen oder bereinigt. Für Daten in Swift erlaubt die S3-API-Kompatibilität eine direkte Migration nach SeaweedFS.
4. Validierungsfenster — Der Workload läuft typischerweise 7–14 Tage parallel auf Cozystack. Vor dem endgültigen Cutover ist die Freigabe des Application Owners erforderlich.
5. Endgültiger Cutover — DNS bzw. Load Balancer werden auf den Cozystack-Endpunkt umgeschaltet. Die OpenStack-Instanz bleibt für ein Rollback-Fenster von 7–30 Tagen verfügbar.

Phase 4 — Betriebsübergabe (2–4 Monate, parallel zu Phase 3)

Die Ænix-Engineers reduzieren ihre direkte Beteiligung. Das Betriebsteam des Kunden übernimmt Incidents im First- und Second-Level. Der Ænix-Support (Plus- oder Enterprise-Stufe für 24×7) läuft für die Eskalation weiter. Übergabe der Dokumentation. Sitzungen zum Wissenstransfer.

Phase 5 — Stilllegung von OpenStack (2–6 Monate)

Sobald Migrationskohorten abgeschlossen sind, wird OpenStack-Kapazität in den Cozystack-Cluster überführt. Die Hardware ist dieselbe Standard-x86-Hardware; der OpenStack-Software-Stack wird stillgelegt. Verträge für Hersteller-Distributionen laufen gemäß ihrem Lebenszyklus aus.

Woran Migrationen von OpenStack zu Cozystack scheitern

1. Neuentwurf des Netzwerkmodells

Das Netzwerkmodell von OpenStack Neutron war traditionell hochgradig konfigurierbar — Provider-Netze, Tenant-Netze, Security Groups, Floating IPs, FWaaS, VPNaaS, komplexe Routing-Topologien. Das eBPF-Modell von Cilium ist grundlegend anders: L4/L7-NetworkPolicies, eBPF-basiertes Routing, Hubble für Observability.

Ausgefeilte Neutron-Konfigurationen auf Cilium zu übertragen, erfordert sorgfältige Architekturarbeit in Phase 0–1. Wer diese überspringt, erlebt in Phase 3 Produktionsvorfälle, weil Kunden-Workloads ein bestimmtes Netzwerkverhalten erwarten, das sich nicht direkt übertragen lässt.

2. Übersetzung der Mandanten-Richtlinien

Das rollenbasierte Zugriffsmodell von OpenStack (Keystone-Rollen, Project-Policies) lässt sich nicht 1:1 auf Kubernetes RBAC + Tenant CRD abbilden. Benutzerdefinierte Rollen für bestimmte OpenStack-APIs haben möglicherweise keine direkte Entsprechung in Kubernetes. Planen Sie Zeit für einen Neuentwurf der Richtlinien ein statt für eine mechanische Übersetzung.

3. VNF-Zertifizierung

Tier-1-Telcos mit zertifizierten VNFs stehen vor einer anderen Herausforderung: Der VNF-Hersteller zertifiziert auf bestimmten OpenStack-Distributionen, nicht auf Cozystack. Drei Ansätze:

• VNFs auf KubeVirt unter Cozystack betreiben — die VNF läuft als VM; ob die Herstellerzertifizierung diese Konfiguration abdeckt, ist offen. Ein Gespräch mit dem Hersteller ist notwendig.
• Zertifizierte VNFs auf OpenStack belassen — parallele Plattformen für den Lebenszyklus der zertifizierten VNF; ein Modernisierungs-Track für neue VNFs auf Cozystack.
• Ein Cloud-native Äquivalent verhandeln — viele VNF-Hersteller wechseln zu Cloud-Native Network Functions (CNFs) auf Kubernetes; die Migration lässt sich womöglich mit der CNF-Modernisierung des Herstellers verzahnen.

In der Praxis kommen alle drei Muster vor, oft beim selben Betreiber — je nachdem, um welchen VNF-Hersteller und welche Generation es geht.

4. Wandel der Betriebskultur

OpenStack-Betreiber sind imperative APIs gewohnt (CLI-Befehle, REST-Aufrufe, Aktionen in der Konsole). Cozystack erwartet GitOps für produktive Änderungen. Das ist ein Kulturwandel, nicht nur ein Werkzeugwechsel. Engineers, deren OpenStack-Expertise auf imperativen Workflows aufbaut, brauchen 4–8 Wochen gezieltes Training plus 3–6 Monate Praxis, um die GitOps-Disziplin zu verinnerlichen.

Ein Ænix-Engagement umfasst Training als eigenen Workstream; zugleich muss der Kunde selbst in den kulturellen Wandel investieren.

Realistische Zeitpläne

Mittelgroßes Unternehmen (200–500 Nodes, einfache Mandantenstruktur, überwiegend Standard-Networking):

• Phase 0: 14 oder 28 Tage
• Phase 1: 2–3 Monate
• Phase 2: 1–2 Monate
• Phase 3: 6–12 Monate
• Phase 4–5: 3–6 Monate

Gesamt: 12–24 Monate

Tier-1-Telco (1.000–5.000 Nodes, komplexe Mandantenstruktur, zertifizierte VNF-Umgebungen, NFV-spezifisches Networking):

• Phase 0: 2–3 Monate
• Phase 1: 4–6 Monate
• Phase 2: 2–3 Monate
• Phase 3: 12–24 Monate (mehrere parallele Kohorten)
• Phase 4–5: 6–12 Monate
• Track zur VNF-Modernisierung: parallel 18–36 Monate

Gesamt: 24–48 Monate für die vollständige Modernisierung; erste produktive Workloads auf Cozystack innerhalb von 12–18 Monaten

Wann die Migration von OpenStack zu Cozystack die richtige Antwort ist

Gute Passung:

• Der Lebenszyklus der Hersteller-Distribution erzwingt innerhalb von 24 Monaten eine Entscheidung
• Der Fachkräftemangel beginnt, die Betriebsqualität zu beeinträchtigen
• Die Kundennachfrage nach verwalteten Datenbanken / S3 / Containern / GPU-Services übersteigt, was OpenStack nativ abdeckt
• Ein Modernisierungsbudget steht über 2–4 Jahre zur Verfügung

Bedingte Passung:

• Stabiles, ausgereiftes OpenStack-Deployment mit tiefer Teamexpertise und ohne Druck auf den Servicekatalog — die Modernisierung kann bis zum Ende des Herstellerlebenszyklus warten
• Sehr große Bestände (>5.000 Nodes), bei denen die Modernisierungskosten im mehrstelligen Millionenbereich liegen — ein gestaffeltes, mehrjähriges Programm ist erforderlich

Schlechte Passung:

• Kürzlich ausgerolltes OpenStack im ersten Jahr eines Fünfjahresprogramms — bringen Sie zu Ende, was Sie begonnen haben, und modernisieren Sie am Ende des Lebenszyklus
• OpenStack auf Basis einer Vergabevorgabe der öffentlichen Hand ohne Spielraum für einen Plattformwechsel

Aufbau des Engagements

• Discovery Call (30 Min., kostenlos)
• Platform Readiness Assessment (Festpreis, 14 Tage fokussiert oder 28 Tage vollständig) — Workload-Kategorien, Optionen für die Phasenplanung, Risikomarkierungen
• Pilot-Deployment (2–3 Monate) — Cozystack wird aufgebaut, 50–100 Workloads werden migriert, Abrechnungs- und Betriebsabläufe validiert
• Migration in Kohorten (6–24 Monate) — Workload-Migration in Kohorten
• Stilllegung von OpenStack (parallel zur Kohortenmigration) — schrittweise, sobald Kohorten abgeschlossen sind
• Support-Subskription (laufend) — Plus- oder Enterprise-Stufe für Eskalation rund um die Uhr (siehe Preise)

Weiterführende Inhalte

• OpenStack-Migrations-Hub — kommerzielle Landingpage
• OpenStack vs Cozystack: Modernisierung — Analyse des Modernisierungspfads
• OpenStack-Alternative — kommerzielle Landingpage mit Fokus auf Alternativen
• Produktseite Public Cloud Platform — häufiges Zielprodukt für OpenStack-Migrationen von Hosting-Anbietern