Magento Wartung: Support-Fristen und Budget planen

Dieser Text soll Ihnen eine einfache Antwort geben: Wird Ihr Shop noch gepatcht. Danach zeigen wir, was daraus für die Kosten folgt, was Magento Shops wirklich lahmlegt und wie ein ehrliches Budget für die Betreuung aussieht. Wenn Sie danach selbst die Version prüfen und selbst über den nächsten Schritt entscheiden, hat der Text seine Aufgabe erfüllt.

Die Daten, mit denen alles beginnt

Die Lifecycle-Politik von Adobe Commerce ist einfach: drei Jahre Standard-Support ab dem GA-Datum, für einen Teil der Versionen zusätzlich ein erweiterter Support. Unten die Fristen, die heute zählen.

Wir haben September 2026, die Schlüsse fallen also kurz aus. Läuft Ihr Shop auf 2.4.5, sind Standard-Support und erweiterter Support abgelaufen (11.08.2026): keine neuen Sicherheitspatches, und jede öffentlich beschriebene Schwachstelle bleibt dauerhaft bei Ihnen. Auf 2.4.6 endete der Standard-Support am 11.08.2026, der erweiterte Support läuft aber bis zum 31.08.2027. Das ist Ihr Fenster für ein geplantes, ruhiges Magento Update, nicht für das Aufschieben des Themas.

Auf 2.4.7 oder 2.4.8 entscheiden Sie über den nächsten Schritt in Ruhe, rechtzeitig vor dem 31.05.2027 beziehungsweise dem 31.05.2028.

Eine eigene Sache ist Magento Open Source. Diese Edition hat keinen kommerziellen Support und keine eigenen, separat veröffentlichten Fristen. In der Praxis hängen Sie von Patches der Community ab und davon, ob jemand auf Ihrer Seite sie verfolgt und einspielt. Übertragen Sie die Daten aus der Tabelle nicht darauf, das Modell ist ein anderes.

Wie Sie in fünf Minuten prüfen, wo Sie stehen

Dafür brauchen Sie weder Dienstleister noch Audit. Drei Handgriffe genügen.

Erstens: das Admin-Panel. Die Versionsnummer steht nach dem Login in der Fußzeile, ein Ergebnis in fünfzehn Sekunden.

Zweitens: die Datei composer.json im Anwendungsverzeichnis, genauer composer.lock. Dort sehen Sie die Version des Kerns und alle Module von Drittanbietern samt Versionen. Ohne Serverzugang bitten Sie um eine Kopie dieser Datei. Eine Mail.

Drittens: eine Frage an Ihren Dienstleister, die sich nicht mit einer Allgemeinheit beantworten lässt. Welche Version läuft genau auf der Produktion, wann wurde zuletzt ein Sicherheitspatch eingespielt, wurde er vorher auf der Testumgebung geprüft. Eine Antwort ohne Versionsnummer und Datum ist keine Antwort.

Warum die Wartung von Magento mehr kostet als WooCommerce oder PrestaShop

Das ist keine Frage der Marge, sondern dreier technischer Unterschiede.

Infrastruktur. Neben der Anwendung stehen Dienste, die laufen und beaufsichtigt werden müssen: Suche, Cache-Schicht, Message Queues und der Cron-Scheduler. Bei WooCommerce ist eine Störung meist der Ausfall eines Prozesses. Bei Magento können mehrere Stellen stehen bleiben, unabhängig von der Seite, die der Kunde sieht.

Kompetenzen. Magento ist Arbeit für Entwickler, nicht für Content-Administratoren. Was anderswo ein Klick im Panel ist, bedeutet hier eine Änderung im Code, neue Indizes und ein Deployment. Der Stundensatz ist derselbe, aber der Kreis der Personen, die diese Stunde leisten können, ist deutlich enger.

Zeit bis zur Änderung. In Magento ändert man nichts auf der Produktion. Es gibt eine Testumgebung, ein Deployment-Verfahren und Regressionstests, denn eine Änderung in einem Modul kann den Warenkorb kippen. Dieselbe scheinbar kleine Korrektur kostet mehr Stunden als bei PrestaShop, und das überrascht bei der ersten Abrechnung am häufigsten. Ausführlich steht das im Beitrag darüber, was der Betrieb eines Onlineshops kostet.

