Aktualisiert mein Hoster auch den Shop?

In der Regel nicht. Der Hoster pflegt Server, Betriebssystem und die bereitgestellten Versionen von PHP und Datenbank. Shop-Kern, Erweiterungen, Theme und Individualcode stehen in üblichen Hosting-Verträgen nicht in der Leistungsbeschreibung. Ob Ihr Tarif eine Ausnahme ist, zeigt nur die Leistungsbeschreibung selbst, nicht der Produktname.

Reicht die Firewall des Hosters als Schutz gegen Lücken in Erweiterungen?

Sie ist eine sinnvolle erste Schicht, ersetzt das Update aber nicht. In einem Pentest bei Hosting-Anbietern wurden nur **26 %** (Patchstack) der Angriffe auf Schwachstellen geblockt; die Daten stammen aus dem WordPress-Ökosystem und dienen für Shopware als Analogie. Geschlossen ist eine Lücke erst, wenn die betroffene Komponente aktualisiert ist.

Wer stellt die PHP-Version um, der Hoster oder die Wartung?

Technisch stellt meist der Hoster um, weil er die Laufzeit bereitstellt. Vorher prüft die Wartung, ob Shop-Kern, Erweiterungen und Individualcode mit der Zielversion laufen, und danach testet sie den Shop. Der Betreiber gibt den Termin frei. Für PHP 8.2 endet die Sicherheitspflege am **31. Dezember 2026** (The PHP Group).

Welche Pflichten bleiben beim Betreiber, wenn Hoster und Wartung beauftragt sind?

Nach Art. 32 DSGVO trifft die Pflicht zu geeigneten technischen und organisatorischen Maßnahmen den Verantwortlichen. Der Betreiber entscheidet über Zugänge, Wartungsfenster, größere Versionssprünge und Lizenzen und bewahrt die Nachweise auf. Die Umsetzung kann er übertragen, die Steuerung nicht.

Woran erkenne ich eine Lücke zwischen Hosting- und Wartungsvertrag?

Legen Sie beide Verträge neben die Zuständigkeitsmatrix. Jede Schicht, für die keiner der beiden Verträge eine Leistung nennt, ist eine Lücke. Jede Schicht, die in beiden auftaucht, braucht eine geregelte Übergabe, etwa beim Wechsel der PHP-Version oder bei der Freigabe gesperrter Anfragen.

Hoster oder Wartung: Wer im Shop was aktualisiert

Q: Kann ich meinen Hoster behalten, wenn ich einen Wartungsvertrag abschließe?

Ja, sofern der Tarif Zugang per SSH, eine planbare Versionspolitik und einen erreichbaren Ansprechpartner bietet. Die Wartung setzt auf die vorhandene Plattform auf und stimmt Umstellungen mit dem Hoster ab. Ein Umzug ist nur nötig, wenn der Tarif diese Voraussetzungen nicht erfüllt.

„Das macht doch der Hoster.“ Der Satz fällt in vielen Erstgesprächen über einen Shop, und er ist selten ganz falsch. Der Hoster spielt Sicherheitskorrekturen für das Betriebssystem ein, tauscht defekte Platten, hält das Netz erreichbar und stellt PHP-Versionen zur Auswahl. Was er in der Regel nicht tut: den Shop-Kern anheben, Erweiterungen aktualisieren, das Theme an eine neue Version anpassen oder prüfen, ob der Checkout nach einem Update noch rechnet. Diese Schichten stehen in üblichen Hosting-Verträgen gar nicht erst drin, und genau dort entsteht der größere Teil der gemeldeten Lücken. In einem groß angelegten Pentest bei Hosting-Anbietern wurden nur 26 % (Patchstack) der Angriffe auf Schwachstellen abgewehrt. Dieser Beitrag zieht die Grenze Schicht für Schicht: was beim Hoster liegt, was bei der Wartung, was beim Betreiber bleibt und an welchen Stellen die Übergabe zwischen den dreien geregelt sein muss.

Das Wichtigste in Kürze

