IBM-POWER-Hardware ist kapitalintensiv, AIX/PowerVM wird pro Socket lizenziert, und die 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 Standard-x86 mit einer offenen, Kubernetes-nativen Plattform, die Ihr bestehendes Team betreiben kann.
Ænix begleitet IBM-AIX/Power-Migrationen von Anfang bis Ende. Die Engineers, die Cozystack — die Open-Source-Zielplattform — entwickelt haben und gemeinsam mit Maintainern anderer Unternehmen pflegen, arbeiten bei Assessment, Reihenfolge und Umsetzung Seite an Seite mit Ihrem Team.
Passt zu: Ænix Private Cloud Platform für regulierte Banken (Air-Gap-Installation, Chargeback, Migration als angebotene Leistung) oder zur OpenShift-Alternative, wenn Sie gezielt IBM Cloud Pak / OpenShift ablösen.
Wer 2026 aus IBM aussteigt
Typische Auslöser:
- IBM Power Systems (AIX) am Ende des Lebenszyklus — ein Refresh bedeutet erneut einen kapitalintensiven POWER-Kauf, oder eben den Ausstieg.
- Steigende IBM-Kosten — teure POWER-Investitionen, AIX- und PowerVM-Lizenzen pro Socket und SWMA/HWMA-Verlängerungen, Jahr für Jahr.
- Oracle-Aufschlag auf Power — Oracle setzt auf POWER einen Core-Faktor von 1,0 an (das Maximum). Jeder Nicht-Oracle-Workload, der noch auf POWER läuft, treibt die Zahl der lizenzpflichtigen Cores nach oben.
- Knappe Spezialisten — AIX/PowerVM-Know-how ist ein schrumpfender, teurer Talentpool; Kubernetes/DevOps nicht.
- Souveränitäts- und Sanktionsrisiken — für staatliche und regulierte Institute hat ein proprietärer Stack eines einzigen Herstellers ein anderes Risikoprofil als eine offene, unter dem Dach der CNCF entwickelte Plattform.
- Modernisierung — ein Altbestand, bei dem der Upgrade-Pfad zugleich der Ausstiegspfad ist, oft verbunden mit dem Umstieg auf Microservices.
Treffen zwei oder mehr Punkte zu, verstärkt ein strukturierter Ausstieg den Nutzen. Ist ein POWER-Refresh bereits bequem budgetiert und drückt sonst nichts, lautet die ehrliche Antwort „bleiben und optimieren“.
Was eine IBM-Migration mit Ænix umfasst
1. Bestandsaufnahme und Assessment AIX/Power-Bestand: LPARs, Sockets und Cores, Firmware, PowerVM-Abhängigkeiten, Oracle-Footprint, Nutzung von Cloud Pak/OpenShift. Klassifizierung der Workloads: jetzt neu bauen / später portieren / auf Bare Metal belassen (Oracle) / abschalten.
2. Zielarchitektur Zielplattform auf Standard-x86. Cozystack als Standard — KubeVirt für VMs, Cilium (eBPF) für das Netzwerk, LINSTOR/DRBD auf ZFS für Storage, Tenant-CRD für Mandantenfähigkeit. Kapazitätsmodell, Hochverfügbarkeit und standortübergreifendes Design.
3. Durchführung der Migration In Kohorten. Microservices und Container-Workloads zuerst; VMs über KubeVirt; Datenbanken werden portiert oder extern angebunden. Parallelbetrieb neben dem IBM-Bestand bis zur Validierung. Live-Migration und Geo-Stretch übernimmt die Plattform.
4. Stilllegung POWER-Systeme werden außer Betrieb genommen, sobald die Kohorten abgeschlossen sind; AIX/PowerVM- und IBM-Supportverträge laufen aus. Der Oracle-Footprint schrumpft auf dedizierte Hosts.
Ehrlicher Hinweis zum Umfang — Endianness. AIX ist auf POWER Big-Endian, x86 Little-Endian: Ein binäres Lift-and-Shift gibt es nicht. Moderne Microservices und Standard-Datenbanken und -Middleware ziehen sauber um; ältere Monolithen brauchen eine Neuarchitektur. Wir trennen beide Klassen im Assessment, nicht erst mitten im Cutover.
Die Wirtschaftlichkeit: Cozystack vs. IBM
Das folgende Modell ist ein illustratives Szenario auf Basis von Listenpreisen für eine mittelgroße Bank (~500 Mitarbeitende), die über drei Jahre den Teil ihrer Workloads verlagert, der POWER verlassen kann (Microservices, VMs, Nicht-Oracle-Datenbanken). Die Zahlen zeigen Größenordnungen und werden im Assessment auf realen Bestandsdaten neu berechnet.
| Position (3 Jahre) | IBM / AIX / Power | Cozystack (x86) |
|---|---|---|
| Hardware (Investition) | 200.000 USD — Refresh von 2 POWER-Servern | 90.000 USD — 6 Standard-x86-Nodes |
| Betriebssystem-/Plattform-Lizenzen | 40.000 USD — AIX + PowerVM | 0 USD — Apache 2.0 |
| Support (3 Jahre) | 180.000 USD — IBM SWMA/HWMA | 198.000 USD — Listenpreis der Support-Stufe Plus für 10 Nodes (24×7, begleitete Migration, 3 Std. Schulung pro Monat) |
| Oracle (Lizenz + Support) | 300.000 USD — auf geteiltem POWER (Core-Faktor 1,0) | 120.000 USD — auf einen minimalen dedizierten Footprint begrenzt |
| Migrationsleistungen | — | Angebot nach dem Assessment (oben nicht enthalten) |
| Gesamt (3 Jahre) | 720.000 USD | 408.000 USD + Migrationsleistungen |
Die Support-Zeile nutzt die veröffentlichte Stufe Plus zur Veranschaulichung; ein Programm mit der Ænix Private Cloud Platform wird für eine Bank per RFP angeboten, und Migrationsleistungen werden nach dem Assessment separat angeboten. Rechnen Sie Ihre eigenen Zahlen mit dem TCO-Rechner (Englisch) durch oder in einem Discovery-Gespräch.
Oracle: die Lizenzfalle, die Sie vermeiden sollten
Der teuerste Einzelfehler beim Umzug von Power auf Kubernetes ist, produktives Oracle im Cluster zu betreiben.
- Oracle wertet Kubernetes und KubeVirt als Soft Partitioning. CPU-Limits und Pinning verkleinern den lizenzpflichtigen Umfang nicht — „the processors of all nodes in the cluster are subject to Oracle licensing“.
- Lizenziert wird der Node, nicht der Pod. Ein ganzer Worker-Node zählt, auch 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 dediziertem, separat lizenziertem Bare Metal belassen und es über ein privates Netz als externe Anwendung an die Plattform anbinden (Helm-Chart bzw. Operator, der Verbindungsendpunkte und Zugangsdaten über eine External-Secret-Referenz kapselt). Tenant-Workloads erreichen die Datenbank wie jeden anderen Managed Endpoint; sie wird nie in den Cluster gezogen.
So schrumpft der lizenzpflichtige Footprint, während Nicht-Oracle-Workloads POWER verlassen. (Die Partitioning Policy von Oracle ist „educational, not contractual“ — stimmen Sie das endgültige Modell mit Oracle und Ihrer Rechtsabteilung ab.)
Cozystack vs. OpenStack vs. IBM Cloud Pak
| Kriterium | Cozystack | OpenStack | IBM Cloud Pak / OpenShift |
|---|---|---|---|
| Was es ist | Offenes PaaS-Framework auf Kubernetes für den Aufbau einer Cloud | IaaS — modulare Infrastrukturdienste | Proprietäres Daten- und KI-Softwarepaket auf Red Hat OpenShift |
| VMs + Container | Eine API (KubeVirt + Container, ein Scheduler) | Getrennt: VMs über Nova, Container über Zun/Magnum | Container-zentriert; keine native, einheitliche Bereitstellung von VMs und Containern |
| Lizenz und Kosten | Apache 2.0; Software kostenlos. Support-Stufen von Ænix ab 1.250 USD pro Monat und 10 Nodes | Apache 2.0; bezahlt werden Distribution/Support | Proprietäre Subscription pro Cluster, vCPU-pro-Pod-Metrik; eingeschränktes OpenShift-Nutzungsrecht |
| Herstellerbindung | Gering — API-first, unter dem Dach der CNCF entwickelt | Mittel — auf Ebene der Distribution | Hoch — proprietärer Stack + eingeschränkt mitgeliefertes OpenShift |
| Mandantenfähigkeit | Nativ (Tenant-Modell, eBPF-Isolation, Billing-Anbindung) | Nativ (Keystone, Projekte, Quotas) | Unterstützt (OpenShift-Namespaces + Zen) |
| On-Prem / Air-Gap | Ja | Ja | Ja (Spiegelung des Operator-Katalogs) |
Cozystack ist ein CNCF-Sandbox-Projekt (der Antrag auf CNCF Incubation befindet sich in der Due-Diligence-Prüfung), steht unter Apache 2.0 und wird offen gesteuert statt von einem einzelnen Hersteller. Das beseitigt den größten Teil des Risikos „der Hersteller ändert die Lizenz“, das bei proprietären und nur scheinbar offenen Produkten besteht: ein anderes Risikoprofil für eine staatliche Bank mit einem Mandat zur digitalen Souveränität.
Storage und Skalierung auf x86
Die Zielarchitektur ist auf lineares horizontales Wachstum ausgelegt — jeder x86-Node bringt Rechenleistung und einen Anteil am verteilten Storage mit, ohne Neuarchitektur:
- Storage im Kernel. LINSTOR orchestriert pro Volume eigene DRBD-Devices auf ZFS; DRBD repliziert im Linux-Kernel statt in einem Userspace-Daemon, sodass der Schreibpfad nicht bei jedem I/O in den User Space wechselt. Kehrt ein Node zurück, synchronisiert DRBD per Bitmap nur die geänderten Blöcke statt der ganzen Disk — entscheidend bei großen Volumes.
- Kein Engpass bei wachsender Größe. Jede PVC ist ein eigenständiges, über den Cluster verteiltes DRBD-Device — 100 Volumes sind 100 unabhängige Devices, nicht ein großes geteiltes.
- Netzwerk. Cilium eBPF ersetzt kube-proxy durch einen Service-Lookup im Kernel mit O(1); die Latenz verschlechtert sich nicht, wenn die Zahl der Services wächst.
- Geo-Stretch. Stretched-Cluster-Designs können bis zu drei Rechenzentren umfassen; die Replikation wird nur für eine migrierende VM synchron, begrenzt durch ein festes RTT-Budget (~15 ms). Diese Designs liefern wir als Engineering-Leistung; ein automatisches standortübergreifendes VM-Failover gibt es nicht.
Wie Ænix vorgeht
- Assessment (14 oder 28 Tage) — Platform Readiness Assessment: AIX/Power-Bestand, Zielarchitektur, Klassifizierung der Workloads, Oracle-Plan, Cutover-Reihenfolge, Risikoregister.
- Pilot — Cozystack wird als funktionierendes Framework anhand Ihrer realen Anforderungen aufgebaut; die Erfolgskriterien werden vorab vereinbart. Umfang und Preis werden im Assessment festgelegt.
- Migration — Umsetzung in Kohorten mit Validierung im Parallelbetrieb, angeboten nach dem Assessment; Recht und Einkauf können mit Ihren Vorlagen arbeiten (Ausschreibungen, Formulare).
- Betrieb (optional) — Cozystack-Betrieb als Managed Service, 24×7, nach dem Cutover, separat angeboten.
Eine Idee, die in der Praxis immer wieder aufkommt: die Plattform auf den POWER-Servern aufsetzen, die am Ende ihres Lebenszyklus frei werden (POWER unterstützt Linux) — als Live-Demonstration, bevor der übrige Bestand folgt.
Warum gerade Ænix
- Wir haben die Zielplattform entwickelt. Aufwandsschätzungen beruhen auf tatsächlich geleisteter Arbeit, nicht auf Theorie.
- Ehrlich bei den schwierigen Punkten. Endianness, Oracle-Lizenzierung und die Neuarchitektur von Altanwendungen kommen im Assessment auf den Tisch, nicht mitten im Cutover.
- Von Ihrem Team betreibbar. Kubernetes-Kompetenzen, die Sie einstellen können, statt knapper AIX/PowerVM-Spezialisten.
- Offenes Ziel. Apache 2.0 und unter dem Dach der CNCF entwickelt — Sie betreiben die Plattform, auf die Sie migrieren, ohne Lizenzkosten für die Plattform.
- Teams in der EU und in Zentralasien. Engineering-Teams in der EU und in Zentralasien; EU-Verträge über die AENIX s.r.o. (Tschechien).
Typischer Migrationszeitplan
| Wann | Was |
|---|---|
| Tag 0 | Discovery-Gespräch (kostenlos) — Eignung klären |
| Tag 1–14 (bzw. 1–28) | Platform Readiness Assessment zum Festpreis |
| Tag 14 (bzw. 28) | Ergebnispräsentation für die Geschäftsleitung — schriftlicher Plan + TCO auf realen Daten |
| Nach der Ergebnispräsentation | Pilot mit realen Workloads |
| Aufbauphase | Workload-Kohorten ziehen um; POWER-Systeme werden außer Betrieb genommen, sobald Kohorten abgeschlossen sind |
| Ende des Programms | Stilllegung von IBM/AIX; Oracle auf dedizierte Hosts reduziert |
Bestandsgröße und das Verhältnis von Altanwendungen zu Microservices bestimmen den tatsächlichen Zeitplan; der Aufbau einer Private Cloud dauert je nach Umfang typischerweise 3–12 Monate, und die Reihenfolge wird im Assessment festgelegt.
Unternehmen, die Plattformen mit Ænix betreiben
Hosting-Anbieter, die Ænix Public Cloud Platform in Produktion betreiben
Hosting-Anbieter, die die Ænix Public Cloud Platform produktiv betreiben. Für den regulierten Finanzsektor siehe die anonymisierten Fallstudien einer Bank und einer Finanzgruppe.
- OpenShift-Alternative — Cloud Pak / OpenShift ablösen
- 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
- OpenStack-Alternative und Cozystack vs. OpenStack — falls OpenStack auf Ihrer Shortlist steht
Æ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.




