Was kostet Shop-Wartung? Die Aufwandstreiber im Überblick

Wer ein Wartungsangebot einholt, bekommt meist einen Monatsbetrag. Dahinter steht Arbeit, deren Menge der Anbieter vorab abschätzen muss: Wie viele Updates fallen an, wie lange dauert der Test, wie oft muss jemand eingreifen, ohne dass es geplant war? Für zwei Shops mit gleichem Umsatz kann die Antwort weit auseinanderliegen. Ob ein Vertrag als Pauschale oder nach Stunden abgerechnet wird und welche Leistungen hineingehören, beschreibt der Beitrag Wartungsvertrag: Wichtigste Inhalte. Hier geht es eine Stufe davor um die Frage, welche Menge an Arbeit eine Pauschale überhaupt abdecken muss und woran diese Menge wächst.

Den Kern benennt der Hersteller für große Updates selbst: Der Aufwand für die Anpassung hängt vom Grad der individuellen Anpassung des Shops und von der Zahl der eingesetzten Erweiterungen ab (Shopware). Ein Shop mit Standardtheme und wenigen Erweiterungen aus dem Store braucht nach einem Update vor allem einen Funktionstest. Ein Shop mit eigenem Theme, selbst geschriebenen Plugins und mehreren angebundenen Systemen braucht für dasselbe Update eine Prüfung jeder Stelle, an der eigener Code auf den Kern trifft. Der Monatsbetrag spiegelt diesen Unterschied, ob er offen ausgewiesen wird oder nicht.

Die Arbeit lässt sich in fünf Bausteine teilen, und jeder hat eigene Treiber. Manche liegen außerhalb Ihres Einflusses, etwa der Updatetakt des Shopsystems und der Skriptsprache PHP. Andere bestimmen Sie selbst: wie viele Erweiterungen laufen, wie viel eigener Code im Shop steckt, wie viele Schnittstellen gepflegt werden und wie schnell im Störungsfall jemand reagieren soll. Wer diese Treiber kennt, kann ein Angebot lesen und ein Budget begründen.

Den ersten Treiber setzt der Hersteller. Für selbst gehostete Shops und PaaS-Installationen gilt bei Shopware: Minor-Releases erscheinen monatlich, und zwar jeden ersten Montag im Monat (Shopware). Hauptversionen mit tieferen Änderungen kommen einmal im Jahr, Patch-Releases nach Bedarf und ohne Vorankündigung (Shopware). Damit sind zwölf Minor-Releases im Jahr gesetzt, bevor ein einziger Patch dazukommt.

Wie dicht dieser Takt in der Praxis ist, zeigt die Liste der Release Notes. Zwischen der Hauptversion 6.7.0.0 vom 17. Juni 2025 und der Fassung 6.7.15.1 vom 7. Oktober 2026 sind in der Reihe 6.7 insgesamt 40 Fassungen erschienen: eine Hauptversion, 15 Minor-Releases und 24 Patch-Releases (Shopware). Jede davon verlangt eine Entscheidung: einspielen und testen, gebündelt mit der nächsten Fassung einspielen oder bewusst auslassen und den Grund festhalten.

Für Minor- und Patch-Updates gibt der Hersteller eine nüchterne Einordnung: Sie verlangen Tests, bringen aber in der Regel keine Änderungen, die bestehenden Code brechen (Shopware). Damit ist der Kostenblock benannt. Nicht das Update selbst kostet Zeit, sondern der Test danach. Je kleiner die einzelne Fassung, desto größer ist der Anteil des Tests am Gesamtaufwand und desto stärker zahlt sich eine automatisierte Prüfung der umsatzkritischen Abläufe aus. Wie solche Tests aufgebaut werden, zeigt der Beitrag zu Update-Tests und Regressionen.

Auch eine ältere Hauptversion steht nicht still. Die letzte Minor-Fassung einer Reihe erhält nach dem Erscheinen der nächsten Hauptversion erweiterten Support mit ausgewählten Fehlerkorrekturen und Sicherheitsupdates (Shopware). In der Reihe 6.6 folgten auf die Fassung 6.6.10.0 noch 29 weitere Patch-Releases bis 6.6.10.29 (Shopware). Wer auf einer älteren Reihe bleibt, spart den Sprung, aber nicht den Takt.