Der Hoster verantwortet in der Regel Netz, Hardware, Betriebssystem und die Bereitstellung von PHP und Datenbank. Shop-Kern, Erweiterungen, Theme und Individualcode stehen in üblichen Hosting-Verträgen nicht in der Leistungsbeschreibung.
Schutz auf Serverebene fängt Anwendungslücken nur zum Teil ab: Im Pentest bei Hosting-Anbietern wurden 26 % (Patchstack) der Angriffe geblockt, gegen bekannte, bereits ausgenutzte Lücken nur 12 % (Patchstack).
Von 11.334 (Patchstack) neu gemeldeten Lücken im WordPress-Ökosystem 2025 betrafen nur 6 (Patchstack) den Kern. Für Shopware gibt es keine vergleichbare Auswertung; der Befund dient als Analogie.
Ein zentraler Übergabepunkt ist PHP: Die Sicherheitspflege für PHP 8.2 endet am 31. Dezember 2026 (The PHP Group). Wer umstellt und wer danach den Shop testet, gehört schriftlich geregelt.
Die Pflicht zu geeigneten technischen und organisatorischen Maßnahmen nach Art. 32 DSGVO trifft den Verantwortlichen, also den Betreiber. Aufgaben lassen sich übertragen, die Steuerung nicht.

Wo die Zuständigkeit des Hosters endet

Hosting ist ein Sammelbegriff für sehr unterschiedliche Leistungen. Beim einfachen Webspace teilt sich der Shop einen Server mit anderen Kunden; der Hoster pflegt alles bis zur PHP-Version, der Betreiber alles darüber. Beim virtuellen oder dedizierten Server ohne Verwaltung endet die Leistung oft schon an Hardware und Netz, das Betriebssystem ist dann Sache des Kunden. Beim verwalteten Server übernimmt der Hoster Betriebssystem, Webserver, Datenbank und PHP-Laufzeit, meist mit einem festen Katalog an Versionen. In allen drei Fällen hört die Pflege dort auf, wo die Anwendung beginnt: bei den Dateien, die der Shop selbst mitbringt.

Der Grund ist nachvollziehbar. Ein Hoster betreibt sehr viele Installationen und kann nicht wissen, welche Erweiterung in welchem Shop eine Preislogik überschreibt oder welches Theme eine Vorlage des Kerns ersetzt. Ein Update des Shop-Kerns ist keine Routine auf Plattformebene, sondern ein Eingriff in das Geschäft eines Kunden: Es kann den Checkout, die Zahlungsanbindung oder den Export an die Warenwirtschaft verändern. Deshalb schließen viele Hosting-Verträge die Anwendung ausdrücklich aus oder nennen sie gar nicht, was im Ergebnis auf dasselbe hinausläuft.

Managed Hosting ist kein verwalteter Shop

Das Wort „Managed“ bezieht sich im Hosting-Vertrag in der Regel auf den Server, nicht auf die Anwendung. Ob der Anbieter auch Shop-Kern und Erweiterungen pflegt, steht in der Leistungsbeschreibung, nicht im Produktnamen. Fehlt dort eine ausdrückliche Zusage, liegt die Pflege beim Betreiber.

Die Zuständigkeitsmatrix: Schicht für Schicht

Die folgende Tabelle ordnet jede Schicht eines Shop-Betriebs den drei Rollen zu. Sie beschreibt den typischen Zuschnitt bei einem verwalteten Server mit separatem Wartungsvertrag. Einzelne Verträge weichen ab, gerade bei der Datenbank und bei den Backups. Die Matrix ersetzt deshalb keine Leistungsbeschreibung, sie ist ein Raster, gegen das man sie legen kann: Jede Zeile, für die sich im Vertrag niemand findet, ist eine Lücke.

