IBM AIX / Power Migration — von Power in eine offene Cloud

Open-Source Cozystack (CNCF-Projekt, von Ænix initiiert) → Ænix Public Cloud, Private Cloud und AI Platform → Ænix baut, betreibt und migriert sie.

Ein Ausstieg aus IBM AIX/Power verlagert Workloads von teurer POWER-Hardware, AIX/PowerVM-Lizenzen und IBM-SWMA/HWMA-Verträgen auf Standard-x86 mit einer offenen, Kubernetes-nativen Plattform. Cozystack — Apache 2.0, ein CNCF-Sandbox-Projekt — betreibt VMs und Container über eine gemeinsame API (KubeVirt + Cilium + LINSTOR), sodass ein vorhandenes Kubernetes-Team die Plattform ohne knappe AIX/Power-Spezialisten betreiben kann. Ænix begleitet den Ausstieg von Anfang bis Ende: Bestandsaufnahme, Zielarchitektur, Oracle-sichere Auslegung, Cutover in Kohorten, Stilllegung. Der entscheidende Hebel für Entscheider außerhalb der IT sind die Kosten: Ein Modell für eine mittelgroße Bank zeigt rund 40 % weniger TCO über drei Jahre — durch x86 statt POWER, keine Lizenzkosten für die Plattform und einen kleineren, teuren Oracle-Footprint auf Power.

Auf einen Blick

  • Was es ist Migration von IBM AIX/Power (und Cloud Pak/OpenShift) auf Standard-x86 mit Cozystack, von Anfang bis Ende begleitet
  • Lizenz der Zielplattform Apache 2.0 — keine Lizenzkosten für die Plattform pro Socket, Core oder vCPU
  • Virtualisierung KubeVirt ersetzt PowerVM; VMs und Container auf einem Kubernetes-Scheduler
  • Typische TCO-Reduktion ~40 % über drei Jahre (illustratives Modell einer mittelgroßen Bank; wird auf realen Bestandsdaten neu berechnet)
  • Oracle Bleibt auf dediziertem Bare Metal und wird als externe Anwendung angebunden — lizenzrechtlich sauber (Oracle wertet KubeVirt als Soft Partitioning)
  • Vorgehen Platform Readiness Assessment (14 oder 28 Tage, Festpreis) → Pilot → Migration in Kohorten; Migrationsleistungen werden nach dem Assessment angeboten
  • Kommerzielles Modell Die Ænix Private Cloud Platform wird per RFP angeboten; Support-Stufen für selbst betriebenes Cozystack beginnen bei 1.250 USD pro 10 Nodes und Monat

Quelle: Cozystack-Dokumentation, Oracle Partitioning Policy

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.

IBM AIX / PowerVM auf POWER
LPARsLizenzierung pro SocketSWMA/HWMA
durchläuft
Cutover in Kohorten
Microservices zuerstVMs über KubeVirtValidierung im Parallelbetrieb
landet auf
Cozystack auf Standard-x86
KubeVirtCiliumLINSTOR
endet mit
POWER-Systeme außer Betrieb
~40 % weniger TCO über drei JahreOracle auf dediziertem Bare Metal

Vergleichen Sie noch? Preise & Plattformen ansehen →

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 / PowerCozystack (x86)
Hardware (Investition)200.000 USD — Refresh von 2 POWER-Servern90.000 USD — 6 Standard-x86-Nodes
Betriebssystem-/Plattform-Lizenzen40.000 USD — AIX + PowerVM0 USD — Apache 2.0
Support (3 Jahre)180.000 USD — IBM SWMA/HWMA198.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 USD408.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