Was Magento Shops wirklich lahmlegt

Fünf Dinge, die in unserer Praxis die meisten Tickets erzeugen: Symptom, Ursache und Größenordnung der Wiederherstellungszeit. Das ist eine Beobachtung aus der Arbeit, keine zugesagte Reparaturzeit, denn die Zeit bis zur Behebung einer Störung lässt sich vorab nicht seriös versprechen.

Gestoppte Queues und Crons. Das Symptom täuscht, der Shop wirkt gesund: Seiten öffnen sich, Bestellungen gehen ein, aber nichts erreicht das ERP, Transaktionsmails gehen nicht raus, Bestände bleiben stehen. Ursache ist oft ein abgestorbener Queue-Consumer oder ein nach dem Serverneustart abgeschalteter Scheduler. Größenordnung: von einigen zehn Minuten bis zu einigen Stunden, am längsten dauert das Aufarbeiten des Rückstaus.

Volle Festplatte und Logs. Symptom: Schreibfehler, das Panel reagiert nicht mehr. Die Ursache ist meist banal: Debug-Logging, beim Start aktiviert und nie abgeschaltet. Größenordnung: von einer Viertelstunde bis zu einer Stunde, sofern jemand den freien Speicher im Blick hat.

Neuindexierung und Cache nach dem Deployment. Symptom: Der Shop zeigt alte Preise, leere Kategorien oder ein zerschossenes Layout. Ursache sind nicht neu berechnete Indizes oder nicht neu gebaute statische Inhalte. Größenordnung: von einigen zehn Minuten bis zu einigen Stunden, je nach Katalogumfang.

Module von Drittanbietern ohne Kompatibilität zur Version. Das Symptom zeigt sich meist direkt nach dem Update: ein 500er Fehler in einem Schritt des Warenkorbs oder im Panel. Ursache ist ein Modul, das keine Kompatibilität zum neuen Kern erklärt. Größenordnung: von einigen Stunden bis zu einigen Tagen, weil Sie oft auf ein Release des Modulherstellers warten.

Zahlungsintegrationen. Symptom: Die Zahlung startet, es kommt kein Status zurück, die Bestellung bleibt offen. Ursache ist eine Änderung beim Anbieter, ein abgelaufenes Zertifikat oder ein Schlüssel. Größenordnung: von einigen zehn Minuten bis zu einigen Stunden, ein Teil davon außerhalb unseres Einflusses. Was ein solcher Ausfall in Geld kostet, steht im Beitrag über die Kosten eines Shop-Ausfalls.

Was die monatliche Betreuung eines Adobe Commerce Shops enthalten sollte

Das Minimum, das Sie von jedem Dienstleister verlangen sollten, auch von uns.

Sicherheitspatches in festem Regime. Bei uns gehen kritische Updates in 72 Stunden ein, die übrigen in 14 Tagen, immer zuerst auf der Testumgebung. Ohne diese letzte Bedingung ist schnelles Patchen ein Risiko und keine Leistung.

Monitoring dessen, was wirklich stehen bleiben kann. Die Startseite alle 60 Sekunden zu prüfen ist nötig und hier nicht ausreichend. Zu überwachen sind Queues, Crons und ob Ereignisse nach außen gehen, denn dort beginnen die stillen Störungen.

Backups mit Wiederherstellungstest. Ein Backup, das niemand zurückgespielt hat, ist eine Annahme und keine Absicherung. Im Basispaket sichern wir alle 7 Tage und testen die Wiederherstellung einmal im Quartal.

Durchsicht der Logs. Logs regelmäßig zu lesen ist langweilig und der einzige Weg, ein Problem vor dem Kunden zu sehen.

Budget: drei Shop-Profile

