Aktualisierung von PrestaShop: Was sollte vor der Kostenschätzung geprüft werden?

Für eine verlässliche Kostenschätzung einer PrestaShop-Aktualisierung werden die vollständige Shop-Version, die Serverumgebung, das Theme, die Schlüsselmodule und eine Beschreibung individueller Änderungen benötigt. Allein die Versionsnummer bestimmt den Arbeitsumfang nicht. Zwei Shops mit derselben Version können eine völlig unterschiedliche Vorbereitung erfordern, wenn einer Standardfunktionen nutzt und der andere einen modifizierten Checkout, eine Lagerintegration und eigene Preisregeln hat.

Dieser Leitfaden hilft dabei, eine Anfrage zur Aktualisierung vorzubereiten und Abnahmekriterien abzustimmen. Er ist keine Anleitung, um den Aktualisierer ohne vorheriges Backup und ohne Prüfung der Abhängigkeiten zu starten.

PrestaShop- und PHP-Version müssen eine unterstützte Kombination bilden

Notieren Sie die vollständige Bezeichnung der aktuellen und der geplanten Shop-Version. Prüfen Sie die PHP-Version, die die Website bedient, sowie die PHP-Version, die von CRON und Konsolenbefehlen verwendet wird. Das Hosting kann für diese Ausführungsarten unterschiedliche Versionen bereitstellen. Eine Änderung der Einstellung im Domain-Panel muss den Interpreter, der von geplanten Aufgaben verwendet wird, nicht zwingend ändern.

Laut der am 13. September 2026 geprüften Dokumentation unterstützt PrestaShop 9.0 PHP 8.1–8.4 und PrestaShop 9.1 — PHP 8.1–8.5. Auch die empfohlenen PHP-Versionen unterscheiden sich zwischen diesen Zweigen. Das ist ein Beispiel dafür, warum die Information „unterstützt PrestaShop 9“ bei der Auswahl der Umgebung nicht ausreicht. Quelle: offizielle Anforderungen von PrestaShop 9.

Eine unterstützte Umgebung der Shop-Engine allein bestätigt noch nicht die Kompatibilität des Themes oder der Module. Prüfen Sie vor der Anhebung von PHP auch deren Anforderungen, Servererweiterungen, Speicherlimits und die Art der Ausführung von Integrationen. Beginnen Sie nicht mit einer PHP-Änderung in der Produktion, nur weil eine höhere Versionsnummer vorteilhafter aussieht.

Inventarisierung: Beginnen Sie mit den kritischen Funktionen

Eine Liste aller Module ist nützlich, aber der Dienstleister sollte vor allem wissen, welche Funktionen den täglichen Verkauf aufrechterhalten. Nennen Sie Zahlungen, Lieferungen, Abholpunkte, Rechnungsstellung, Lager, Preis- und Bestandsimporte, Reservierungen sowie spezielle B2B-Regeln. Ergänzen Sie die Information, wer jede Integration betreut.

In der ersten Kontaktphase reichen technische Informationen und eine Prozessbeschreibung aus. Passwörter, API-Schlüssel oder Kundendaten sollten nicht in ein allgemein zugängliches Dokument eingetragen werden. Wenn Zugriff auf eine Kopie erforderlich ist, stimmen Sie die Art der Übergabe und den Umfang der Berechtigungen ab.

Was bleibt, was aktualisieren wir und was ersetzen wir?

Jedes wichtige Element sollte eine Entscheidung und deren Begründung erhalten. „Bleibt“ bedeutet bestätigte Eignung in der geplanten Konfiguration. „Zu prüfen“ ist vor der Analyse ein korrekter Status; vorgetäuschte Sicherheit erschwert die Kostenschätzung und die spätere Abnahme.

Bewerten Sie ein Modul nicht ausschließlich danach, ob es sich installieren lässt. Die Installation bestätigt weder die Berechnung des Rabatts noch die Speicherung des Abholpunkts oder den Abschluss der Kommunikation mit dem Lager. Ebenso ist eine korrekt angezeigte Startseite kein Beweis für eine korrekt durchgeführte Shop-Aktualisierung.

Individuelle Änderungen: Das größte Risiko ist im Panel oft nicht sichtbar

Fragen Sie die Personen, die den Shop betreuen, nach Änderungen, die im Laufe der Jahre entstanden sind: zusätzliche Felder, ungewöhnliche Bestellstatus, Preisänderungen, Ausschlüsse von Versanddienstleistern oder spezielle Exporte. Ein Teil davon kann außerhalb der im Panel sichtbaren Module existieren.

Nützlich ist eine kurze Verhaltensbeschreibung: „für diese Kundengruppe wird der Preis so berechnet“, „diese Produkte schließen diesen Versanddienstleister aus“, „nach diesem Status senden wir ein Dokument an das System“. Auf dieser Grundlage lässt sich ein Abnahmetest vorbereiten. Der bloße Name einer Override-Datei erklärt ihre geschäftliche Bedeutung nicht.