Schicht	Hoster	Wartung	Betreiber
Netz und Hardware	Betrieb, Austausch, Anbindung, Abwehr von Überlastangriffen	Erreichbarkeit von außen überwachen	Tarif und Standort wählen
Betriebssystem	Sicherheitskorrekturen, Neustarts, Supportende im Blick	Auswirkung auf den Shop prüfen	Wartungsfenster freigeben
PHP und Datenbank	Versionen bereitstellen, Laufzeit pflegen	Verträglichkeit prüfen, Shop anpassen, nach der Umstellung testen	Termin freigeben
Webserver und Firewall	Konfiguration, Zertifikate, Netzfilter	Regeln auf den Shop abstimmen, Sperren prüfen	Ausnahmen genehmigen
Shop-Kern	nicht enthalten	Updates einspielen, testen, Rückweg bereithalten	größere Versionssprünge freigeben
Erweiterungen	nicht enthalten	Updates, Lizenzstand, Verträglichkeit	Lizenzen bezahlen, Nutzen bewerten
Theme und Individualcode	nicht enthalten	an neue Versionen anpassen, Regressionstests	Entwicklungsaufträge vergeben
Inhalte und Konfiguration	nicht enthalten	technische Einstellungen nach Updates prüfen	Produkte, Preise, Texte, Versandregeln
Zugänge	Server- und Panelkonten	Admin- und Entwicklerkonten prüfen und entziehen	entscheiden, wer was darf
Backups	Serversicherung nach Tarif	Sicherung vor Updates, Wiederherstellung üben	Aufbewahrung festlegen

Auffällig ist die Spalte des Hosters: Ab der Zeile Shop-Kern steht dort nichts mehr. Das ist kein Mangel des Hosters, sondern der normale Zuschnitt. Problematisch wird es erst, wenn der Betreiber annimmt, diese Zeilen seien mit abgedeckt. Dann pflegt niemand die Schichten, in denen die meisten Lücken gemeldet werden. Was ein Wartungsvertrag in diesen Zeilen konkret leistet, steht ausführlich im Beitrag dazu, was in einen Wartungsvertrag gehört.

Warum Schutz auf Serverebene nicht reicht

Viele Hoster bieten Firewall, Schadcode-Suche und Filter vor dem Webserver an. Diese Schichten sind nützlich, sie wirken aber an einer anderen Stelle als eine Lücke in der Anwendung. Ein Filter vor dem Server sieht eine Anfrage, nicht die Logik, die sie im Shop auslöst. Ob ein Parameter eine fehlende Rechteprüfung in einer Erweiterung ausnutzt, lässt sich von außen oft nicht erkennen, weil die Anfrage genauso aussieht wie eine legitime.

Wie groß dieser blinde Fleck ist, hat Patchstack für das WordPress-Ökosystem gemessen. In einem groß angelegten Pentest bei verbreiteten Hosting-Anbietern wurden nur 26 % (Patchstack) aller Angriffe auf Schwachstellen geblockt. Ein zweiter Versuch mit bekannten, bereits ausgenutzten Lücken ergab, dass herkömmliche Abwehr nur 12 % (Patchstack) der Angriffe auf WordPress-spezifische Schwachstellen aufhielt. Für den Shopware-Store gibt es keine vergleichbare Auswertung; der Befund dient hier als Analogie eines gleich gebauten Baukastensystems, in dem Erweiterungen vieler Hersteller auf einem gemeinsamen Kern laufen.

Was daraus folgt

Schutz vor dem Server ist die erste Verteidigungslinie, nicht die einzige. Die zweite ist das Update der betroffenen Komponente, und dieses Update kann nur einspielen, wer die Anwendung kennt und danach prüft, ob sie noch funktioniert. Eine Firewall-Regel des Hosters verkürzt die Zeit, in der ein Shop angreifbar ist; sie ersetzt das Schließen der Lücke nicht. Wie sich eine eigene Schutzschicht vor dem Shop pflegen lässt, zeigt der Beitrag zu WAF und Bot-Schutz in der Wartung.

Wo die Lücken tatsächlich sitzen

