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

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

Hilft eine Hyvaee-Migration beim Upgraden?

Hyvaee ersetzt das Luma/RequireJS-Frontend durch einen React-basierten Stack und reduziert damit die Abhaengigkeit von Magento's Frontend-JavaScript-Komplexitaet. Das kann zukuenftige Upgrades auf Frontend-Ebene einfacher machen. Aber das Core-Upgrade selbst, die Datenbankschema-Updates und Vendor-Module sind unabhaengig vom Theme. Eine Hyvaee-Migration loest keine Composer-Konflikte.

Uebernehmen Sie 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 Faellen. Ein Patch-Upgrade mit der richtigen Vorbereitung hat keine sichtbare Downtime fuer Besucher. Der Cache-Flush nach dem Deploy fuehrt zu einer kurzen Phase hoeherer Last durch Cache-Warming, aber der Shop ist erreichbar. Fuer ein Major-Versions-Upgrade mit Datenbankmigrationen ist manchmal ein kurzer Wartungsmodus notwendig, abhaengig von der Datenbankgroesse und der Komplexitaet der Schema-Aenderungen.

Arbeiten Sie mit den Magento DevDocs Deprecation Reports?

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

Koennen wir das auf Produktion ohne Dev-Klon machen?

Nein. Ich fuehre 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, fuehrt zu einer behebbaren Situation. Ein Upgrade, das auf Produktion scheitert, fuehrt zu einem P1 mit direkten Auswirkungen auf Besucher und Umsatz.

Magento 2 Upgrades ohne Downtime

Warum Upgrades nicht optional sind

Adobe veroeffentlicht quartalsweise Sicherheits-Patches fuer Magento 2. Ein Patch auf Version 2.4.6-p14 schliesst 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 ungeschuetzte Schwachstelle.
▸PHP-Version EOL: PHP 8.1 erhaelt 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 verfuegbar. Auf einer veralteten Version zu bleiben bedeutet, bei der Funktionalitaet zurueckzubleiben.
▸Composer-Abhaengigkeiten: eine veraltete Version zieht eine Kette veralteter Pakete mit. Je laenger man wartet, desto groesser das Delta beim naechsten Upgrade.

Das Risiko des Nicht-Upgrades waechst 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 groesseres 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 aendert.

▸Dev-Klon einrichten: Produktionsdatenbank exportieren, auf Staging importieren, .env anpassen. Alles, was ich tue, teste ich zuerst hier.
▸Composer-Aufloesung: das Core-Upgrade ueber composer require ausfuehren und dann die Konflikte pro Erweiterung durcharbeiten. Mit 328 Modulen auf CarCare24 bedeutet das manchmal 15 bis 20 manuelle Konflikte aufzuloesen.
▸Vendor-Modul-Updates: jede Erweiterung, die eine neue Version fuer Kompatibilitaet benoetigt, update ich separat. Manchmal ist ein Composer-Patch die vorruebergehende Loesung, wenn der Erweiterungsanbieter noch keine kompatible Version veroeffentlicht hat.
▸di:compile + static-content:deploy: nach jeder wesentlichen Aenderung ein vollstaendiger 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, Bestaetigungs-Seite. Das sind die kritischen Pfade. Alles muss funktionieren, bevor ich den Schritt zur Produktion erwaege.
▸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 zurueckrollen.

Auf Produktion arbeite ich bevorzugt ausserhalb der Spitzenlastzeiten. Der Cache-Flush nach dem Deploy fuehrt zu einer kurzen Phase hoeherer Last durch Cache-Warming. Das ist normal und akzeptabel. Tatsaechliche Downtime ist nicht akzeptabel.

Die 4 Deploy-Schritte, die immer zaehlen

Nach jeder Code-Aenderung 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 haeufigsten vergessen wird.
4.
bin/magento cache:flushCache leeren, damit der neue Code fuer Besucher aktiv wird.

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

Risiken, die ich kenne und adressiere

Nicht jedes Upgrade verlaeuft reibungslos. Das sind die Probleme, die ich auf einer Produktionsumgebung mit 328 Modulen erlebt habe und loesen kann:

▸Knockout.js-Kompatibilitaetsbrueche: Magento 2.4.7 enthaelt Updates an den KO-Komponenten fuer Checkout und Mini-Cart. Custom Templates, die KO-Bindings verwenden, muessen auf veraltete Syntax geprueft werden.
▸Drittanbieter-Modul-Brueche: eine nicht gewartete Erweiterung kann nach einem Core-Upgrade aufhoeren zu funktionieren. Ich pruefe jede Erweiterung gegen die Magento Marketplace Kompatibilitaets-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 groessere Bundles produzieren als Standard-RequireJS-Loading. Dann setze ich die Bundle-Konfiguration zurueck und baue neu.
▸Plumrocket Cookie-Blocking-Regressionen: Cookie-Consent-Module, die den Consent-Flow nach einem Upgrade erneut blockieren, weil Scripts durch Reihenfolgeaenderungen in layout-XML wieder render-blockierend geworden sind.

Diese Probleme sind loesbar. 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 fuer Marketplace-Sync, Plumrocket Cookie-Consent und ein benutzerdefiniertes SRI-Hashes-Modul. Am 15. Mai 2026 fuerhrte ich das Patch-Upgrade von p14 auf p15 durch.

Nach dem Patch-Deploy lief das Frontend zunaechst stabil. Nach 2 Stunden stellte sich heraus, dass MagePack eine veraltete Bundle-Konfiguration geladen hatte, die groessere JS-Bundles produzierte als vor dem Patch. Der LCP auf Mobil stieg messbar an. Ich rollte MagePack auf Standard-RequireJS-Bundling zurueck und fuehrte 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 ueberfluessiger Luxus.

Was ich nicht mache

Es gibt Projekte, von denen ich abrate und die ich selbst nicht durchfuehre:

✕Major Adobe Commerce Upgrade ohne Lizenz-Check: ein Upgrade auf Adobe Commerce Enterprise erfordert eine Lizenz. Ich fuehre dieses Upgrade nicht durch, ohne dass die Lizenzsituation geklaert ist.
✕Theme-Versions-Upgrades ohne Custom-Mod-Assessment: ein Theme-Update ueberschreibt benutzerdefinierte Anpassungen. Ich erfasse immer zuerst, welche benutzerdefinierten Aenderungen 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, pruefe ich zuerst, ob alle vom Shop genutzten Funktionen auch in der Alternative verfuegbar sind.
✕Upgrade auf Produktion ohne Staging-Test: keine Code-Aenderung auf Produktion, ohne dass sie zuerst auf Staging gelaufen ist. Das ist keine Empfehlung, sondern eine harte Regel.
✕Major-Versions-Upgrade ueberspringen: von 2.4.4 direkt auf 2.4.8 zu gehen ist technisch moeglich, erhoet aber das Risiko unerwarteter Konflikte erheblich. Ich empfehle schrittweise Upgrades ueber Zwischenversionen.

Umfang und Preis

Der Preis eines Upgrade-Projekts haengt von der Anzahl der Module, dem Vorhandensein von benutzerdefinierten Modulen oder Theme-Anpassungen, der Groesse des PHP-Versions-Sprungs und der Verfuegbarkeit 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.