Ab 30. Oktober droht Adobe-Commerce-on-Cloud-Shops mit veralteten Diensten die Sperrung

Am 30. Oktober 2026 beginnt Adobe, eine neue Sicherheitsrichtlinie für Adobe Commerce on Cloud durchzusetzen. Bei einer Umgebung, die nach diesem Datum noch Elasticsearch, MariaDB 10.5 oder älter oder RabbitMQ 3.9 oder älter betreibt, kann laut Richtlinie „der Admin-Zugriff gesperrt werden, während die Storefront online bleibt, und/oder der eingehende Traffic gesperrt werden, wodurch die Storefront offline geht“. Im Mai 2027 folgen weitere Fristen, danach müssen auch die älteren Magento-Versionen selbst aktualisiert werden.

Die Richtlinie gilt für Adobe Commerce on Cloud (PaaS) in den Versionen 2.4.4 bis 2.4.9. Sie gilt nicht für Adobes SaaS-Produkt und nicht für Shops, die Sie selbst hosten. Trifft das auf Sie zu, ist für Sie vor allem der kurze Abschnitt am Ende des Beitrags relevant. Die folgenden Daten und Zitate wurden am 20. Oktober 2026 mit Adobes eigenen Seiten abgeglichen.

Die Fälligkeitstermine

Folgende Dienste müssen Sie laut Adobe ablösen:

Das gilt für jede Magento-Version, auch für 2.4.8 und 2.4.9, und für jede Umgebung, nicht nur für Production.

Für die Magento-Version gilt eine eigene Frist. Shops auf 2.4.4 oder 2.4.5 müssen bis zum 1. Juni 2027 auf 2.4.9 aktualisieren oder zu Adobes SaaS migrieren. Shops auf 2.4.6 oder 2.4.7 haben Zeit bis zum 1. Juni 2028. Für 2.4.8 und 2.4.9 hat Adobe keine Frist festgelegt. Cloud-Shops älter als 2.4.4 sind in der Richtlinie nicht aufgeführt, doch Adobes Lifecycle-Richtlinie sieht ab dem 1. Juni 2027 dieselbe Sperrung für jede nicht unterstützte Version vor.

Wenn Sie 2.4.4 oder 2.4.5 betreiben, lassen Sie sich Ihre Termine von Adobe bestätigen. Die Richtlinienseite nennt für diese beiden Versionen in einer Tabelle den 30. Oktober 2026 für alle Service-Upgrades und in einer anderen die oben genannten Termine. Fragen Sie in Ihrem Support-Ticket nach und lassen Sie sich die Antwort schriftlich geben.

Die Folgen einer verpassten Frist

Adobe kann den Admin-Zugriff für alle Benutzer sperren, während die Storefront online bleibt, den Traffic sperren, sodass die Storefront offline geht, oder beides. Ist die Umgebung nach einer Traffic-Sperre weiterhin nicht konform, „kann Adobe die Cloud-Dienste beenden“, und die Stilllegung löscht alle Daten, Umgebungen und Branches endgültig. Eine Ankündigungsfrist vor einem der beiden Schritte nennt Adobe nicht.

Können Sie eine Frist nicht einhalten, sollen Sie sich laut Richtlinie „so bald wie möglich an Ihr Account-Team oder den Adobe Support wenden“, um „eine kurze Verlängerung“ zu erhalten. Wie lang eine Verlängerung sein kann, steht dort nicht.

Prüfen Sie, was Sie betreiben

Sie benötigen zwei Angaben: die Magento-Version und die Version jedes Dienstes in jeder Umgebung.

Die Magento-Version steht unten rechts auf jeder Admin-Seite oder ergibt sich aus bin/magento --version. Für die Dienste verweist Adobes Richtlinie auf die Cloud Console: Öffnen Sie die Umgebung und prüfen Sie jeden Dienst auf dem Tab „Containers“, der die aktuell laufende Version anzeigt.

Prüfen Sie auf Pro den laufenden Dienst, nicht das Repository. Adobes Knowledge Base beschreibt Staging- und Production-Umgebungen, in denen Änderungen an services.yaml „ignoriert werden“ und die alten Versionen weiterlaufen. Die Datei zeigt, was angefordert wurde. Der laufende Dienst zeigt, was Sie tatsächlich haben. Beachten Sie außerdem, dass New Relic den Cache auch nach einem Wechsel zu Valkey weiterhin „Redis“ nennt. Leiten Sie den Dienst daher nicht aus den Bezeichnungen im Monitoring ab.

Der Ablauf des Upgrades