Die Verteilung der Schwachstellen erklärt, warum die Grenze zwischen Hoster und Wartung so viel Gewicht hat. Patchstack zählte für 2025 insgesamt 11.334 (Patchstack) neue Schwachstellen im WordPress-Ökosystem. Im Kern selbst wurden davon nur 6 (Patchstack) gemeldet, und diese waren niedrig eingestuft. Der Rest steckt in Erweiterungen und Themes, also in genau den Schichten, die in der Matrix oben beim Hoster leer bleiben. Auch hier gilt: Die Zahlen stammen aus einem anderen System und werden für Shopware nur als Analogie herangezogen.

Zwei weitere Werte aus derselben Auswertung zeigen, wie wenig Zeit zwischen Meldung und Angriff bleibt. Bei 46 % (Patchstack) der Schwachstellen lag zum Zeitpunkt der Veröffentlichung noch keine Korrektur des Herstellers vor. Bei stark ausgenutzten Lücken vergingen im Median 5 Stunden (Patchstack) bis zur massenhaften Ausnutzung. Das BSI zählte in seinem Lagebericht 2025 weltweit im Schnitt 119 (BSI) neu bekannt gewordene Schwachstellen pro Tag. Wer bei dieser Menge darauf wartet, dass der Hoster eine Erweiterung aktualisiert, wartet auf etwas, das im Vertrag nicht vorgesehen ist.

Plattform

Betriebssystem, Webserver, PHP-Laufzeit und Datenbank. Hier greifen die Updates des Hosters, meist automatisch und ohne Zutun des Betreibers.

Anwendung

Shop-Kern, Erweiterungen, Theme und Individualcode. Hier entsteht der größere Teil der Meldungen, und hier braucht jedes Update einen Test im Shop.

Betrieb

Konfiguration, Zugänge und Freigaben. Diese Schicht lässt sich nicht vollständig auslagern, weil sie Entscheidungen des Unternehmens enthält.

Übergabepunkt PHP: wer umstellt, wer testet

Besonders direkt treffen Hoster und Wartung bei der PHP-Version aufeinander. Jeder Versionszweig wird zwei Jahre voll gepflegt und danach zwei weitere Jahre nur noch mit kritischen Sicherheitskorrekturen versorgt. The PHP Group formuliert die Folge nüchtern: Nach vier Jahren (The PHP Group) Pflege erreicht der Zweig sein Lebensende und wird nicht mehr unterstützt. Für PHP 8.2 ist das der 31. Dezember 2026 (The PHP Group), für PHP 8.4 endet die Sicherheitspflege am 31. Dezember 2028 (The PHP Group).

Shopware 6 setzt laut Entwicklerdokumentation PHP 8.2 (Shopware) als Minimum voraus und empfiehlt 8.4 (Shopware), dazu ein memory_limit von mindestens 512M (Shopware). Bei der Datenbank nennt die Dokumentation MariaDB ab 10.11.6 (Shopware) oder MySQL ab 8.0.22 (Shopware). Welche PHP-Version auf dem Server läuft, ist damit keine reine Hoster-Angelegenheit mehr: Die Version muss zum Shop-Kern passen, zu jeder Erweiterung und zum Individualcode.

Die Dokumentation enthält außerdem einen Hinweis, der im Alltag zu Missverständnissen führen kann: Auf vielen Servern laufen Kommandozeile und Webserver mit unterschiedlichen PHP-Konfigurationen. Sinngemäß heißt es dort, CLI und FPM hätten oft unterschiedliche php.ini-Dateien, und man solle den Hosting-Anbieter nach dem richtigen PHP-Binary fragen. Wer im Panel auf eine neue Version umstellt, hat unter Umständen nur eine der beiden Laufzeiten angehoben, und geplante Aufgaben oder Wartungsbefehle laufen weiter mit der alten.

Schritt 1

Bestand erfassen

Die Wartung stellt fest, welche PHP- und Datenbankversion für Webserver und Kommandozeile gilt und welche Erweiterungen installiert sind.

