Kann ich Versionen überspringen, zum Beispiel von 2.4.4 direkt auf 2.4.8?

Technisch gesehen ja, aber ich empfehle es nicht. Ein grosses Versions-Delta erhöht die Wahrscheinlichkeit von Konflikten mit Vendor-Modulen, die Zwischenschritte erfordern. Es ist sicherer, schrittweise über 2.4.6 oder 2.4.7 zu upgraden, damit Konflikte kleiner und besser isolierbar sind.

Hilft eine Hyvä-Migration beim Upgraden?

Hyvä ersetzt das Luma/RequireJS-Frontend durch einen React-basierten Stack und reduziert damit die Abhängigkeit von Magento's Frontend-JavaScript-Komplexität. Das kann zukünftige Upgrades auf Frontend-Ebene einfacher machen. Aber das Core-Upgrade selbst, die Datenbankschema-Updates und Vendor-Module sind unabhängig vom Theme. Eine Hyvä-Migration löst keine Composer-Konflikte.

Übernimmst du auch das PHP-Upgrade im selben Projekt?

Ja. Magento 2.4.7 erfordert PHP 8.2 oder 8.3. Wenn das Upgrade einen PHP-Versions-Sprung beinhaltet, nehme ich das in dasselbe Projekt auf. Ein PHP-Upgrade und Magento-Upgrade in demselben Deploy ist riskant, wenn man sie nicht zusammen testet. Ich teste immer die Kombination auf Staging vor Produktion.

Kann ich Downtime vermeiden?

Ja, in den meisten Fällen. Ein Patch-Upgrade mit der richtigen Vorbereitung hat keine sichtbare Downtime für Besucher. Der Cache-Flush nach dem Deploy führt zu einer kurzen Phase höherer Last durch Cache-Warming, aber der Shop ist erreichbar. Für ein Major-Versions-Upgrade mit Datenbankmigrationen ist manchmal ein kurzer Wartungsmodus notwendig, abhängig von der Datenbankgröße und der Komplexität der Schema-Änderungen.

Arbeitest du mit den Magento DevDocs Deprecation Reports?

Ja. Die Magento DevDocs enthalten pro Release eine Liste veralteter Klassen und Methoden. Ich prüfe benutzerdefinierte Module und Theme-Anpassungen systematisch gegen diese Liste vor dem Upgrade. So weiß ich vor dem Deploy, welche Anpassungen notwendig sind, und nichts entgeht mir beim Compile-Schritt.

Können wir das auf Produktion ohne Dev-Klon machen?

Nein. Ich führe kein Upgrade auf Produktion durch, ohne dass der gesamte Prozess zuerst auf einer Staging-Umgebung mit einer Produktionsdatenbank-Kopie durchgelaufen ist. Ein Upgrade, das auf Staging scheitert, führt zu einer behebbaren Situation. Ein Upgrade, das auf Produktion scheitert, führt zu einem P1 mit direkten Auswirkungen auf Besucher und Umsatz.

Magento 2 Upgrades ohne Downtime

Warum Upgrades nicht optional sind

Adobe veröffentlicht quartalsweise Sicherheits-Patches für Magento 2. Ein Patch auf Version 2.4.6-p14 schließt beispielsweise bekannte Schwachstellen in Admin und Checkout. Ein Shop, der auf 2.4.4 oder 2.4.5 bleibt, verpasst diese Patches und ist bekannten Exploits ausgesetzt, die aktiv eingesetzt werden.

2.4.4 End-of-Life: keine Sicherheits-Patches mehr nach April 2026. Jeder Tag danach ist eine ungeschützte Schwachstelle.
PHP-Version EOL: PHP 8.1 erhält keine Sicherheitsupdates mehr. Magento 2.4.7 erfordert PHP 8.2 oder 8.3. Das PHP-Upgrade ist fast immer Teil desselben Projekts.
Vendor-Module: Erweiterungen von Drittanbietern folgen ihrem eigenen Release-Zeitplan. Ein Modul, das mit 2.4.5 kompatibel ist, funktioniert manchmal nicht mehr auf 2.4.7 ohne Update oder Patch.
Adobe Commerce Roadmap: neue Funktionen wie der verbesserte Checkout und GraphQL-Verbesserungen sind nur in aktuellen Versionen verfügbar. Auf einer veralteten Version zu bleiben bedeutet, bei der Funktionalität zurückzubleiben.
Composer-Abhängigkeiten: eine veraltete Version zieht eine Kette veralteter Pakete mit. Je länger man wartet, desto größer das Delta beim nächsten Upgrade.