KriteriumCozystackOpenStackIBM Cloud Pak / OpenShift
Was es istOffenes PaaS-Framework auf Kubernetes für den Aufbau einer CloudIaaS — modulare InfrastrukturdiensteProprietäres Daten- und KI-Softwarepaket auf Red Hat OpenShift
VMs + ContainerEine API (KubeVirt + Container, ein Scheduler)Getrennt: VMs über Nova, Container über Zun/MagnumContainer-zentriert; keine native, einheitliche Bereitstellung von VMs und Containern
Lizenz und KostenApache 2.0; Software kostenlos. Support-Stufen von Ænix ab 1.250 USD pro Monat und 10 NodesApache 2.0; bezahlt werden Distribution/SupportProprietäre Subscription pro Cluster, vCPU-pro-Pod-Metrik; eingeschränktes OpenShift-Nutzungsrecht
HerstellerbindungGering — API-first, unter dem Dach der CNCF entwickeltMittel — auf Ebene der DistributionHoch — proprietärer Stack + eingeschränkt mitgeliefertes OpenShift
MandantenfähigkeitNativ (Tenant-Modell, eBPF-Isolation, Billing-Anbindung)Nativ (Keystone, Projekte, Quotas)Unterstützt (OpenShift-Namespaces + Zen)
On-Prem / Air-GapJaJaJa (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

WannWas
Tag 0Discovery-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äsentationPilot mit realen Workloads
AufbauphaseWorkload-Kohorten ziehen um; POWER-Systeme werden außer Betrieb genommen, sobald Kohorten abgeschlossen sind
Ende des ProgrammsStilllegung 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.




Æ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.

Häufig gestellte Fragen

Können wir AIX-Binaries per Lift-and-Shift auf x86 übernehmen?

Nein. AIX läuft auf Big-Endian-POWER, x86 ist Little-Endian. AIX-Binaries laufen auf x86 nicht unverändert — Anwendungen müssen neu gebaut oder auf eine neue Plattform portiert werden. Moderne Microservices und die meisten Datenbank- und Middleware-Workloads ziehen sauber um; ältere Monolithen brauchen einen Schritt der Neuarchitektur. Eine ehrliche Migration trennt diese beiden Klassen von Anfang an, statt ein binäres Lift-and-Shift zu versprechen.

Müssen wir auf die Live-Migration von PowerVM verzichten?

Nein. KubeVirt bietet Live-Migration laufender VMs zwischen x86-Nodes. In Stretched-Cluster-Designs über mehrere Rechenzentren wird die Replikation nur für die gerade migrierende VM auf synchron umgeschaltet, sodass die Latenz im gesamten Cluster nicht steigt. Stretched-Designs liefern wir als Engineering-Leistung beim Aufbau; ein automatisches standortübergreifendes VM-Failover gibt es nicht.

Wir sind auf Oracle Database angewiesen. Bricht Kubernetes die Oracle-Lizenzierung?

Das würde passieren, wenn Sie Oracle im Cluster betreiben. Oracle wertet Kubernetes und KubeVirt als Soft Partitioning und akzeptiert sie nicht als Mittel, den lizenzpflichtigen Umfang zu begrenzen — Oracle in einer Cluster-VM kann die Lizenzierung aller physischen Cores erfordern, auf denen es landen könnte. Das empfohlene Muster hält produktives Oracle auf dediziertem, separat lizenziertem Bare Metal und bindet es über ein privates Netz als externe Anwendung an die Plattform an. Lizenzrechtlich sauber — und so betreiben die meisten Banken Oracle ohnehin.

Ist IBM Cloud Pak / OpenShift dieselbe Art von Produkt?

Nicht ganz. Cloud Pak ist ein proprietäres Daten- und KI-Softwarepaket auf Red Hat OpenShift, lizenziert pro Cluster nach einer vCPU-pro-Pod-Metrik mit eingeschränktem OpenShift-Nutzungsrecht — eine andere Produktklasse als eine VM-Cloud. Einen OpenShift-spezifischen Vergleich finden Sie unter OpenShift-Alternative und Cozystack vs. OpenShift.

Kann unser bestehendes Team die Plattform betreiben, obwohl uns AIX-Spezialisten fehlen?

Genau darum geht es bei dieser Zielplattform. Sie wird mit Kubernetes- und DevOps-Kompetenzen betrieben — einem Talentpool, aus dem Sie tatsächlich einstellen können — statt mit knappen AIX/PowerVM-Spezialisten. Ænix bietet Schulungen an (Kubernetes Deep Dive); eine begleitete Migration und ein 24×7-Betrieb als Managed Service sind als separat angebotene Leistungen verfügbar.

Was kostet die Migration, und wie läuft die Zusammenarbeit?

Am Anfang steht ein Platform Readiness Assessment zum Festpreis (14 oder 28 Tage). Programme mit der Ænix Private Cloud Platform werden für Banken nach dem Assessment per RFP angeboten; Migrationsleistungen, ein Pilot und der Betrieb als Managed Service werden separat geplant und angeboten. Support-Stufen für selbst betriebenes Cozystack beginnen bei 1.250 USD pro 10 Nodes und Monat. Siehe die Preisseite.

Läuft das air-gapped für einen regulierten Bankbetrieb?

Ja. Air-Gap-Installation, White-Labeling, Backup und GPU-Sharing sind Open-Source-Funktionen von Cozystack; die Support-Stufen von Ænix legen fest, wie viel Unterstützung Sie dabei erhalten, und die Billing-/Chargeback-Komponenten sind Module von Ænix. Die Plattform ist On-Prem-first und für souveräne, kundenkontrollierte Infrastruktur ausgelegt — siehe Datensouveränität und Finanzdienstleistungen.

Planen Sie Ihren Umstieg?

Starten Sie mit einer Platform-Readiness-Assessment zum Festpreis — Architektur-Review, Gap-Analyse und ein Fahrplan, den Sie dem Vorstand vorlegen können.