Der entscheidende Punkt ist der Termin mit dem Hoster. Stellt der Hoster die Version eigenständig um, etwa weil er einen Versionszweig aus seinem Katalog nimmt, trifft die Umstellung einen ungeprüften Shop. Deshalb gehört in den Hosting-Vertrag eine Vorlaufzeit für solche Änderungen und in den Wartungsvertrag die Pflicht, diese Vorlaufzeit zu nutzen. Wie ein geordneter Versionswechsel im Detail abläuft, beschreibt der Beitrag zum PHP-EOL-Management für sichere Upgrades; für das Supportende von Betriebssystem und Datenbank gilt dasselbe Prinzip, siehe Supportende im Unterbau.

stand-erfassen.sh

#!/usr/bin/env bash
# Stand von Laufzeit und Shop erfassen, bevor Hoster und Wartung über eine Umstellung sprechen.
# Die Werte gelten für die Kommandozeile; der Webserver (PHP-FPM) kann eine andere php.ini laden.
set -u

echo "PHP (CLI):";            php -v | head -n 1
echo "memory_limit (CLI):";   php -r 'echo ini_get("memory_limit"), PHP_EOL;'
echo "Geladene php.ini (CLI):"; php --ini | head -n 2

# Zugangsdaten der Datenbank wie in der Shop-Konfiguration hinterlegt
echo "Datenbank:";            mysql -N -e 'SELECT VERSION();'

cd /pfad/zum/shop || exit 1
echo "Shop-Kern:";            composer show shopware/core | grep -E '^versions'
echo "Erweiterungen:";        bin/console plugin:list

Das Skript ändert nichts, es liest nur. Sein Ergebnis gehört in die Ticket-Historie, bevor ein Termin mit dem Hoster vereinbart wird. Weicht die Ausgabe von dem ab, was der Webserver in seiner PHP-Info anzeigt, ist die zweite Laufzeit gefunden, bevor sie einen nächtlichen Aufgabenlauf zum Stehen bringt.

Fragen an den Hoster vor Vertragsschluss

Die Matrix wird erst belastbar, wenn der Hoster sie für seinen Vertrag bestätigt. Die folgenden Fragen lassen sich schriftlich stellen und schriftlich beantworten. Jede Antwort, die „im Einzelfall“ oder „auf Anfrage“ lautet, ist ein Hinweis darauf, dass die Zeile in der Matrix beim Betreiber oder bei der Wartung landet.

Welche Schichten pflegt der Tarif ausdrücklich: Betriebssystem, Webserver, PHP, Datenbank, Mailserver?
Wie lange im Voraus wird angekündigt, dass eine PHP- oder Datenbankversion aus dem Angebot fällt, und wer erhält diese Ankündigung?
Werden Webserver-PHP und Kommandozeilen-PHP gemeinsam umgestellt, und lässt sich die Version je Umgebung festlegen?
Gibt es Zugang per SSH und Composer, damit Updates des Shops über die Kommandozeile laufen können?
Welche Backups laufen, wie lange werden sie aufbewahrt, und wie wird eine Wiederherstellung einzelner Verzeichnisse oder der Datenbank beauftragt?
Wer entscheidet über Sperren durch die Firewall des Hosters, und wie wird eine fälschlich gesperrte Zahlungsbenachrichtigung freigegeben?
Gibt es eine Staging-Umgebung auf derselben Plattform, und darf sie mit einer Kopie der Live-Daten laufen?
Wie erreicht die Wartung den Hoster im Störungsfall, und welche Reaktionszeiten sind vereinbart?

Ob sich der vorhandene Hoster mit einer externen Wartung verträgt, ist selten eine Frage der Technik. Entscheidend sind Zugang per SSH, eine planbare Versionspolitik und ein erreichbarer Ansprechpartner. Die Antwort auf die Frage, ob Sie Ihren Hosting-Anbieter behalten können, hängt deshalb vor allem an diesen drei Punkten.

Was beim Betreiber bleibt