Das Risiko des Nicht-Upgrades wächst mit der Zeit. Von 2.4.6 auf 2.4.7 ist ein kontrollierter Schritt. Von 2.4.4 auf 2.4.8 ist ein viel größeres Delta mit mehr Konflikten.

Wie ich ein Upgrade angehe

Ein Upgrade auf einem Produktions-Magento-Shop erfordert Vorbereitung. Ich arbeite immer mit einem Dev-Klon des Produktions-Shops, bevor sich auf Produktion etwas ändert.

Dev-Klon einrichten: Produktionsdatenbank exportieren, auf Staging importieren, .env anpassen. Alles, was ich tue, teste ich zuerst hier.
Composer-Auflösung: das Core-Upgrade über composer require ausführen und dann die Konflikte pro Erweiterung durcharbeiten. Mit 328 Modulen auf CarCare24 bedeutet das manchmal 15 bis 20 manuelle Konflikte aufzulösen.
Vendor-Modul-Updates: jede Erweiterung, die eine neue Version für Kompatibilität benötigt, update ich separat. Manchmal ist ein Composer-Patch die vorübergehende Lösung, wenn der Erweiterungsanbieter noch keine kompatible Version veröffentlicht hat.
di:compile + static-content:deploy: nach jeder wesentlichen Änderung ein vollständiger Compile- und Deploy-Zyklus. Ohne static-content:deploy gibt der Shop HTTP 500 mit 'Unable to retrieve deployment version'.
Smoke-Test auf 6 Routen: Homepage, Kategorie-Seite, Produkt-Seite, Suchergebnisse, Checkout, Bestätigungs-Seite. Das sind die kritischen Pfade. Alles muss funktionieren, bevor ich den Schritt zur Produktion erwäge.
Rollback-Strategie: vor jedem Produktions-Upgrade bereite ich einen Datenbank-Snapshot vor und notiere den genauen composer.lock-Stand. Bei einem P1-Problem innerhalb von 24 Stunden kann ich zurückrollen.

Auf Produktion arbeite ich bevorzugt außerhalb der Spitzenlastzeiten. Der Cache-Flush nach dem Deploy führt zu einer kurzen Phase höherer Last durch Cache-Warming. Das ist normal und akzeptabel. Tatsächliche Downtime ist nicht akzeptabel.

Die 4 Deploy-Schritte, die immer zählen

Nach jeder Code-Änderung auf einer Magento 2-Installation im Produktionsmodus sind diese 4 Schritte obligatorisch, in dieser Reihenfolge:

1.
bin/magento setup:upgradeDatenbankschema aktualisieren, neue Modul-Konfigurationen registrieren.
2.
bin/magento setup:di:compileDependency-Injection-Code regenerieren. Fehlt eine Klasse, folgt zur Laufzeit ein 500-Fehler.
3.
bin/magento setup:static-content:deploy -fRegeneriert deployed_version.txt. Ohne diesen Schritt gibt jede Seite HTTP 500 mit 'Unable to retrieve deployment version'. Das ist der Schritt, der am häufigsten vergessen wird.
4.
bin/magento cache:flushCache leeren, damit der neue Code für Besucher aktiv wird.

Bei Shops mit einem SRI-Hashes-Modul: Schritt 3 mit --jobs=1 ausführen. Parallele Jobs erzeugen eine Race-Condition, die die sri-hashes.json korrumpiert.

Risiken, die ich kenne und adressiere

Nicht jedes Upgrade verläuft reibungslos. Das sind die Probleme, die ich auf einer Produktionsumgebung mit 328 Modulen erlebt habe und lösen kann:

Knockout.js-Kompatibilitätsbrüche: Magento 2.4.7 enthält Updates an den KO-Komponenten für Checkout und Mini-Cart. Custom Templates, die KO-Bindings verwenden, müssen auf veraltete Syntax geprüft werden.
Drittanbieter-Modul-Brüche: eine nicht gewartete Erweiterung kann nach einem Core-Upgrade aufhören zu funktionieren. Ich prüfe jede Erweiterung gegen die Magento Marketplace Kompatibilitäts-Matrix und finde den richtigen Patch oder das Update.
Custom-Theme-JavaScript-Regressionen: Custom-JS, das mit RequireJS-Modulen oder dem neuen Checkout-Flow interferiert. Ich teste allen benutzerdefinierten Frontend-Code gegen die Upgrade-Version.
SRI-Hashes Race Conditions: das sri-hashes Modul generiert ein Manifest beim static-content:deploy. Bei parallelen Jobs kann das Manifest korrumpieren und Frontend-Ressourcen blockieren. Das habe ich live auf Wave 9 erlebt.
MagePack-Rollback: nach einem Upgrade kann eine bestehende MagePack-Bundling-Konfiguration veraltet sein und größere Bundles produzieren als Standard-RequireJS-Loading. Dann setze ich die Bundle-Konfiguration zurück und baue neu.
Plumrocket Cookie-Blocking-Regressionen: Cookie-Consent-Module, die den Consent-Flow nach einem Upgrade erneut blockieren, weil Scripts durch Reihenfolgeänderungen in layout-XML wieder render-blockierend geworden sind.