Auf Pro aktualisiert Adobe die Dienste in Staging und Production für Sie, und zwar über ein Support-Ticket. Die Richtlinie verlangt dieses Ticket „mindestens 30 Tage vor Ihrem Stichtag“. Für den 30. Oktober ist dieser Zeitpunkt am 30. September verstrichen. Haben Sie noch kein Ticket eingereicht, holen Sie das jetzt nach und fragen Sie im selben Ticket nach einer Verlängerung. Änderungen an Production erfordern zudem eine Vorlaufzeit von mindestens zwei Arbeitstagen, Wochenenden nicht mitgerechnet, und in Stoßzeiten mehr.

Auf Starter beschreibt Adobes Services-Seite die Änderung als Self-Service: Das Zusammenführen einer aktualisierten .magento/services.yaml in den Production-Branch aktualisiert Production. Ein späteres Downgrade der Dienste ist nicht möglich, erstellen Sie daher vorher ein Backup. Die Richtlinie selbst fordert alle Cloud-Kunden auf, ein Ticket zu eröffnen. Klären Sie deshalb mit Adobe, wer die Änderung an Ihrem Projekt vornimmt.

In beiden Fällen bleibt ein Teil der Arbeit bei Ihnen:

• das Upgrade zuerst auf einer Nicht-Production-Umgebung testen, mindestens Checkout, Suche, Warenkorb und Ihre Integrationen,
• nach Abschluss durch Adobe einen Redeploy ausführen, der auch die RabbitMQ-Queues neu aufbaut,
• nach einer OpenSearch-Änderung einen vollständigen Reindex ausführen,
• sicherstellen, dass während des gesamten Production-Fensters jemand aus Ihrem Team oder von Ihrem Partner erreichbar ist, da Adobe Ihre Anwendung nicht testet.

Adobes Services-Seite empfiehlt, Service-Upgrades einzeln zu validieren, und warnt: „Datenbank-Upgrades haben die größten betrieblichen Auswirkungen und erfordern besondere Vorsicht.“ Führen Sie auf Pro zunächst einen Probelauf in Staging mit Daten im Umfang der Produktionsumgebung durch. Die dort benötigte Zeit ist der beste Anhaltspunkt für die Dauer des Production-Fensters.

Ein Service-Upgrade als Magento-Upgrade

Jeder Magento-Patch unterstützt bestimmte Service-Versionen, die in Adobes Systemanforderungen aufgeführt sind, und Adobe unterstützt nur die dort genannten Kombinationen. Die geforderte Version läuft daher möglicherweise nicht auf Ihrer Magento-Version. Aus dieser Tabelle ergeben sich folgende Fälle:

• 2.4.4 und 2.4.5 können PHP 8.2 nicht ausführen. Jeder Patch beider Versionen unterstützt nur PHP 8.1. Wer die PHP-Frist am 31. Mai 2027 einhalten will, muss Magento bis dahin aktualisieren, also einen Tag vor der Versionsfrist am 1. Juni.
• 2.4.6 unterstützt kein neueres PHP als 8.2, und PHP 8.2 erhält laut php.net ab dem 31. Dezember 2026 keine Sicherheitsfixes mehr. Adobes eigene Lifecycle-Richtlinie stuft dies ab Ende 2026 als PCI-Risiko ein. Der einzige Ausweg ist ein Magento-Upgrade.
• Ältere Patches brauchen für die Oktober-Frist ein Patch-Upgrade. So erfordert OpenSearch 2 mindestens 2.4.4-p13 oder 2.4.5-p12, und RabbitMQ 3.13 erfordert 2.4.4-p18. Auf einem älteren Patch kommt das Patch-Upgrade zuerst.
• OpenSearch 3 auf 2.4.6 und 2.4.7 erfordert den neuesten Patch (2.4.6-p15 oder 2.4.7-p10). Diese Patches setzen außerdem Valkey statt Redis, RabbitMQ 4.3 und MariaDB 10.11 oder neuer voraus, sodass mit dem Wechsel zu OpenSearch 3 unter Umständen auch diese Änderungen vorgezogen werden müssen. Frühere Patches von 2.4.6 und 2.4.7 unterstützen OpenSearch 2. Ob das für den 30. Oktober genügt, klären Sie in Ihrem Ticket.
• Der Sprung von einer alten Version auf 2.4.9 erfordert mehrere Schritte. Kein einzelner Patch unterstützt sowohl die alten als auch die neuen Versionen aller Dienste, und RabbitMQ muss Version für Version aktualisiert werden. Fragen Sie Adobe, mit wie vielen Production-Fenstern Sie planen sollten.

Zwei Änderungen, die größer sind, als sie wirken

Adobe selbst warnt: „Der Wechsel von Elasticsearch zu OpenSearch und von Redis zu Valkey ist eine Migration auf eine andere Software, kein Versions-Upgrade.“

