IBM-POWER-Hardware ist kapitalintensiv, AIX/PowerVM wird pro Socket lizenziert, und IBM-SWMA/HWMA-Verlängerungen summieren sich Jahr für Jahr — während AIX-Spezialisten immer schwerer zu finden sind. Ein IBM-Ausstieg verlagert diese Workloads auf Commodity-x86 mit einer offenen, Kubernetes-nativen Plattform, die Ihr bestehendes Team betreiben kann.
Ænix führt IBM-AIX/Power-Migrationen End-to-End durch. Dieselben Ingenieure, die Cozystack gebaut haben und betreiben — die Open-Source-Zielplattform, Apache 2.0, CNCF-Projekt — arbeiten mit Ihrem Team an Assessment, Sequenzierung und Umsetzung.
Passt zu: Ænix Private Cloud Platform für regulierte Banken und Unternehmen (Air-Gap, Billing, gemanagte Migration). Sie ersetzen speziell IBM Cloud Pak / OpenShift? Siehe die OpenShift-Alternative.
Wer 2026 einen IBM-Ausstieg durchführt
Ausgelöst durch:
- IBM Power Systems (AIX) am End-of-Life — ein Refresh bedeutet erneut einen kapitalintensiven POWER-Kauf oder den Ausstieg. Das AIX-End-of-Life-Fenster ist der natürliche Auslöser.
- Steigende IBM-Kosten — teure POWER-CapEx, AIX- + PowerVM-Lizenzierung pro Socket und IBM-SWMA/HWMA-Supportverträge Jahr für Jahr.
- Oracle-auf-Power-Steuer — Oracle hat auf POWER einen Core-Factor von 1,0 (Maximum). Jeder Nicht-Oracle-Workload auf POWER bläht die lizenzierbare Core-Zahl auf.
- Knappe Spezialisten — AIX/PowerVM-Expertise ist ein schrumpfender, teurer Talentpool; Kubernetes/DevOps nicht.
- Souveränität und Sanktionsrisiko — ein proprietärer Single-Vendor-Stack hat ein anderes Risikoprofil als eine offene, CNCF-geführte Plattform für staatliche und regulierte Institute.
- Modernisierung — ein Legacy-Bestand, bei dem der Upgrade-Pfad zugleich der Ausstiegspfad ist, oft begleitet vom Umstieg auf Microservices.
Treffen zwei oder mehr zu, verstärkt ein strukturierter Ausstieg den Nutzen. Ist ein POWER-Refresh bereits budgetiert und nichts anderes drückt, ist „bleiben und optimieren“ die ehrliche Antwort.
Was eine Ænix-IBM-Migration abdeckt
1. Bestandsaufnahme und Assessment AIX/Power-Bestand: LPARs, Sockets und Cores, Firmware, PowerVM-Abhängigkeiten, Oracle-Footprint, Cloud-Pak/OpenShift-Nutzung. Workload-Klassifizierung: jetzt-neu-bauen / später-re-plattformieren / auf-Bare-Metal-belassen (Oracle) / abschalten.
2. Zielarchitektur Zielplattform auf Commodity-x86. Cozystack als Standard — KubeVirt für VMs, Cilium (eBPF) für Networking, LINSTOR/DRBD auf ZFS für Storage, Tenant-CRD für Mandantenfähigkeit. Kapazitätsmodell, HA- und Geo-Design.
3. Migrationsdurchführung Kohortenweise. Microservices und Container-Workloads zuerst; VMs via KubeVirt; Datenbanken re-plattformiert oder extern angebunden. Parallelbetrieb gegen den IBM-Bestand bis zur Validierung. Live-Migration und Geo-Stretch übernimmt die Plattform.
4. Decommissioning POWER-Frames werden außer Betrieb genommen, sobald Kohorten abgeschlossen sind; AIX/PowerVM- und IBM-Supportverträge werden zurückgefahren. Oracle-Footprint auf dedizierte Hosts verdichtet.
Ehrlicher Scoping-Hinweis — Endianness. AIX ist Big-Endian auf POWER; x86 ist Little-Endian. Es gibt kein Binary-Lift-and-Shift. Moderne Microservices und Standard-Datenbank-/Middleware ziehen sauber um; Legacy-Monolithen brauchen einen Re-Architecture-Schritt. Wir trennen beide Klassen im Assessment, statt es mitten im Cutover zu entdecken.
Die Ökonomie: Cozystack vs IBM
Für Entscheider außerhalb der IT zählt die Sprache der Kosten. Das folgende Modell ist ein illustratives List-Price-Szenario für eine mittelgroße Bank (~500 Mitarbeitende), die den Teil der Workloads verlagert, der POWER verlassen kann (Microservices, VMs, Nicht-Oracle-Datenbanken), über einen Drei-Jahres-Horizont. Die Zahlen sind Größenordnungen und werden im Assessment auf realen Bestandsdaten neu berechnet.
| Position (3 Jahre) | IBM / AIX / Power | Cozystack (x86) |
|---|---|---|
| Hardware (CapEx) | 200.000 $ — Refresh 2 POWER-Server | 90.000 $ — 6 Commodity-x86-Nodes |
| OS-/Plattform-Lizenzen | 40.000 $ — AIX + PowerVM | 0 $ — Apache 2.0 |
| Support (3 Jahre) | 180.000 $ — IBM SWMA/HWMA | 198.000 $ — Ænix Plus (24×7, Enterprise-Module, Schulung, Migrationsbegleitung) |
| Oracle (Lizenz + Support) | 300.000 $ — auf geteiltem POWER (Core-Factor 1,0) | 120.000 $ — auf minimalen dedizierten Footprint isoliert |
| Installation + Migration + Schulung | — | 0 $ — Installation bei Subscription inklusive; Migration & Schulung im Tier enthalten |
| Gesamt (3 Jahre) | 720.000 $ | 408.000 $ |
Die Ænix-Subscription ist vergleichbar mit der reinen IBM-Maintenance, enthält aber bereits 24×7-Support, Enterprise-Module, Installation, Schulung und Migration — ohne separate Einmalgebühren. Rechnen Sie Ihre eigenen Zahlen mit dem ROI-Rechner oder in einem Discovery-Gespräch.
Oracle: die Lizenzfalle, die es zu vermeiden gilt
Der teuerste Fehler bei einem Power-zu-Kubernetes-Umzug ist, produktives Oracle im Cluster zu betreiben.
- Oracle wertet Kubernetes und KubeVirt als Soft Partitioning. CPU-Limits und Pinning verengen den Lizenzumfang nicht — „die Prozessoren aller Cluster-Nodes unterliegen der Oracle-Lizenzierung“.
- Lizenziert wird der Node, nicht der Pod. Ein ganzer Worker-Node zählt, selbst wenn Oracle nur einen Bruchteil seiner Cores nutzt; eine KubeVirt-VM gilt nicht als von Oracle anerkanntes Hard Partitioning.
- Der saubere Weg: produktives Oracle auf dedizierter, separat lizenzierter Bare-Metal-Hardware halten und als externe Anwendung (Helm-Chart / Operator mit Verbindungspunkten und Credentials via External Secret Reference) über ein privates Netz anbinden. Tenant-Workloads erreichen es wie jeden Managed-Endpoint; die Datenbank wird nie in den Cluster gezogen.
Das entspricht der Praxis der meisten Banken und verdichtet den lizenzierbaren Footprint, sobald Nicht-Oracle-Workloads POWER verlassen. (Oracles Partitioning Policy ist „educational, not contractual“ — das endgültige Modell mit Oracle und Ihrer Rechtsabteilung abstimmen.)
Cozystack vs OpenStack vs IBM Cloud Pak
| Kriterium | Cozystack | OpenStack | IBM Cloud Pak / OpenShift |
|---|---|---|---|
| Was es ist | Offenes PaaS-Framework auf Kubernetes zum Cloud-Bau | IaaS — modulare Infrastruktur-Services | Proprietäres Daten-/AI-Software-Bundle auf Red Hat OpenShift |
| VM + Container | Eine API (KubeVirt + Container, ein Scheduler) | Getrennt: VMs via Nova, Container via Zun/Magnum | Container-zentriert; kein natives einheitliches VM+Container-Provisioning |
| Lizenz & Kosten | Apache 2.0; Software frei. Ænix-Support ab 1.250 $/Mon. (10 Nodes) | Apache 2.0; bezahlt wird Distro/Support | Proprietäre Subscription pro Cluster, vCPU-per-Pod-Metrik; eingeschränkter OpenShift-Anspruch |
| Vendor-Lock-in | Gering — API-first, CNCF-geführt (Lizenz kann nicht wechseln) | Mittel — auf Distro-Ebene | Hoch — proprietärer Stack + eingeschränktes OpenShift |
| Mandantenfähigkeit | Nativ (Tenant-Modell, eBPF-Isolation, Billing-Integration) | Nativ (Keystone, Projekte, Quotas) | Unterstützt (OpenShift-Namespaces + Zen) |
| On-Prem / Air-Gap | Ja | Ja | Ja (Operator-Catalog-Mirroring) |
Cozystack ist ein CNCF-Sandbox-Projekt — seine Lizenz bleibt garantiert Apache 2.0 und entfernt das Risiko „Vendor ändert die Lizenz“, das bei proprietären und quasi-offenen Produkten besteht. Für eine staatliche Bank unter einem Digitale-Souveränität-Mandat ist das ein grundlegend anderes Risikoprofil.
Storage und Skalierung auf x86
Die Zielarchitektur ist für lineares horizontales Wachstum ausgelegt — jeder x86-Node liefert sowohl Compute als auch einen Anteil verteilten Storage, ohne Re-Architecture:
- Storage im Kernel. LINSTOR orchestriert DRBD-Geräte pro Volume auf ZFS; DRBD läuft im Linux-Kernel — minimaler Overhead, schneller als Userspace-Lösungen wie Longhorn. Nach Rückkehr eines Nodes resynct DRBD per Bitmap nur die geänderten Chunks, nicht die ganze Platte — entscheidend bei großen Volumes.
- Kein Engpass bei Skalierung. Jede PVC ist ein eigenständiges DRBD-Gerät über den Cluster verteilt — 100 Volumes bedeuten 100 unabhängige Geräte, kein fettes geteiltes Gerät.
- Netzwerk. Cilium eBPF ersetzt kube-proxy durch O(1)-In-Kernel-Service-Lookup; die Latenz degradiert nicht mit wachsender Service-Zahl.
- Geo-Stretch. Cluster können sich über bis zu drei Rechenzentren erstrecken; die Replikation wird nur für eine migrierende VM synchron, gesteuert durch ein hartes RTT-Budget (~15 ms).
- Bewährte Skalierung. Die Architektur lief in Produktion bis 800 Nodes / ~3,2 PB — reichlich Reserve gegenüber einem typischen Bankbestand.
So arbeitet Ænix
- Assessment (5-10 Tage) — Platform Readiness Assessment: AIX/Power-Bestand, Zielarchitektur, Workload-Klassifizierung, Oracle-Plan, Cutover-Sequenzierung, Risiko-Register.
- Pilot (4 Wochen) — Cozystack als funktionierendes Framework gegen Ihre realen Anforderungen aufgesetzt; Erfolgskriterien vorab vereinbart. Der Pilot wird auf das erste Support-Jahr angerechnet.
- Migration — Kohorten-Durchführung mit Parallelbetrieb-Validierung. Im Enterprise-Tier wird die Migration vollständig von Ænix gemanagt; Legal/Procurement läuft über Ihre Vorlagen (Ausschreibungen, Formulare).
- Betrieb (optional) — gemanagter Cozystack-Betrieb, 24×7, nach dem Cutover.
Eine wiederkehrende Praxis-Idee: die Plattform auf den am End-of-Life freiwerdenden POWER-Servern aufsetzen (POWER unterstützt Linux) — als Live-Demonstration vor dem Commitment des breiteren Bestands.
Warum gerade Ænix
- Wir haben das Ziel gebaut. Aufwandsschätzungen sind an ausgelieferter Arbeit kalibriert, nicht an Theorie.
- Ehrlich bei den schweren Teilen. Endianness, Oracle-Lizenzierung und Legacy-Re-Architecture werden im Assessment offengelegt — nicht mitten im Cutover entdeckt.
- Von Ihrem Team betreibbar. Die Plattform läuft auf Kubernetes-Kompetenzen, die Sie einstellen können — Schluss mit der Abhängigkeit von knappen AIX/PowerVM-Spezialisten.
- Offenes Ziel. Cozystack ist Apache 2.0 und CNCF-geführt — die Plattform, auf die Sie migrieren, gehört Ihnen, ohne Lizenz, die sich unter Ihnen ändern kann.
- Teams in EU + Zentralasien. Zeitzonenfreundlich für MENA- und GUS-Bestände; ausgerichtet an EU-Regulatorik.
Typischer Migrationszeitplan
| Wann | Was |
|---|---|
| Tag 0 | Discovery-Gespräch (kostenlos) — Eignung bestätigen |
| Tage 1-10 | Platform Readiness Assessment |
| Woche 2 | Executive-Readout — schriftlicher Plan + TCO auf realen Daten |
| Wochen 3-6 | 4-wöchiger Pilot gegen reale Workloads |
| Monate 2-6 | Workload-Kohorten migrieren; POWER-Frames werden außer Betrieb genommen |
| Monate 6-12 | IBM/AIX-Decommissioning; Oracle auf dedizierte Hosts verdichtet |
Bestandsgröße und der Legacy-/Microservice-Mix bestimmen den tatsächlichen Zeitplan; die Sequenzierung wird im Assessment festgelegt.
IBM-Migrationen, die wir begleitet haben
"Running Nuvolos on sovereign bare metal meant we needed hyperscaler-grade multi-tenancy without the hyperscaler. Cozystack delivered exactly that — isolated tenants, shared GPUs, KubeVirt for legacy workloads — and it's why we can promise our customers infrastructure control, not just a workspace."
Alexandru PopescuCEO, Nuvolos
- OpenShift-Alternative — Cloud Pak / OpenShift ersetzen
- Cozystack vs OpenShift — direkter Vergleich
- Private Cloud Platform — schlüsselfertig für regulierte Banken
- Finanzdienstleistungen — Branchenkontext
- Datensouveränität — offene, kundenkontrollierte Infrastruktur
- Cozystack — die Open-Source-Zielplattform
Ænix ist das Team hinter Cozystack (CNCF-Projekt) und bietet die Ænix Platform — unser kommerzielles, produktisiertes Angebot auf Basis von Cozystack.