Veraltete Shopsysteme sind kein Automatismus für ein sofortiges Handlungsgebot. Viele laufen seit Jahren stabil, generieren Umsatz und scheinen ihren Zweck zu erfüllen. Dennoch verschieben sich die rechtlichen und technischen Rahmenbedingungen kontinuierlich – und mit ihnen die Risikolage für den Betreiber. Wer seine Position bewusst einschätzen kann, trifft bessere Entscheidungen über Investitionen und Zeitpunkt eines Systemwechsels.
Die Systeme im Überblick: Was aus der 2000er-Jahre-Ära übrig blieb
osCommerce und xt:Commerce prägten den deutschen Online-Handel in den frühen 2000er-Jahren. Beide Systeme basieren auf PHP und MySQL, setzen auf offene Architekturen und wurden durch eine aktive Community mit Erweiterungen versehen. xt:Commerce entstand als Abspaltung von osCommerce und fand vor allem im deutschsprachigen Raum Verbreitung; spätere Varianten wie xt:Commerce Veyton oder die kommerzielle Edition veränderten das Grundgerüst teilweise erheblich.
Heute existieren diese Systeme in sehr unterschiedlichen Zuständen. Ein Teil der Installationen wurde über Jahre hinweg gepflegt, mit individuellen Anpassungen versehen und läuft auf moderneren PHP-Versionen. Der weitaus größere Anteil verharrte jedoch auf einem Stand, der die ursprüngliche Softwarearchitektur weitgehend unverändert lässt – inklusive der damaligen Technologiestandards.
Entscheidend für die Risikobewertung ist die konkrete Installation vor Ort, nicht der Name des Systems. Ein xt:Commerce-Shop aus dem Jahr 2012 auf einem aktuellen Server mit angepasstem Code kann sicherer sein als ein scheinbar jüngeres System, das seit der Erstinstallation nie aktualisiert wurde.
Technische Lebenszeichen: Wann ein alter Shop noch läuft – und wann er stirbt
Die Lebensfähigkeit alter Shopsysteme hängt primär von der PHP-Version ab, auf der sie betrieben werden. PHP 7.4 erreichte im November 2022 das Ende der offiziellen Sicherheitsunterstützung; PHP 8.0 folgte im November 2023. Viele Hosting-Anbieter forcieren seitdem die Umstellung auf PHP 8.x oder kündigen ältere Versionen schrittweise ab.
osCommerce und ältere xt:Commerce-Versionen sind für PHP 7.x oder darunter geschrieben. Die Migration auf PHP 8.x erfordert in der Regel substanzielle Code-Anpassungen: veraltete Funktionen müssen ersetzt, striktere Typisierung berücksichtigt, Datenbankabfragen überarbeitet werden. Wer diese Anpassungen nicht vornimmt, läuft Gefahr, dass der Shop bei einer serverseitigen PHP-Aktualisierung unbrauchbar wird – ohne Vorwarnung und ohne einfache Rückkehr zum vorherigen Zustand.
Ein weiteres End-of-Life-Szenario betrifft das Plugin-Ökosystem. Zahlreiche Zahlungsanbieter, Versanddienstleister und Schnittstellenanbieter stellen die Unterstützung älterer Shopversionen ein. Der Betreiber verliert dann nicht die Funktionalität über Nacht, sondern erlebt einen schleichenden Prozess: Eine Zahlungsart wird nicht mehr angeboten, eine Versandintegration funktioniert nicht mehr mit aktuellen APIs, der Warenwirtschaftssystem-Export bricht zusammen.
Der kritische Moment entsteht, wenn mehrere Abhängigkeiten gleichzeitig ausfallen oder der Hosting-Anbieter die PHP-Version zwangsweise aktualisiert. Dann ist der Shop handlungsunfähig – oft in der Hauptgeschäftszeit, ohne Vorlauf für eine geordnete Migration.
Compliance-Lücken, die sich mit den Jahren auftun
Die rechtlichen Anforderungen an Online-Shops haben sich seit den 2000er-Jahren erheblich verschärft. Die Datenschutz-Grundverordnung (DSGVO) trat 2018 in Kraft und etablierte Pflichten zur Dokumentation technischer und organisatorischer Maßnahmen, zur rechtmäßigen Datenverarbeitung und zur Meldung von Verletzungen des Schutzes personenbezogener Daten. Das Telekommunikation-Telemedien-Datenschutzgesetz (TTDSG) ergänzte 2021 spezifische Regelungen für Cookies und Tracking-Technologien. Das Barrierefreiheitsstärkungsgesetz (BFSG) verpflichtet seit Juni 2025 bestimmte Unternehmen zur barrierefreien Gestaltung ihrer Webangebote.
Bei veralteten Shopsystemen entstehen mehrere konkrete Probleme:
Die DSGVO verlangt angemessene Sicherheitsmaßnahmen. Ein System ohne Sicherheitsupdates, das auf einer nicht mehr unterstützten PHP-Version läuft, lässt sich nur schwerlich als "Stand der Technik" rechtfertigen. Im Schadensfall – etwa bei einem Datenleck – erhöht sich das Haftungsrisiko, weil der Betreiber nicht nachweisen kann, dass er die technischen Voraussetzungen für einen sicheren Betrieb gewahrt hat.
Das TTDSG erfordert eine transparente Einwilligungsverwaltung für Cookies und ähnliche Technologien. Viele ältere Shopsysteme verfügen nicht über entsprechende Consent-Management-Funktionalitäten. Nachrüstlösungen sind oft aufwendig oder mit der bestehenden Codebasis nicht kompatibel.
Das BFSG betrifft vor allem Unternehmen mit mehr als 500 Mitarbeitern und einem Jahresumsatz über 50 Millionen Euro oder einer Bilanzsumme über 43 Millionen Euro. Für kleinere Betreiber besteht derzeit keine direkte Pflicht, jedoch wachsen die indirekten Anforderungen: Barrierefreiheit wird zunehmend als Qualitätsmerkmal erwartet, und die technischen Voraussetzungen dafür sind in älteren Systemen kaum gegeben.
Wichtig ist: Weder osCommerce noch xt:Commerce sind per se "illegal". Das Problem liegt in der konkreten Konfiguration, der Pflege des Systems und der Erfüllung der für den Einzelfall geltenden Pflichten.
Sicherheitsrisiken: Was ohne Updates wirklich passieren kann
Sicherheitslücken in veralteten Systemen sind kein theoretisches Risiko. Die konkrete Gefahr hängt von der exponierten Position ab: Ein kleiner Nischenshop mit wenigen Besuchern täglich ist weniger attraktives Ziel als ein etablierter Shop mit hohem Umsatz und sensiblen Kundendaten.
Typische Angriffsszenarien betreffen SQL-Injection-Schwachstellen, die in älteren Codebasen häufiger vorkommen, ungeschützte Administrationsbereiche, veraltete Verschlüsselungsmethoden für Passwörter oder Zahlungsdaten, und kompromittierte Plugins oder Themes, die nicht mehr gepflegt werden. Der Schaden reicht von manipulierten Bestellungen über Diebstahl Kundendaten bis zur vollständigen Übernahme des Servers.
Ein oft übersehener Aspekt: Der Betreiber haftet nicht nur für direkte Schäden, sondern auch für Folgeschäden bei Kunden. Wenn Zahlungsdaten abgefischt werden, weil der Shop eine unsichere Übertragung nutzt, entstehen neben den regulatorischen Konsequenzen auch zivilrechtliche Ansprüche.
Der richtige Zeitpunkt: Update, Migration oder kompletter Neuanfang
Die Entscheidung zwischen Weiterbetrieb, technischem Update und vollständigem Relaunch hängt von mehreren Faktoren ab.
Ein technisches Update reicht, wenn der Code grundsätzlich wartbar ist, die PHP-Anpassungen überschaubar bleiben, die Datenbankstruktur stabil ist und keine fundamentalen Geschäftsprozessänderungen anstehen. In der Praxis ist das bei osCommerce-Installationen ab etwa 2015 mit aktivem Customizing eher gegeben; bei älteren xt:Commerce-Versionen oder stark modifizierten Systemen wird es schnell unwirtschaftlich.
Eine Migration auf ein anderes Shopsystem wird notwendig, wenn die technische Basis nicht mehr zu retten ist, das Plugin-Ökosystem zusammenbricht, die Pflegekosten das Niveau einer Neuentwicklung erreichen oder strategische Anforderungen (Multichannel, erweiterte Automatisierung, internationale Expansion) das alte System überfordern.
Ein kompletter Relaunch empfiehlt sich, wenn sich die Marke, das Sortiment oder die Zielgruppe grundlegend verändert haben, die User Experience veraltet ist und Konversionsverluste vermutet werden, oder wenn die technische Migration kostenneutral zur gleichzeitigen Neuausrichtung genutzt werden kann.
Die Bewertung "nur alt" versus "gefährlich" lässt sich anhand mehrerer Indikatoren vornehmen: Läuft das System auf einer PHP-Version mit aktivem Security-Support? Sind Sicherheitsupdates für das Shopsystem und alle Plugins verfügbar? Funktionieren Zahlungs- und Versandschnittstellen mit aktuellen APIs? Erfüllt der Server die aktuellen Verschlüsselungsstandards? Ist ein technischer Notfallplan dokumentiert? Wer mehr als zwei dieser Fragen verneinen muss, befindet sich im Risikobereich.
Daten, SEO und Betrieb: Was bei einem Systemwechsel erhalten bleibt
Die Sorge vor dem Verlust von Bestandsdaten und Suchmaschinen-Rankings bremst viele Betreiber aus. Mit geplanter Vorgehensweise lassen sich beide Risiken minimieren.
Produktdaten, Kundenstamm, Bestellhistorie und Bewertungen sind technisch in der Regel übertragbar. Die Qualität der Migration hängt von der Datenbereinigung ab: Dubletten, veraltete Kategorisierungen und inkonsistente Pflege über Jahre erschweren den Import. Ein investierbarer Aufwand vor der Migration zahlt sich bei der Zielsystem-Einrichtung vielfach zurück.
Für die SEO-Stabilität sind drei Maßnahmen zentral: die Erhaltung der URL-Struktur durch Redirects auf neue Adressen, die Übertragung aller relevanten Metadaten und die Beibehaltung oder gezielte Verbesserung der internen Verlinkungslogik. Ein abruptes Abschalten alter URLs ohne Weiterleitung führt zu Ranking-Verlusten; eine sorgfältig geplante Umleitungsstrategie kann die Sichtbarkeit sogar stabilisieren oder verbessern, wenn gleichzeitig technische Defizite der alten Installation behoben werden.
Kostenvergleich: Weiterbetrieb versus Relaunch
Die Kosten eines Relaunchs sind unmittelbar sichtbar: Projektkosten für Konzeption, Design, Entwicklung, Migration, Testing und Einführung. Die Kosten des Weiterbetriebs verlagern sich in die Zukunft und bleiben oft unberechnet: Notfallbehebungen bei Ausfällen, manuelle Workarounds für nicht mehr funktionierende Schnittstellen, Zeitaufwand für veraltete Pflegeprozesse, höhere Sicherheitsprämien oder Selbstbeteiligungen bei Versicherungen, regulatorische Beratungskosten bei Prüfungen.
Ein pragmatischer Vergleich betrachtet den Zeitraum von drei bis fünf Jahren. In diesem Horizont konvergieren die Kostenkurven häufig – mit dem Unterschied, dass der Relaunch planbar ist, während der Weiterbetrieb mit unkalkulierbaren Unterbrechungen rechnen muss.
Für Betreiber, die unsicher sind, ob eine vollständige Neuentwicklung notwendig ist, bietet sich eine neutrale Bestandsaufnahme an. Eine Beratung kann die konkrete Situation bewerten und den passenden Aufwand ermitteln – ohne den Druck, sofort eine aufwändige Migration zu beginnen.
Erste Schritte für Betreiber mit Alt-Systemen
Wer die Lage seines Shops einschätzen möchte, kann systematisch vorgehen:
Zunächst die technische Basis dokumentieren: verwendete Shopsystem-Version, installierte Plugins und deren Versionsstände, PHP-Version, Serverkonfiguration, SSL-Zertifikat und Verschlüsselungsstandards. Diese Informationen lassen sich beim Hosting-Anbieter oder durch einen technischen Dienstleister ermitteln.
Anschließend die Abhängigkeiten prüfen: Welche Zahlungsanbieter, Versanddienstleister und Warenwirtschaftssysteme sind angebunden? Gibt es aktive Verträge oder technische Dokumentationen? Welche Schnittstellen werden vom Partner noch unterstützt?
Dann die rechtliche Situation bewerten: Ist eine aktuelle Datenschutzerklärung vorhanden und technisch umgesetzt? Funktioniert das Cookie-Consent-Management? Gibt es dokumentierte Verarbeitungstätigkeiten? Entspricht der Bestellprozess den aktuellen Anforderungen an Widerrufsbelehrung und Button-Lösung?
Schließlich die wirtschaftliche Tragfähigkeit prüfen: Welche Umsätze generiert der Shop aktuell? Welche Wachstumsziele bestehen? Welche Prozesse blockiert das alte System bereits heute?
Aus dieser Bestandsaufnahme lässt sich ein priorisiertes Maßnahmenpaket ableiten – von der kurzfristigen PHP-Anpassung über die mittelfristige Migration bis zur langfristigen strategischen Neuausrichtung.
Betreiber, die eine externe Einschätzung ihrer konkreten Situation wünschen, können hier eine unverbindliche Anfrage stellen. Die Bewertung erfolgt neutral und auf der Seite des Betreibers, ohne voreingestellte Empfehlung zu einem bestimmten System oder einer bestimmten Agentur.