Von Elasticsearch zu OpenSearch. In Commerce on Cloud wird die Suchmaschine in .magento.env.yaml (SEARCH_CONFIGURATION) und in den Service-Relationships in .magento.app.yaml festgelegt. Beide müssen auf den neuen Dienst verweisen. Auch Such-Extensions sind zu prüfen. ElasticSuite von Smile etwa unterstützt OpenSearch 3 erst ab Magento 2.4.8. Ein Shop auf 2.4.6 oder 2.4.7, der sie einsetzt, sollte die OpenSearch-Version daher vor dem 30. Oktober mit Adobe klären.

Von Redis zu Valkey. Adobes Valkey-Seite empfiehlt, den Wechsel wie einen neuen Cache zu behandeln: Sessions bleiben möglicherweise nicht erhalten, und „Benutzer werden nach Abschluss der Migration abgemeldet“. Entfernen Sie die alte Redis-Definition, denn sind beide verfügbar, verwendet Magento weiterhin Redis. Die neuesten Patches von 2.4.5 bis 2.4.7 sowie alle Patches von 2.4.8 und 2.4.9 unterstützen Redis überhaupt nicht mehr. Ein Shop, der seine Patches aktuell hält, vollzieht diesen Wechsel also vor der Frist im Mai 2027.

Die Schritte je Version

• Jeder Cloud-Shop, jetzt: Prüfen Sie die laufende Version jedes Dienstes in jeder Umgebung. Trifft etwas aus den Oktober-Zeilen zu oder betreiben Sie 2.4.4 oder 2.4.5, eröffnen Sie jetzt ein Support-Ticket. Fragen Sie, welche Termine für Sie gelten, wie viele Production-Fenster die Arbeit erfordert, und bitten Sie um eine Verlängerung, falls sich der 30. Oktober nicht einhalten lässt.
• 2.4.4 und 2.4.5: Aktualisieren Sie auf 2.4.9 oder migrieren Sie zu Adobes SaaS, und schließen Sie dies bis zum 31. Mai 2027 ab. Reichen Sie die Service-Tickets deutlich vor dem 1. Mai ein, denn das ist der letztmögliche Termin, kein Ausgangspunkt.
• 2.4.6: Beginnen Sie jetzt mit dem Upgrade auf 2.4.9, denn für PHP 8.2 enden Ende 2026 die Sicherheitsupdates.
• 2.4.7: Wechseln Sie zu PHP 8.3, das bis zum 31. Dezember 2027 Sicherheitsfixes erhält, und planen Sie das Upgrade auf 2.4.9 vor diesem Datum. Adobes Frist ist der 1. Juni 2028.
• 2.4.8 und 2.4.9: Prüfen Sie die Service-Tabelle oben. Eine Versionsfrist gibt es noch nicht. Der Standard-Support für 2.4.8 endet am 31. Mai 2028.
• Älter als 2.4.4: Aktualisieren Sie vor dem 1. Juni 2027 auf 2.4.9, und fragen Sie Adobe, ob die Oktober-Fristen für Sie gelten. Die OpenSearch-Unterstützung beginnt mit 2.4.4-p13, der Abschied von Elasticsearch erfordert also bereits ein Magento-Upgrade.

Wenn Sie Magento selbst hosten

Ein selbst gehosteter Shop wird aufgrund dieser Richtlinie nicht vom Netz genommen. Sie gilt nicht für Adobe Commerce on-premises, Magento Open Source oder Mage-OS. Für dieselbe Software endet dennoch der Support: Der Support von Elastic für Elasticsearch 7.17 endete laut der End-of-Life-Seite am 15. Januar 2026, und PHP 8.2 folgt Ende 2026. Unser Hosting-Beitrag zeigt, welche Hoster mit Adobes Anforderungen Schritt halten.

Die Alternative, die Adobe anbietet

Zu jeder Versionsfrist gibt es eine zweite Option: den Wechsel zu Adobe Commerce as a Cloud Service, den Adobe als „empfohlenes langfristiges Ziel“ für Cloud-Kunden bezeichnet. Adobes Migrationsübersicht macht deutlich, dass es sich um einen Neuaufbau handelt: Anpassungen werden zu App-Builder-Anwendungen, und Storefronts werden auf Edge Delivery Services neu aufgebaut. Das SaaS-Produkt unterstützt keine Luma-Storefronts. Für die meisten Shops ist das ein Replatforming-Projekt, und unser Beitrag zu Replatforming oder Reparatur zeigt, wie Sie es gegen ein Upgrade abwägen.

Genau diese Versions- und Service-Upgrades deckt unser Magento-Service ab.