Die Wiederherstellung einer fehlenden Funktion kann separate Arbeit erfordern. Das sollte im Umfang erkannt oder ausdrücklich als zu klärende Abhängigkeit gekennzeichnet werden, statt erst nach der Umschaltung des Shops aufzutauchen.

Testkopie und Abnahmekriterien

Die Aktualisierung wird zunächst auf einer Kopie mit kontrollierten Integrationen durchgeführt. Die Vorbereitung der Kopie umfasst auch den Schutz des Zugangs, das Stoppen produktiver Aussendungen sowie die Trennung der Konfiguration externer Dienste. Die Kopie soll einen Probelauf des Prozesses ermöglichen und nicht unbewusst das Verhalten des Produktionsshops vervielfältigen.

Der offizielle Leitfaden zur Aktualisierung aus dem Panel beschreibt die Bedienung des Aktualisierungstools. Der Abnahmeumfang sollte zusätzlich die Shop-Funktionen widerspiegeln; als Bezugspunkt dient die Checkliste nach der Aktualisierung.

• Vergleichen Sie ausgewählte Produkte, Kombinationen, Preise und Bestände.
• Prüfen Sie das Kundenkonto, den Warenkorb, Adressen sowie wichtige Liefer- und Zahlungsmethoden.
• Kontrollieren Sie das Ergebnis der Bestellung im Panel und in den Systemen, in die sie gelangen sollte.
• Führen Sie kontrollierte Tests von Importen, Exporten und CRON-Aufgaben aus.
• Vergleichen Sie wichtige Adressen, Canonicals, Weiterleitungen, Sprachversionen und Sitemaps.
• Dokumentieren Sie Fehler, Entscheidungen und Akzeptanzbedingungen und nicht nur ein allgemeines „Tests abgeschlossen“.

Eine detailliertere Prüfliste für den Kaufprozess finden Sie im Leitfaden zum Wechsel des Checkouts. Bei Arbeiten an Adressen nutzen Sie auch den vorhandenen Text zum Erhalt alter Links und Weiterleitungen.

Der Umschalt- und Rückkehrplan muss neue Bestellungen berücksichtigen

Legen Sie vor den Arbeiten den Zeitpunkt für die Erstellung der finalen Datei- und Datenbankkopie, die Art der Begrenzung von Datenänderungen sowie die Reihenfolge des Stopps und der Wiederaufnahme von Integrationen fest. Bestimmen Sie die Person, die die Entscheidung über die Inbetriebnahme des Shops trifft, und die Bedingungen, unter denen Sie zur vorherigen Version zurückkehren.

Die Rückkehr zu einer Kopie von vor der Aktualisierung kann Bestellungen oder Änderungen aus der aktuellen Datenbank entfernen, die später gespeichert wurden. Deshalb ist ein Backup ohne festgelegten Wiederherstellungspunkt kein vollständiger Notfallplan. Es müssen auch Zahlungen berücksichtigt werden, die mit Verzögerung bestätigt werden können, sowie Daten, die an externe Systeme gesendet wurden.

Die Grundsätze zur Vorbereitung einer Kopie werden in der PrestaShop-Dokumentation zu Backups erläutert. Legen Sie für den konkreten Shop zusätzlich fest, wer die Wiederherstellbarkeit geprüft hat und wie Änderungen abgestimmt werden, die während der Arbeiten entstehen. Gehen Sie nicht von vornherein von einer Aktualisierung ohne Ausfallzeit aus.

Woraus besteht die Kostenschätzung?

Die Kostenschätzung kann Analyse und Inventarisierung, die Vorbereitung einer Kopie, die eigentliche Aktualisierung, die Anpassung von Code und Theme, Tests, die Umschaltung sowie Support nach dem Start umfassen. Lizenzen, kostenpflichtige Aktualisierungen externer Module und Funktionen, die wiederhergestellt werden müssen, sollten gesondert ausgewiesen werden.

Bitten Sie um einen klaren Umfang, Abhängigkeiten und Abschlusskriterien. Ein Festpreis ist für klar erkannte Arbeiten sinnvoll; bei unbekannten Änderungen kann zunächst eine Analysephase nützlich sein. Es gibt keinen einheitlichen fairen Betrag für jeden Shop mit der Bezeichnung „PrestaShop 1.7“ oder „PrestaShop 8“.

Bereiten Sie die Shop-Version, den Namen des Themes und die Liste der Schlüsselintegrationen vor. Auf dieser Grundlage kann man mit der Planung der Aktualisierung des PrestaShop-Shops beginnen, die erforderlichen Prüfungen festlegen und einen Umfang vorbereiten, der abrechenbar ist.

Fachliche Verifizierung: 13. September 2026. Die Versionsanforderungen wurden in der PrestaShop-Dokumentation geprüft. Die Entscheidungsmatrix ist beispielhaft; der Zielpfad und die Kompatibilität der Integrationen werden für den konkreten Shop festgelegt.