Auch mit Hoster und Wartungsvertrag bleibt ein Teil der Arbeit beim Betreiber, und zwar nicht aus Bequemlichkeit der Dienstleister. Die Datenschutz-Grundverordnung legt die Pflicht zur Sicherheit der Verarbeitung ausdrücklich dem Verantwortlichen und dem Auftragsverarbeiter auf. Der Betreiber kann Aufgaben übertragen, die Verantwortung für Auswahl und Steuerung seiner Dienstleister bleibt bei ihm.

[…] treffen der Verantwortliche und der Auftragsverarbeiter geeignete technische und organisatorische Maßnahmen, um ein dem Risiko angemessenes Schutzniveau zu gewährleisten

Art. 32 Abs. 1 DSGVO

Zu diesen Maßnahmen zählt Art. 32 Abs. 1 lit. d DSGVO ausdrücklich ein Verfahren zur regelmäßigen Überprüfung, Bewertung und Evaluierung ihrer Wirksamkeit. Für den Shop heißt das: Der Betreiber sollte zeigen können, dass Updates eingespielt, getestet und dokumentiert werden, gleich ob er das selbst tut oder beauftragt. Ein Wartungsprotokoll mit Datum, Version und Testergebnis ist dafür ein naheliegender Nachweis.

Zugänge freigeben

Wer ein Admin- oder Entwicklerkonto bekommt, entscheidet der Betreiber. Wartung und Hoster setzen die Entscheidung um und melden verwaiste Konten.

Wartungsfenster festlegen

Wann ein Update laufen darf, hängt am Geschäft: Aktionstage, Newsletter, Saison. Diese Termine kennt nur der Betreiber.

Größere Sprünge freigeben

Ein Wechsel der Hauptversion verändert Oberflächen und Abläufe. Die Freigabe gehört zu den Entscheidungen, die im Unternehmen fallen.

Lizenzen bezahlen

Viele Erweiterungen liefern Updates nur mit laufender Lizenz. Ob eine Erweiterung ihren Preis noch wert ist, bewertet der Betreiber.

Verträge abgleichen

Hosting- und Wartungsvertrag müssen dieselbe Matrix beschreiben. Lücken zwischen beiden fallen erst auf, wenn jemand sie nebeneinanderlegt.

Nachweise aufbewahren

Update-Protokolle, Testergebnisse und Backup-Nachweise belegen die Maßnahmen nach Art. 32 DSGVO. Aufbewahren muss sie der Verantwortliche.

Bei den Zugängen lohnt ein genauer Blick, weil hier alle drei Rollen Konten verwalten: der Hoster im Panel und auf dem Server, die Wartung im Shop und im Repository, der Betreiber in der Administration. Wie ein vollständiges Rechteinventar aussieht und wie man Zugänge beim Wechsel eines Dienstleisters sauber entzieht, steht im Beitrag zum Entziehen von Zugängen und Rechteinventar.

Die Lücke zwischen zwei Verträgen

Manche Lücke ist nicht technischer Natur. Sie entsteht, wenn zwei Verträge denselben Bereich jeweils dem anderen zuschreiben. Der Hoster geht davon aus, dass die Wartung Erweiterungen aktualisiert, die Wartung geht davon aus, dass der Hoster die Firewall-Regeln nach einer Warnung anpasst, und der Betreiber geht davon aus, dass beides passiert. Im Ergebnis bleibt eine bekannte Lücke offen, obwohl zwei Dienstleister bezahlt werden.

Wie lange so etwas dauern kann, zeigt der Data Breach Investigations Report von Verizon. Das Ausnutzen von Schwachstellen ist dort inzwischen der häufigste bekannte Einstiegsweg bei Datenpannen und stieg im aktuellen Datensatz auf 31 % (Verizon). Für kritische Schwachstellen aus dem Katalog bekannter ausgenutzter Lücken der US-Behörde CISA stieg die mittlere Zeit bis zur vollständigen Behebung auf 43 Tage (Verizon). Beide Werte stammen aus dem branchenübergreifenden Datensatz des Berichts und beschreiben Organisationen allgemein, nicht speziell Online-Shops.

Meldung ohne Empfänger

Eine Sicherheitswarnung zu einer Erweiterung geht an eine Adresse, die niemand mehr liest, etwa an einen ausgeschiedenen Entwickler.

