Wann immer Adobe ein neues Magento-Sicherheits-Release ankündigt, beginnt für uns die eigentliche Arbeit – und zwar lange bevor der Patch deinen Shop berührt. Als Magento-Agentur sehen wir es als unsere Aufgabe, jeden neuen Patch sorgfältig zu analysieren, in einer Testumgebung zu prüfen und erst dann auf den Live-Shop zu übertragen, wenn wir sicher sind, dass nichts kippt. Genau das ist das Gegenteil von Hektik: strukturierte Arbeit im Hintergrund, die du als Shopbetreiber idealerweise gar nicht mitbekommst.
Trotzdem hören wir immer wieder die gleiche Geschichte: Ein Shopbetreiber liest ein Adobe-Security-Bulletin, googelt die CVE-Nummer und weiß nicht, ob er morgen früh schon panisch deployen soll. Diese Unsicherheit wollen wir dir abnehmen. In diesem Beitrag zeigen wir dir Schritt für Schritt, wie professionelles Patch-Management für Magento bei uns abläuft – damit du verstehst, was wir im Hintergrund tun, oder damit du es intern besser aufsetzen kannst.
Eines vorweg: Ein hängender Checkout nach einem überstürzten Patch kostet dich nicht nur einen Bestellabschluss, sondern Vertrauen, das du vorher monatelang aufgebaut hast. Genau deshalb deployen wir grundsätzlich nicht unter Zeitdruck, sondern nach einem klaren Plan.
Warum dieses Thema überhaupt brennt
Magento ist – das wissen wir beide – kein WordPress-Plugin, das du mal eben mit zwei Klicks aktualisierst. Es ist ein gewachsenes Ökosystem aus Core-Code, Drittanbieter-Modulen, individuellen Themes, ERP-Schnittstellen und Payment-Integrationen. Jedes dieser Zahnräder kann nach einem Patch knirschen. Adobe veröffentlicht im Schnitt vier bis fünf Sicherheits-Releases pro Jahr, dazu kommen die regelmäßigen Feature-Releases. Wer da manuell hinterherläuft, hat einen Fulltime-Job – und keine Zeit mehr, das eigentliche Business voranzutreiben.
Noch eine Ebene anspruchsvoller wird es, seit KI-Agenten beginnen, eigenständig in Shops einzukaufen. Sie greifen auf Produkt-APIs zu, vergleichen Optionen und treffen Kaufentscheidungen autonom. Ein Shop, der nach einem fehlerhaften Patch instabil läuft, wird von solchen Agenten schlicht übergangen. Menschen sind oft geduldig genug, einen 500er-Fehler beim zweiten Versuch zu verzeihen. Maschinen nicht.
Unsere Lektion: Übersicht schlägt Hektik
In den vergangenen Jahren haben wir aus etlichen Patch-Projekten ein paar Dinge gelernt – manchmal auf die harte Tour. Die wichtigste Erkenntnis: Manuelles Patchen unter Zeitdruck ist nicht “vorsichtig”, es ist Glücksspiel. Wer einen Patch innerhalb von Stunden raushaut, ohne ihn vorher in einer realistischen Umgebung gesehen zu haben, produziert genau die Inkompatibilitäten, die er eigentlich verhindern will.
Was uns wirklich Ruhe gebracht hat: Übersicht. Wir pflegen die exakte Magento-Version und den Patch-Status jedes Kundenshops zentral in unserem ERP. Sobald Adobe ein neues Release veröffentlicht, sehen wir auf einen Blick, welche Shops betroffen sind, welche bereits aktualisiert wurden und wo noch Bedarf besteht. Diese Transparenz hat unser Patch-Geschäft komplett verändert – aus reaktivem Feuerlöschen wurde planbare Arbeit.
Aus dieser Routine ist auch unser Patch-Service entstanden. Was wir dabei konkret tun – von der Patch-Analyse über die Vorbereitung bis zur Freigabe auf Staging – beschreiben wir in den folgenden Abschnitten.
Der Workflow, den wir dir wärmstens empfehlen
So sieht ein belastbares Patch-Management in der Praxis aus:
Schritt 1: Staging als Generalprobe
Eine Staging-Umgebung ist die Generalprobe vor dem Live-Auftritt. Idealerweise ist sie ein 1:1-Klon der Produktivumgebung – gleicher PHP-, MySQL- und OpenSearch-Stack, gleiche Modulversionen, gleiche Konfiguration. In der Realität ist das nicht immer perfekt machbar, aber je näher du diesem Ideal kommst, desto belastbarer sind deine Tests. Was du auf jeden Fall sicherstellen solltest: Staging wird automatisiert deployt, nicht per FTP mitten in der Nacht.
Ohne eine Staging-Umgebung ist sauberes Patch-Management schlicht nicht möglich. Das ist nicht unsere Meinung, das ist schlicht logisch: Du kannst nichts testen, wenn du nichts zum Testen hast.
Schritt 2: Patch analysieren und bewerten
Bevor wir auch nur eine Zeile Code verändern, lesen wir die Release-Notes von Adobe sorgfältig durch. Welche Magento-Komponenten sind betroffen? Welche Klassen werden modifiziert? Gibt es Hinweise auf Konflikte mit verbreiteten Drittanbieter-Modulen? Diese Einordnung machen wir manuell – sie ist nicht delegierbar, weil sie Erfahrung und Kontextwissen über den konkreten Shop voraussetzt.
In dieser Phase entscheiden wir auch, wie dringend das Update ist, ob es sofort eingespielt werden muss oder in den regulären Wartungszyklus passt. Bei einem Shop mit Hyvä-Frontend gelten andere Risiken als bei einem klassischen Luma-Theme; ein Multistore mit ERP-Anbindung braucht mehr Prüfaufwand als ein einfacher B2C-Shop.
Schritt 3: Patch vorbereiten und auf Staging einspielen
Wenn die Analyse durch ist, geht es in die technische Umsetzung. Wir legen einen dedizierten Git-Branch nach dem Schema patch-release-<Magento-Version> an und ziehen über Composer die neuen Versionen samt aller Abhängigkeiten. Hier zeigen sich oft die ersten Stolpersteine: Composer-Konflikte, deprecated APIs, geänderte Schnittstellen. Wir lösen diese im Vorfeld – nicht erst auf Live.
Anschließend deployen wir das vorbereitete Paket auf die Staging-Umgebung des Kunden. Auf Staging laufen unsere Smoke-Tests durch – Login, Warenkorb, Checkout, Kategorienavigation – und parallel klickt sich ein Entwickler durch die kritischen Workflows des konkreten Shops. Was bei dem einen Kunden ein wichtiger Test ist (etwa ein B2B-Quoting-Prozess), ist beim nächsten irrelevant. Diese manuelle Prüfung schaut sich keine Pipeline ab.
Schritt 4: Freigabe und produktives Deployment
Erst wenn die QS auf Staging vollständig ist und der Kunde freigegeben hat, deployen wir auf die Produktivumgebung. Bewusst manuell, bewusst zu einer abgestimmten Uhrzeit, idealerweise außerhalb der umsatzstärksten Stunden. Zwischen “alles grün” und “wirklich live gehen” sitzt immer ein Mensch, der einmal tief durchatmet. Verantwortung lässt sich nicht delegieren – schon gar nicht an einen Cronjob.
Schritt 5: Versions-Monitoring und Übersicht
Damit dieser ganze Prozess überhaupt früh genug anläuft, halten wir den Magento-Versionsstand und das jeweilige Patch-Level jedes Kundenshops in unserem ERP nach. Sobald Adobe ein relevantes Release veröffentlicht, sehen wir innerhalb von Minuten, welche Shops betroffen sind, welche bereits gepatcht wurden und wo Handlungsbedarf besteht. Diese Transparenz ist die Basis dafür, dass wir vorausschauend arbeiten können – und nicht nachträglich Feuer löschen.
Composer-Patches: Die Kunst des chirurgischen Eingriffs
Manchmal hast du das Problem, dass ein Drittanbieter-Modul einen Bug enthält, der dich blockiert – aber der Hersteller braucht noch Wochen für ein offizielles Update. Was tun? Den Code im vendor/-Verzeichnis direkt ändern? Bitte nicht, das überlebt das nächste composer install keine Minute.
Die saubere Antwort: ein Composer-Patch. Wir nutzen dafür entweder cweagen/composer-patches oder creativestyle/composer-plugin-patchset. Der Workflow:
- Fehler im
vendor/-Code finden und beheben. - Diff erzeugen und als
.patch-Datei inconfig/patches/<vendor>/<modul>/ablegen. - In der
composer.jsonunterextra.patchesden Patch referenzieren:
"extra": {
"magento-force": "override",
"composer-exit-on-patch-failure": true,
"patches": {
"vendor/extension-name": {
"fix-description": "config/patches/vendor/extension-name/fix.patch"
}
}
}Beim nächsten composer install wendet Composer den Patch automatisch an. Versions-Updates bleiben möglich, der Eingriff ist dokumentiert und beim Wegfall des Bugs einfach wieder entfernt. Elegant und nachvollziehbar.
Updates strukturiert nach Risiko bewerten
Nicht jedes Update hat dieselbe Dringlichkeit. So bewerten wir die Lage:
| Update-Typ | Beispiel | Reaktionszeit | Bemerkung |
|---|---|---|---|
| Critical Security Patch | hochkritisches CVE | binnen 1 Woche | Analyse + Test, dann Deployment |
| Standard Security Patch | reguläres Adobe-Release | binnen 2–4 Wochen | regulär in Wartungszyklus einplanen |
| Feature-Release | z. B. 2.4.8 | ab Patch-Level p3 | dann meist 3rd-Party-Kompatibilität gegeben |
| Major-Upgrade | 2.3.x → 2.4.x | als Migrationsprojekt | gesonderte Planung, Budget, Tests |
| Modul-Patch (Composer) | Drittanbieter-Fix | nach Bedarf | als chirurgischer Hotfix |
Besonders der Punkt mit den Feature-Releases verdient eine Erklärung: Wir installieren Major-Versionen wie 2.4.8 in der Regel nicht direkt nach Erscheinen, sondern warten ab p3. Erfahrungsgemäß sind dann die meisten Drittanbieter-Module nachgezogen und kompatibel. Wer früher upgraded, wird oft zum unbezahlten Beta-Tester für seine Extension-Anbieter. Das muss nicht sein.
Die zwei Hebel: Standard vs. Pro
Wir bieten unseren Update-Service in zwei Varianten an:
- Standard: Wir analysieren und spielen die Patches auf Staging ein, du übernimmst dort die Qualitätssicherung. Treten Fehler auf, beheben wir sie nach Aufwand und in enger Abstimmung mit dir.
- Pro: Wir gehen den vollen Weg – Analyse, Vorbereitung, eigene Smoke-Test-Runde auf Staging vor der Übergabe und ein fixes Stundenkontingent für Fehlerbehebung pro Patch. Du musst dich um nichts mehr kümmern als die finale Abnahme.
Welche Variante zu dir passt, hängt vor allem davon ab, wo dein Team seine Energie lieber investiert. Beides ist legitim. Den genauen Leistungsumfang findest du auf unserer Service-Seite zu Sicherheitsupdates & Patches.
Was du heute tun kannst – auch ohne uns
Falls du diesen Artikel liest und denkst: “Schön, aber wir machen das intern” – auch dann gibt es drei Dinge, die wir dir ehrlich ans Herz legen:
- Prüfe deine Staging-Umgebung. Wie nah ist sie wirklich an Live? Wann wurde sie zuletzt gespiegelt? Wenn die Antwort “vor Monaten” lautet, hast du gerade deine wichtigste Hausaufgabe gefunden.
- Dokumentiere deinen aktuellen Patch-Stand. Welche Magento-Version läuft? Welche Hot-Fixes sind manuell drin? Welche Composer-Patches existieren? Schreib es auf, bevor jemand kündigt, der das im Kopf hat.
- Definiere klare Verantwortlichkeiten. Wer entscheidet im Notfall über einen Rollback? Wer hat die Deploy-Rechte? Wer informiert den Kundensupport? Diese Fragen müssen vor dem nächsten Patch beantwortet sein, nicht währenddessen.
Diese drei Punkte kosten dich einen Nachmittag und können dir ein Wochenende voller Anrufe ersparen.
Ein letzter Gedanke zum Mitnehmen
Updates fühlen sich oft an wie Zahnarzttermine: ungeliebt, aber unverzichtbar. Wer sie aufschiebt, zahlt später drauf – mit Zinsen. Wir glauben: professionelles Patch-Management ist kein Premium-Feature für Konzerne, sondern Standard für jeden ernsthaft betriebenen Magento-Shop. Die Werkzeuge sind da, die Workflows sind erprobt – es braucht nur jemanden, der den ersten Schritt geht.
Wenn du unsicher bist, wie dein aktueller Stand wirklich aussieht: Sprich uns an. Wir machen mit dir gemeinsam eine ehrliche Bestandsaufnahme, ohne Verkaufsdruck und ohne erhobenen Zeigefinger. Manchmal reicht es schon, ein zweites Paar Augen draufzuhaben. Und wenn daraus mehr wird, freuen wir uns natürlich auch.