Profil eins: ein Shop auf 2.4.7 oder 2.4.8, wenige Integrationen, ein Katalog von einigen tausend Artikeln, selten beauftragte Änderungen. Realistisch ist das Paket Advanced für 440 EUR monatlich mit 20 Stunden, das reicht für Patches, kleine Änderungen und Tickets.

Profil zwei: ein Shop auf 2.4.6 vor dem Update, mit einem Dutzend Modulen von Drittanbietern und einer ERP-Integration. Hier sind 20 Stunden in dem Monat aufgebraucht, in dem das Update kommt. Realistisch ist das Paket Premium für 880 EUR monatlich mit 40 Stunden.

Profil drei: ein Shop auf 2.4.5, also außerhalb des Supports, mit eigenen Modulen. Bevor wir über ein Abo sprechen, brauchen Sie einen Ausstiegsplan aus dieser Version, denn monatliche Betreuung löst das Fehlen von Patches nicht.

Ein ehrlicher Vorbehalt: Ein Magento Shop passt selten in das Paket Basic für 220 EUR mit 10 Stunden. Zehn Stunden können hier in einem einzigen Deployment mit Regressionstests verschwinden. Wenn Ihnen jemand Magento für 220 EUR anbietet, fragen Sie, was nach dem Aufbrauchen des Kontingents passiert. Eine Stunde im Paket kostet bei uns 22 EUR, eine Stunde über das Kontingent hinaus 35 EUR.

Die Überwachung der Verfügbarkeit rechnen wir getrennt ab: Sie ist eine andere Leistung als ein Stundenkontingent für Ihre Aufträge. Die Stufe Standard beginnt bei 210 EUR. Bei Magento kommt meist die Stufe Erweitert für 550 EUR, und der Grund ist konkret: Zu überwachen ist nicht eine Adresse, sondern Queues, Crons und Hintergrundprozesse, und die Diagnose bei einem kritischen Ereignis braucht jemanden, der diese Plattform kennt. Durchgehende Bereitschaft 24/7 gibt es nur auf unserer höchsten SLA-Stufe. Den Unterschied zerlegen wir im Beitrag über technischen Support und SLA.

Update oder Migration auf eine andere Plattform

Diese Frage sollte man ehrlich stellen, besonders auf einer Version ohne Support. Wir überreden Sie nicht zur Migration: Der Weg weg von Magento ist teuer, lang und endet in der Hälfte der Fälle mit denselben Problemen an anderer Stelle. Stattdessen drei Kriterien.

Erstens: Rechnen Sie die Wartung auf ein Jahr, also Abo mal zwölf plus Stunden über dem Kontingent plus Hosting. Erst diese Zahl, nicht eine Rechnung für einen Monat, lässt sich vergleichen.

Zweitens: Prüfen Sie, wie viele Funktionen Ihres Shops wirklich speziell sind. Komplexe B2B-Preislisten, mehrere Lager und eine harte ERP-Integration heißen, dass Magento die Arbeit leistet, für die Sie zahlen. Ein einfacher Katalog mit Zahlung heißt, dass Sie für ungenutzte Möglichkeiten zahlen.

Drittens: Fragen Sie, ob Ihr Team mit dieser Plattform umgehen kann. Magento braucht auf Ihrer Seite jemanden, der den Unterschied zwischen Index und Cache kennt. Fehlt diese Person, wird jede Änderung nach Stunden eingekauft, und das ist ein realer Teil der Rechnung.

Fallen zwei der drei Kriterien für Magento aus, bleiben Sie und planen Sie das Update. Fällt keines aus, ist ein Gespräch über die Migration berechtigt, aber das ist ein eigenes Projekt und kein Nachtrag zum Wartungsvertrag.

Beginnen Sie mit einer Prüfung von Version und technischem Zustand. Wir sehen nach, auf welcher Version der Shop läuft, wann er zuletzt Patches bekommen hat, ob Queues und Crons laufen, und übergeben eine Liste der Aufgaben mit einer Schätzung in Stunden. Schreiben Sie über /de/sla-help-desk, und wir sagen Ihnen, ob in Ihrem Fall ein Stundenkontingent genügt oder auch die Überwachung der Verfügbarkeit nötig ist.