Umstellung ohne Test

Der Hoster hebt PHP planmäßig an, der Shop läuft danach nur noch teilweise, und niemand hat den Termin an die Wartung weitergegeben.

Backup ohne Probe

Der Tarif enthält eine tägliche Sicherung, aber niemand hat je eine Wiederherstellung des Shops samt Datenbank durchgespielt.

Gegen alle drei hilft dasselbe: eine gemeinsame Liste mit einem Namen je Zeile der Matrix, eine Adresse für Sicherheitsmeldungen, die bei der Wartung ankommt, und ein Monitoring von Shop und Checkout, das nach jeder Änderung durch den Hoster anschlägt, wenn der Shop nicht mehr sauber antwortet. Bei der Sicherung reicht es nicht, dass der Hoster sie anbietet; der Backup-Service der Wartung übt die Wiederherstellung und hält vor jedem Update einen eigenen Stand bereit.

Hoster behalten, Wartung darüberlegen

Um diese Lücken zu schließen, ist ein Wechsel des Hosters selten nötig. Die Wartung setzt auf die vorhandene Plattform auf und übernimmt die Zeilen, die im Hosting-Vertrag fehlen: Sicherheitsupdates für Kern und Erweiterungen, Tests nach jedem Update, Abstimmung mit dem Hoster bei PHP- und Datenbankwechseln. Wo ein Umzug trotzdem sinnvoll ist, etwa weil der Tarif keinen Zugang per SSH erlaubt, lässt er sich geordnet planen, siehe Serverumzug ohne Bestellverlust.

So teilen wir die Matrix auf

Der Wartungsvertrag mit SLA enthält Sicherheitsupdates für Shop-Kern und Erweiterungen, vor jedem Update eine Kompatibilitätsprüfung und eine Sicherung, dazu Monitoring, Backup-Prüfung und Wiederherstellungstests. Mit dem vorhandenen Hoster arbeiten wir zusammen, statt einen Umzug zur Bedingung zu machen. Für Shopware-Shops beschreibt die Seite zur Shopware-Wartung, wie Updates, Theme-Kompatibilität und die Prüfung der Benutzerkonten im Einzelnen ablaufen.

Wichtig ist dabei die Reihenfolge. Ein Update des Shop-Kerns wird zuerst auf einer Staging-Umgebung eingespielt und danach mit festen Regressionstests geprüft, wie im Beitrag zu Update-Tests und Regression beschrieben. Schlägt ein Update trotzdem fehl, greift der Rückweg, den die Antwort auf die Frage was bei einem fehlgeschlagenen Update passiert erläutert.

Der nächste Schritt

Der Einstieg ist ein Blatt mit der Matrix aus diesem Beitrag. Für jede Zeile trägt der Betreiber ein, wer sie heute tatsächlich pflegt, und legt Hosting- und Wartungsvertrag daneben. Zeilen ohne Namen sind die offenen Stellen, Zeilen mit zwei Namen die Stellen, an denen eine Übergabe geregelt werden muss. Parallel liefert das Skript aus dem Abschnitt zum Übergabepunkt PHP den technischen Stand. Mit beidem lässt sich in einem kurzen Gespräch klären, welche Zeilen eine Wartung übernehmen kann, ohne dass der Hoster wechseln muss. Die Anfrage dafür läuft über das Kontaktformular für ein Erstgespräch.

Quellen und Studien

Dieser Artikel stützt sich auf Daten aus: Patchstack, State of WordPress Security in 2026 (Datenbasis WordPress-Ökosystem, Meldungen 2025, Pentest bei Hosting-Anbietern); Verizon, 2026 Data Breach Investigations Report, Retail Snapshot; The PHP Group, Supported Versions; Shopware, Entwicklerdokumentation zum Hosting; BSI, Die Lage der IT-Sicherheit in Deutschland 2025; Verordnung (EU) 2016/679 (DSGVO), Art. 32. Alle Quellen abgerufen am 23.09.2026.