Shopware 5 im Bestand: Sanieren ohne Stillstand
Was zwei alte Shops uns über Bestandsaufnahme, Aktualisierungspfade und Rückfall ohne zweiten Server gelehrt haben
Ein mittelständischer Händler betreibt zwei Shopware-5-Shops beim selben Hoster. Beide laufen seit Jahren. Nun sollen sie rechtlich sauber, technisch aktuell und für KI-Suchsysteme verständlich werden. Die harte Randbedingung: Keiner der beiden Shops darf ungeplant offline gehen. Der Fall zeigt, warum eine Sanierung nicht mit dem Aktualisierungsknopf beginnt, sondern mit einer belastbaren Bestandsaufnahme.
Erst messen, dann planen
Die Versionsangaben des Betreibers stimmten nicht mit dem laufenden Bestand überein. Einer der Shops war zwei Hauptversionen weiter als angenommen. Der andere stand auf einem seit Jahren nicht gepflegten Stand. Hätten wir auf dieser Grundlage bereits einen Aktualisierungspfad festgelegt, wäre der Plan am ersten technischen Schritt zerfallen.
Wir nahmen den Bestand deshalb ausschließlich lesend auf: Backend, Systeminformationen, Erweiterungsmanager, Cronjobs, Benutzerverwaltung und öffentliche Seiten. Während dieser Aufnahme wurde nichts installiert, gespeichert oder umgestellt. Damit blieb klar, welcher Befund bereits vorhanden war und welche Veränderung später bewusst von uns ausgelöst wurde.
Die Lehre: Angaben aus zweiter Hand sind Hypothesen. Erst der laufende Bestand ist eine Planungsgrundlage.
Typische Altlasten in gewachsenen Shops
- Veraltete Laufzeit: Auf dem Verbrauchershop lief eine PHP-Version, die seit Ende 2018 keine Sicherheitsaktualisierungen mehr erhalten hatte.
- Zu viele Vollzugriffe: In der Benutzerverwaltung standen 13 Administratorkonten. Rund 10 davon waren seit Jahren ungenutzt.
- Abgebrochene Hintergrundarbeit: Cronjobs waren seit 2019 ohne Funktion. Der SEO-Index war zuletzt 2017 erneuert worden.
- Blockierte Aktualisierung: In jedem Shop waren 7 Erweiterungslizenzen abgelaufen. Ohne aktuelle Erweiterungen ließ sich die Shop-Aktualisierung nicht verlässlich vorbereiten.
- Ungeeigneter Betriebsmodus: Der Bearbeitungsmodus lief im Livebetrieb und hatte den HTTP-Cache deaktiviert.
Keiner dieser Punkte ist für sich ungewöhnlich. Problematisch wird die Kombination: Ein alter Kern, alte Erweiterungen, fehlende Hintergrundläufe und unklare Zugriffe beeinflussen einander. Deshalb gehört die Liste schriftlich in den Befund, bevor Aufwand und Reihenfolge festgelegt werden.
Die Rechtsfrage entscheidet den Umfang
Die erste fachliche Frage lautet nicht »Welche Shopware-Version läuft?«, sondern: Verkauft der Shop ausschließlich an Unternehmen oder auch an Verbraucher? Einer der beiden Shops zeigte Nettopreise, richtete sein Angebot aber zugleich an Verbraucher. Damit fehlte der nach der Preisangabenverordnung erforderliche Gesamtpreis.
Aus der Einordnung folgen weitere Prüffelder. Dazu gehören das Barrierefreiheitsstärkungsgesetz einschließlich seiner Ausnahmen, die 30-Tage-Regel bei bekannt gegebenen Preisermäßigungen nach § 11 PAngV und der frühere Link zur europäischen Plattform für Online-Streitbeilegung. Die zugrunde liegende EU-Verordnung wurde zum 20. Juli 2025 aufgehoben; ein alter OS-Link gehört deshalb entfernt.
Je nach Sortiment kommen die EU-Produktsicherheitsverordnung GPSR, ElektroG und WEEE-Registrierung, Batterierecht, VerpackG sowie die Einwilligungsregeln des TDDDG hinzu. Die technische Sanierung muss diese Fragen abbilden können. Sie ersetzt keine rechtliche Einzelfallprüfung.
Die Lehre: B2B oder B2C gehört an den Anfang. Die Antwort verändert nicht nur Texte, sondern Preislogik, Bedienoberfläche, Einwilligungen und Prüfaufwand.
Der Aktualisierungspfad ist eine Treppe
Der eingebaute Aktualisierer schlägt bei einem alten Shop nicht automatisch die letzte verfügbare Fassung vor. Das ist kein Fehler, sondern eine Folge der zulässigen Sprünge. Jede Shopware-Stufe unterstützt nur ein bestimmtes PHP-Fenster. Wer Shopware und PHP gleichzeitig bis zum Ende hochzieht, überspringt die Kombinationen, in denen der nächste Schritt überhaupt ausführbar ist.
Für den älteren Shop ergab sich deshalb ein achtstufiger Pfad. Shopware-Aktualisierungen und PHP-Wechsel wechselten einander ab. Jeder Schritt bekam eine eigene Prüfung: Backend erreichbar, öffentliche Seiten ohne Fehler, Erweiterungen geladen, Datenbankmigration abgeschlossen.
Der jüngere Shop benötigte nur drei Stufen. Genau deshalb war er der bessere Übungsplatz. Dort probten wir den vollständigen Ablauf einschließlich Rückfall. Erst nachdem Umschaltung und Rückweg nachvollziehbar funktioniert hatten, war der komplexere Shop an der Reihe.
Blau/Grün auf Verzeichnisebene
Für eine Blau/Grün-Umschaltung ist nicht zwingend ein zweiter Server nötig. Der laufende Shop bleibt in seinem bisherigen Verzeichnis unangetastet. Daneben entsteht eine vollständige Kopie in einem zweiten Verzeichnis, verbunden mit einer zweiten Datenbank. In dieser Kopie laufen alle Aktualisierungen, Prüfungen und Korrekturen.
Die Umschaltung besteht aus einem gemeinsamen Vorgang im Hosting-Panel: Dokumentenstamm und PHP-Version werden zusammen gewechselt. Nie erst das Verzeichnis und später PHP, nie umgekehrt. Andernfalls trifft alter Programmcode auf eine neue Laufzeit oder neuer Code auf eine zu alte Laufzeit.
Der Rückfall ist derselbe Handgriff rückwärts. Dokumentenstamm und PHP-Version zeigen wieder auf den alten, unveränderten Stand. Wenn dieser Weg vorher geprobt wurde, dauert die technische Rückkehr Minuten.
Die ehrliche Grenze: Für Datenbankmigrationen bleibt ein Wartungsfenster von rund 90 Minuten unvermeidbar. »Kein Ausfall« bedeutet hier: kein ungeplanter Ausfall, ein geplantes Fenster außerhalb der Geschäftszeiten und ein garantierter Rückweg in den alten Stand.
Lizenzen: Kundennummer ist nicht Konto
Für Lizenzarbeiten reicht eine Kundennummer nicht. Benötigt wird die Anmeldung zum Herstellerkonto, über die Erweiterungen und Lizenzstände verwaltet werden. Diese Unterscheidung klingt klein, blockiert aber den gesamten Aktualisierungspfad, wenn sie erst im Wartungsfenster auffällt.
Zugangsdaten dokumentieren wir deshalb nie als losgelöste Zeichenfolge. Zu jedem Zugang gehört der Fundort: welches Portal, welcher Mandant, welcher Zweck und welcher Shop. So lässt sich später prüfen, ob ein gefundener Zugang wirklich zum benötigten Konto gehört.
Was wir mitnehmen
- Bestandsaufnahme schriftlich, lesend und vollständig. Erst danach entsteht ein belastbares Angebot.
- Rechtliche Einordnung vor der Technik. B2B und B2C führen zu unterschiedlichen Anforderungen.
- Aktualisierungspfade in Stufen planen. PHP-Wechsel sind eigene Schritte mit eigener Prüfung.
- Den Rückfall am einfacheren System proben. Ein theoretischer Rückweg ist noch kein funktionierender Rückweg.
- Jede Änderung umkehrbar bauen. Der alte Zustand muss mit einem gemeinsamen Handgriff wieder erreichbar sein.
Wenn Sie sich in mehreren Befunden wiedererkennen, lassen sich Versionen, Konten, Hintergrundläufe, Erweiterungen und Rechtsrahmen in überschaubarer Zeit prüfen. Als IT-Manufaktur nehmen wir den Bestand auf und bauen den Sanierungspfad so, dass der laufende Shop bis zur geplanten Umschaltung unangetastet bleibt.
Ihr Shop braucht einen belastbaren Sanierungspfad?
Wir prüfen den laufenden Bestand, trennen Befunde von Annahmen und planen Aktualisierung, Umschaltung und Rückweg als zusammenhängenden Ablauf.
Onlineshop-Service ansehen