Neben dem Shopsystem setzen weitere Fristen die Grundlast. TLS-Zertifikate, die seit dem 15. März 2026 ausgestellt werden, dürfen höchstens 200 Tage gültig sein; ab dem 15. März 2027 sinkt die Grenze auf 100 Tage (CA/Browser Forum). Ab dann ist jedes Zertifikat spätestens nach 100 Tagen zu erneuern, und jede Erneuerung muss funktionieren, auch auf Domains für Bilder, Schnittstellen oder Testsysteme. Das bleibt ein kleiner Posten, solange die Erneuerung automatisch läuft und überwacht wird.

Eigenentwicklung heißt im Shop: selbst geschriebene Plugins, ein eigenes Theme, überschriebene Vorlagen in Storefront und Mails, eigene Regeln und Abläufe. Für diesen Code gibt es keinen Anbieter, der ihn an neue Fassungen anpasst. Das übernimmt die Wartung oder niemand. Shopware versteht unter Breaking Changes Änderungen, nach denen Entwickler bestehenden Code anpassen müssen, damit er kompatibel bleibt (Shopware). Solche Änderungen kommen vor allem mit der jährlichen Hauptversion.

Vorher kündigt der Hersteller sie an. Als veraltet markierte Funktionen arbeiten in der laufenden Fassung weiter, sind aber zum Entfernen in späteren Releases vorgesehen (Shopware). Für eigenen Code ist jede dieser Markierungen eine Aufgabe auf der Liste vor dem nächsten Sprung. Wer sie im laufenden Jahr abarbeitet, verteilt den Aufwand auf viele kleine Schritte. Wer sie liegen lässt, sammelt sie für das Upgrade an.

Ein unterschätzter Teil der Eigenentwicklung sind überschriebene Vorlagen. Ein Theme, das einzelne Blöcke der Storefront ersetzt, und eigene Mailvorlagen bekommen Verbesserungen des Kerns nicht automatisch mit. Nach einem Update muss jemand vergleichen, ob sich an der Originalvorlage etwas geändert hat, das in der eigenen Fassung fehlt. Der Aufwand steigt mit der Zahl der überschriebenen Stellen, nicht mit ihrer Größe.

Messbar wird der Treiber über drei Größen aus dem eigenen Bestand: die Zahl der eigenen Plugins, die Zahl der überschriebenen Vorlagen und den Anteil der Abläufe, die ein automatisierter Test abdeckt. Je höher der Testanteil, desto weniger kostet das einzelne Release, weil die Prüfung nicht jedes Mal von Hand wiederholt werden muss. Eine tragfähige Update-Strategie für Shopware trennt deshalb von Anfang an zwischen Kern, Erweiterungen und eigenem Code.

Die Reaktionszeit ist der Treiber, den Sie am direktesten wählen, und der, der den Preis am deutlichsten verschiebt. Eine Zusage rund um die Uhr verlangt, dass nachts, am Wochenende und an Feiertagen jemand erreichbar ist, der den Shop kennt. Eine Erstreaktion an Werktagen verlangt das nicht. Wichtig ist der Unterschied zwischen Reaktion und Lösung: Die Reaktionszeit sagt, wann jemand die Arbeit aufnimmt, nicht, wann der Fehler behoben ist. Was eine solche Zusage praktisch bedeutet, erklärt der Beitrag Reaktionszeit-SLA: Was guter Notfall-Support kann.

In unseren Stufen zeigt sich der Treiber direkt im Preis. Der Basis-SLA kostet 199 € netto im Monat mit Reaktion in der Servicezeit Mo–Fr 9–18 Uhr, der Business-SLA 349 € mit priorisierter Reaktion, der Enterprise-SLA 699 € mit höchster Priorität, jeweils innerhalb der Servicezeit; die Reaktionszeiten legt Ihr Angebot fest. Alle Preise verstehen sich netto zuzüglich Umsatzsteuer bei einer Mindestlaufzeit von 6 Monaten, danach monatlich kündbar; Preisstand ist September 2026 (Preisübersicht). Updates, Monitoring, Backups und Monatsbericht sind in jeder Stufe enthalten. Der Preisunterschied liegt in Priorität, Reaktionszeit und Updatetakt, nicht in der Größe des Sortiments.