Diese Probleme sind lösbar. Der Unterschied ist, dass ich sie erkenne, bevor sie auf Produktion zu einem P1 werden.

Upgrade-Fallstudie

CarCare24: Patch p14 auf p15 mit MagePack-Rollback

CarCare24 betreibt Magento 2.4.6 auf Hypernode mit Cloudflare. Die Produktionsplattform hat 328 Module, darunter M2EPro für Marketplace-Sync, Plumrocket Cookie-Consent und ein benutzerdefiniertes SRI-Hashes-Modul. Am 15. Mai 2026 führte ich das Patch-Upgrade von p14 auf p15 durch.

Nach dem Patch-Deploy lief das Frontend zunächst stabil. Nach 2 Stunden stellte sich heraus, dass MagePack eine veraltete Bundle-Konfiguration geladen hatte, die größere JS-Bundles produzierte als vor dem Patch. Der LCP auf Mobil stieg messbar an. Ich rollte MagePack auf Standard-RequireJS-Bundling zurück und führte eine Neuinstallation der Bundle-Konfiguration durch. Plumrocket hatte zudem eine Cookie-Blocking-Regression, bei der Scripts erneut render-blockierend wurden. Diese Behebung erforderte eine Anpassung in der layout-XML.

328

Module auf Produktion

p14 bis p15

Patch-Version

2h nach Deploy

MagePack-Rollback

Nach dem MagePack-Rollback und der Plumrocket-Behebung befand sich der Shop wieder auf dem Leistungsniveau von vor dem Patch. Die Gesamtauswirkung auf Besucher war auf den 2-Stunden-Zeitraum begrenzt. Rollback-Strategie und Monitoring sind bei Shops mit dieser Modulanzahl kein überflüssiger Luxus.

Was ich nicht mache

Es gibt Projekte, von denen ich abrate und die ich selbst nicht durchführe:

Major Adobe Commerce Upgrade ohne Lizenz-Check: ein Upgrade auf Adobe Commerce Enterprise erfordert eine Lizenz. Ich führe dieses Upgrade nicht durch, ohne dass die Lizenzsituation geklärt ist.
Theme-Versions-Upgrades ohne Custom-Mod-Assessment: ein Theme-Update überschreibt benutzerdefinierte Anpassungen. Ich erfasse immer zuerst, welche benutzerdefinierten Änderungen in den Theme-Dateien stecken, bevor ich ein Theme-Update empfehle.
Vendor-Modul-Ersatz ohne Feature-Parity-Check: wenn eine Erweiterung durch eine Alternative ersetzt wird, prüfe ich zuerst, ob alle vom Shop genutzten Funktionen auch in der Alternative verfügbar sind.
Upgrade auf Produktion ohne Staging-Test: keine Code-Änderung auf Produktion, ohne dass sie zuerst auf Staging gelaufen ist. Das ist keine Empfehlung, sondern eine harte Regel.
Major-Versions-Upgrade überspringen: von 2.4.4 direkt auf 2.4.8 zu gehen ist technisch möglich, erhöht aber das Risiko unerwarteter Konflikte erheblich. Ich empfehle schrittweise Upgrades über Zwischenversionen.

Umfang und Preis

Der Preis eines Upgrade-Projekts hängt von der Anzahl der Module, dem Vorhandensein von benutzerdefinierten Modulen oder Theme-Anpassungen, der Größe des PHP-Versions-Sprungs und der Verfügbarkeit einer Staging-Umgebung ab.

Ich arbeite nicht mit festen Upgrade-Paketen. Ein Shop mit 20 Standard-Marketplace-Erweiterungen auf Hypernode hat einen anderen Umfang als ein Shop mit 328 Modulen, von denen ein Teil benutzerdefiniert ist. Preise sind immer auf Anfrage, nach einer kurzen Bestandsaufnahme des aktuellen Stacks.