Dieser Text zeigt, wie diese Schuld entsteht, woran Sie sie erkennen, wie viele Stunden im Monat ein Shop verbraucht und wie eine Betreuung aussieht, die die Schuld nicht vergrößert. Wir malen keinen Weltuntergang auf alten Versionen an die Wand. Wir zeigen Ihnen die Rechnung.
Die Versionslandschaft, ohne Panikmache
Drei Fakten genügen für die Karte. PrestaShop 8 erschien im Oktober 2022 und verlangt PHP 8.1. PrestaShop 9 erschien im Juni 2025: Symfony 6.4, PHP Unterstützung bis 8.4, neue Admin API, neues Theme. PrestaShop 9.1 erschien im April 2026. Die Versionen 1.6 und 1.7 sind historisch.
Ein Support Enddatum für 1.7 nennen wir nicht, weil wir keines verifiziert haben und nichts erfinden. Praktischer ist dies: Ein Shop auf 1.7 steht auf einem Zweig, der nicht mehr weiterentwickelt wird, und kostenpflichtige Module erhalten dafür keine Updates mehr. Der zweite Punkt schmerzt schneller. Ein Anbieter eines Zahlungs oder Versandmoduls bringt eine Fassung für PrestaShop 8 und 9 heraus und lässt für 1.7 die Ausgabe von vor Jahren stehen. Das funktioniert, solange sich beim Anbieter nichts ändert. Ändert der Anbieter die API, ist es an einem Tag vorbei.
Prüfen Sie das selbst, das dauert eine Viertelstunde: Lesen Sie im Backoffice die PrestaShop und die PHP Version ab und zählen Sie dann, wie viele Module zuletzt vor mehr als zwei Jahren aktualisiert wurden. Diese Zahl zeigt das Risiko besser an als die Versionsnummer allein.
Warum ein Shop auf einer alten Version bleibt
Am Kern liegt es selten, der lässt sich relativ berechenbar anheben. Der Shop bleibt stehen, weil Module und Theme stehen bleiben.
Nach einigen Jahren hat ein typischer Shop von 30 bis 60 Module: gut ein Dutzend kostenpflichtig, zwei oder drei auf Bestellung geschrieben, der Rest während einer Kampagne ergänzt und nie wieder abgeschaltet. Das Theme wurde gekauft und danach verändert, oft mit überschriebenen Kernvorlagen. Beim Versionswechsel muss jemand für jede dieser Positionen eine konkrete Frage beantworten: Gibt es eine Entsprechung für die Zielversion, und wenn nicht, was dann. Für die meisten fällt die Antwort leicht. Für drei lautet sie: "Gibt es nicht, muss geschrieben werden." An diesen dreien bleibt das Projekt hängen.
Der Mechanismus läuft nur in eine Richtung: Je länger Sie stehen, desto teurer wird das Losfahren. Ein Shop auf PrestaShop 8, der auf 9 geht, macht einen Sprung. Ein Shop auf 1.7 überspringt zwei Hauptversionen auf einmal, die Änderungen beider Zweige häufen sich in einem Projekt, und getestet wird alles gleichzeitig. Dazu kommt PHP: Ein Sprung der Sprachversion kann ältere Module unabhängig von PrestaShop lahmlegen. Aufschieben ist nicht neutral. Es ist ein Kredit mit steigendem Zins.
Was Shops auf PrestaShop tatsächlich kaputt macht
Fünf Dinge, die in unserer Praxis am häufigsten in einem Ticket enden, jeweils mit der Größenordnung der Zeit bis zur Wiederherstellung des Betriebs. Das ist eine Beobachtung aus der Arbeit, keine vertragliche Zusage: Garantiert ist die Reaktionszeit, nicht die Reparaturzeit.
Modulkonflikte nach dem Überschreiben derselben Dateien. Symptom: Nach dem Aktivieren eines neuen Moduls verschwindet eine Schaltfläche im Warenkorb, oder die Preisanzeige bricht. Ursache: Zwei Module überschreiben dieselbe Vorlage oder dieselbe Klasse, das später geladene gewinnt. Größenordnung: von 1 bis 4 Stunden, sofern bekannt ist, was wann eingespielt wurde.
Performance bei großem Katalog. Symptom: Produktliste und Suche mahlen mehrere Sekunden, das Backoffice hängt beim Bearbeiten eines Produkts. Ursache: viele Kombinationen und Attribute, fehlende oder nicht neu aufgebaute Indizes, ein abgeschalteter oder wirkungsloser Cache. Größenordnung: von 4 bis 16 Stunden für Diagnose und erste Korrekturen, denn das ist Arbeit an Daten, nicht an einem Schalter.
Anbindungen an Großhändler und ERP. Symptom: Die Bestände laufen auseinander, oder der Import bleibt nachts stehen und niemand sieht es bis zum Morgen. Ursache: eine Formatänderung beim Großhändler, ein abgelaufener Schlüssel, fehlende Fehlerbehandlung im Importskript. Größenordnung: von 2 bis 8 Stunden, dazu die Wartezeit auf die Gegenseite, auf die wir keinen Einfluss haben.
Zahlungs und Versandmodule nach Änderungen beim Anbieter. Symptom: Der Kunde schließt die Bestellung nicht ab, in den Logs erscheint eine Ablehnung des Gateways, Etiketten werden nicht mehr erzeugt. Ursache: Der Anbieter hat die API geändert oder die ältere Modulfassung zurückgezogen, und Ihre Shopversion hat keine passende Ausgabe. Größenordnung: von 2 bis 6 Stunden, wenn es ein Austauschmodul gibt. Gibt es keines, ist das kein Serviceticket mehr, sondern ein Projekt.
Fehler 500 nach einem Update. Symptom: weiße Seite oder Serverfehler direkt nach dem Einspielen einer Korrektur. Ursache: ein Modul, das mit neuer PHP oder Kernversion nicht verträglich ist, seltener Rechte und Cache. Größenordnung: von 30 Minuten bis 3 Stunden, vorausgesetzt es gibt eine Sicherung und die Änderung lässt sich zurücknehmen. Ohne Sicherung reden wir über ganz andere Zahlen.
Diese Kategorien haben wir breiter in unserem Text über die häufigsten Shopstörungen beschrieben.
Wie ehrliche PrestaShop Betreuung Monat für Monat aussieht
In der Praxis sind es fünf wiederkehrende Tätigkeiten. Keine davon ist spektakulär.
Erstens eine Modulinventur: jedes Modul mit Version, Anbieter, Ablaufdatum der Lizenz und dem Hinweis, ob es eine Ausgabe für die nächste Hauptversion gibt. Diese Liste wird gepflegt, nicht einmal erstellt. Zweitens eine Testumgebung als Kopie der Produktion, auf der jedes Update landet, bevor es den Shop berührt. Drittens Updates nach Ihrer Freigabe, abgerechnet aus dem Stundenkontingent, nicht heimlich nachts. Viertens die Überwachung der PHP Verträglichkeit, denn es ist der Hoster, der die Sprachversion wechselt, oft ohne zu fragen, und das ist der häufigste Grund für einen plötzlichen Fehler 500. Fünftens Sicherungen mit einem Wiederherstellungstest einmal im Quartal, denn eine Sicherung, die niemand zurückgespielt hat, ist eine Vermutung und kein Schutz.
Was hier fehlt: das Versprechen, dass nichts kaputtgeht. Das geben wir nicht. Wir versprechen, dass es im Schadensfall etwas gibt, wohin man zurückkehren kann, und dass klar ist, was zuletzt verändert wurde.
Wie viele Stunden PrestaShop frisst
Drei Profile aus unserer Praxis, zur Orientierung bei der Wahl des Supportpakets.
Stabiler Shop: bis 2.000 Produkte, gut ein Dutzend Module, eine Anbindung, Änderungen vor allem an Inhalten und Bannern. Realistisch von 6 bis 10 Stunden im Monat. Paket Basic, 220 EUR, Kontingent 10 Std.
Aktiver Shop: großer Katalog mit Kombinationen, Anbindung an ERP oder Großhändler, regelmäßige Kampagnen, mehrere kostenpflichtige Module mit Lizenzen im Blick. Von 15 bis 22 Stunden. Paket Advanced, 440 EUR, Kontingent 20 Std.
Komplexer Shop: mehrsprachig oder Multistore, mehrere Anbindungen, auf Bestellung geschriebene Module, häufige Änderungen im Kaufprozess. Von 30 bis 40 Stunden. Paket Premium, 880 EUR, Kontingent 40 Std.
Ein Hinweis fürs Budget: Ein Shop mitten in der Versionsmigration verbraucht von zwei bis drei Mal mehr Stunden als sonst, über die gesamte Projektdauer und noch einige Wochen nach der Umschaltung. Planen Sie für diese Zeit ein höheres Kontingent. Eine Stunde im Paket kostet 22 EUR, eine Stunde über das Kontingent hinaus 35 EUR, zusätzliche Stunden sind einzeln abgerechnet also schlicht teurer. Die Gesamtkosten rechnen wir in einem eigenen Text über die Kosten des Shopbetriebs durch.
Eine Versionsmigration ist ein Projekt, keine Aufgabe aus dem Kontingent
Migrationen werfen wir nicht in das Abonnement und tun nicht so, als passten sie ins Stundenkontingent. Wir kalkulieren sie getrennt, denn ihr Umfang folgt aus der Inventur, nicht aus dem Kalender.
Fünf Teile. Audit von Modulen und Theme: was eine Entsprechung hat, was eine kostenpflichtige, was neu geschrieben werden muss und was sich abschalten lässt, weil es seit drei Jahren niemand nutzt. Geschäftliche Entscheidungen auf Basis dieses Audits, getroffen von Ihnen, nicht von uns. Theme: anpassen oder auf einem neuen aufbauen. Daten: Migration und Prüfung von Katalog, Bestellungen, Kunden und Weiterleitungen. Tests auf einer Umgebung, die die Produktion kopiert, samt Kaufstrecke und Zahlungen. Am Ende die Umschaltung mit geplantem Fenster und fertigem Rückweg.
Und etwas Praktisches: Migrieren Sie nicht im November, auch nicht in der zweiten Oktoberhälfte. Jede Migration erzeugt in den ersten zwei Wochen nach der Umschaltung eine Welle kleiner Mängel, und das ist genau die Zeit, in der Sie Ihre Aufmerksamkeit nicht zwischen Saison und Nacharbeit teilen wollen. Die besten Fenster sind Januar, Februar und die Zeit von Mai bis August.
Checkliste für den aktuellen Dienstleister
Sieben Fragen. Die Antworten sagen mehr als jede Präsentation.
- Wer ist Inhaber der Lizenzen für kostenpflichtige Module: Sie oder die Agentur? Bei der Agentur stehen Sie nach der Trennung ohne Updaterecht da.
- Liegt der Shopcode in einem Repository, und haben Sie Zugriff darauf?
- Gibt es ein Verzeichnis der Overrides und Anpassungen außerhalb des Standards, oder muss es erst aus den Dateien rekonstruiert werden?
- Wer hat Zugriff auf Server und Hostingpanel, und stehen Sie auf dieser Liste?
- Liest überhaupt jemand die Fehlerlogs, oder warten wir auf die Meldung eines Kunden?
- Wann wurde zuletzt eine Sicherung in einer Testumgebung zurückgespielt?
- Welches ist das Ablaufdatum der ältesten Modullizenz, und wer behält es im Auge?
Bleiben drei dieser Fragen ohne Antwort, ist die Betreuung eine Reaktion auf Störungen und keine Instandhaltung. Das muss nicht immer einen Wechsel bedeuten, manchmal genügt es, das Fehlende zu ergänzen. Aber es lohnt sich zu wissen, wofür Sie zahlen und ob Abonnement oder Stundenabrechnung besser passt.
Vergleichen Sie Leistungsumfang und Preise unter /de/sla-help-desk und wählen Sie das Paket, das zu Ihrem Stundenprofil passt. Wenn Sie zuerst sehen möchten, wo Ihr Shop steht, starten Sie Tester eCommerce: Sie geben die Shopadresse an und erhalten eine kostenlose Diagnose, ohne Verkaufsgespräch zu Beginn.