Welche Stufe passt, hängt weniger von der Größe des Shops ab als von der Frage, wann der Umsatz entsteht und was eine Stunde Stillstand kostet. Ein Shop, der viele Bestellungen abends und am Wochenende erhält, braucht dort Bereitschaft. Ein B2B-Shop mit Bestellungen zu Bürozeiten kommt mit einer Werktagszusage aus, wenn die Überwachung auch nachts meldet. Wie sich der Wert einer Ausfallstunde ermitteln lässt, zeigt der Beitrag zu Ausfallkosten eines Shops; die Stufen im Einzelnen, alle mit Reaktion in der Servicezeit Mo–Fr 9–18 Uhr, stehen auf der Seite SLA-Wartungsvertrag.

Der teuerste Einzelposten der Wartung ist selten ein Notfall, sondern die nächste Hauptversion. Shopware veröffentlicht sie einmal im Jahr, begleitet von einem Release Candidate, der in der Regel rund zwei Monate vorher erscheint (Shopware). Die Supportphasen folgen keinem festen Kalender: Supportwechsel sind an Major-Releases gebunden, nicht an feste Zeitpläne (Shopware). Die Rücklage sollte deshalb über das Jahr aufgebaut werden, nicht im Monat des Upgrades.

Wie groß sie sein muss, hängt an denselben Treibern wie die Grundwartung, nur stärker: Jede Erweiterung braucht eine Fassung für die neue Hauptversion, jedes eigene Plugin eine Anpassung, jede Schnittstelle einen vollständigen Test. In unserer Preisstruktur ist das Major-Upgrade darum nicht Teil der Monatspauschale, sondern ein Festpreis nach Analyse, dessen Umfang von Ausgangsversion und Erweiterungen abhängt. Das macht den Posten planbar, sobald die Analyse vorliegt, und hält ihn aus dem Monatsbetrag heraus.

Zur Rücklage gehört 2027 auch die Skriptsprache. Jeder PHP-Zweig erhält zwei Jahre aktive Unterstützung (The PHP Group) und danach zwei weitere Jahre nur Korrekturen für kritische Sicherheitslücken (The PHP Group). Shopware setzt mindestens PHP 8.2 voraus und empfiehlt PHP 8.4 (Shopware). Für PHP 8.2 enden die Sicherheitsupdates am 31. Dezember 2026 (The PHP Group); am selben Tag endet die aktive Unterstützung von PHP 8.4, das danach bis zum 31. Dezember 2028 Sicherheitskorrekturen erhält (The PHP Group). Ein Wechsel betrifft Server, Kern und jede Erweiterung und braucht einen eigenen Testlauf. Den Ablauf beschreibt der Beitrag zum PHP-EOL-Management.

Ein Aufschub ist möglich, aber nicht kostenlos. Das Sicherheits-Plugin soll ausdrücklich die Zeit bis zu einem regulären Update überbrücken (Shopware), und eine ältere Reihe erhält im erweiterten Support nur ausgewählte Korrekturen. Wer den Sprung verschiebt, verschiebt die Rücklage ins nächste Jahr und vergrößert sie meist, weil sich veraltete Funktionen und alte Fassungen von Erweiterungen weiter ansammeln.

Aus den Treibern wird eine Zahl, wenn Sie sie in einer festen Reihenfolge erfassen. Die folgenden Schritte lassen sich im November erledigen und liefern eine Grundlage, die ein Angebot nachvollziehbar macht.

Ein Wartungsangebot lässt sich danach an wenigen Fragen messen. Sie zeigen, ob der Anbieter die Treiber Ihres Shops kennt oder nur einen Durchschnitt anbietet: