PrestaShop 8 im Supportende: jetzt auf Version 9 migrieren?

Was „erweiterter Support“ konkret bedeutet

Seit Juli 2025 befindet sich PrestaShop 8 im erweiterten Support. Das ist noch nicht das Ende der Unterstützung, aber auch keine vollständige Pflege mehr: Der Zweig 8.x erhält nur noch Korrekturen kritischer Fehler, Sicherheitspatches und unverzichtbare Hook-Anpassungen. Neue Funktionen fließen ausschließlich in Version 9. Das echte Supportende kommt mit dem Erscheinen von PrestaShop 10.

Die Frage „PrestaShop 8 Supportende – muss ich migrieren?“ stellt sich also nicht wegen eines drohenden Ausfalls. Sie stellt sich wegen der technischen Schuld, die sich anhäuft.

Die drei technischen Fakten, die wirklich ins Gewicht fallen

PHP. PrestaShop 8 kommt maximal bis PHP 8.1, dessen offizieller Sicherheitssupport ausgelaufen ist. PrestaShop 9 unterstützt PHP 8.1 bis 8.4. Früher oder später nimmt Ihr Hoster PHP 8.1 aus dem Angebot – dann haben Sie keine Wahl mehr.

Symfony. PrestaShop 8 basiert auf Symfony 4.4, das ohne Sicherheits-Backports am Ende seines Lebenszyklus steht. PrestaShop 9 setzt auf Symfony 6.4 LTS, mit Fehlerkorrekturen bis Ende 2026 und Sicherheitsupdates bis Ende 2027. Das PrestaShop-Team hat ausdrücklich erklärt, dass für den Zweig 8.x keine Backports vorgesehen sind.

Node.js. Das Kompilieren der Themes in Version 9 setzt Node 20 oder höher voraus. Dieses Detail bringt Agenturen ins Stolpern, die noch mit einer alten Build-Umgebung arbeiten.

Was beim Wechsel auf Version 9 tatsächlich bricht

Die Migration von 8 auf 9 ist kein simples Versionsupdate. Diese Brüche erzeugen den eigentlichen Aufwand:

• Aus dem Core entfernte Bibliotheken: Swift Mailer weicht Symfony Mailer, Guzzle dem Symfony HTTP Client, League Tactician dem Symfony Messenger. Jedes Modul mit use GuzzleHttp\... erzeugt einen Fatal Error.
• Admin-Controller: FrameworkBundleAdminController ist zugunsten von PrestaShopAdminController veraltet. Controller müssen als Services mit Dependency Injection deklariert werden.
• Entfernte Bundles: sensio/framework-extra-bundle fällt weg, damit funktionieren Routing- und Template-Annotationen nicht mehr.
• Die Backoffice-Authentifizierung läuft vollständig über Symfony: Selbst gebaute SSO- oder Zwei-Faktor-Module, die auf dem alten Cookie aufsetzen, stellen den Dienst ein.
• Theme: Hummingbird wird zum Standard-Theme. Es verzichtet auf Bootstrap und macht Anpassungen kaputt, die für Classic geschrieben wurden. Classic wird weiterhin mitgeliefert – das verschafft Ihnen Zeit.

Das Entscheidungsraster

Bleiben Sie vorerst bei 8, wenn Ihr Shop stabil läuft, Ihr Hoster PHP 8.1 weiterhin anbietet, Sie von Drittanbieter-Modulen ohne 9-kompatible Version abhängen und Sie mitten in der Hochsaison stecken. Dann aber gilt: jeden Sicherheitspatch der Reihe 8.2.x konsequent einspielen.

Planen Sie die Migration in den nächsten 6 bis 12 Monaten, wenn Ihr Shop ein zentraler Vermögenswert ist, Sie regelmäßig Funktionen entwickeln oder Ihr Theme stark angepasst ist. Je länger Sie warten, desto weiter driften Ihr Code und der Core auseinander.

Denken Sie eher über einen Neubau als über eine Migration nach, wenn Ihr Theme von vor 2020 stammt, sich mehr als zehn Overrides angesammelt haben oder mehr als die Hälfte Ihrer Drittanbieter-Module nicht mehr gepflegt wird. In dieser Lage kostet eine Migration oft mehr als ein sauberer Neuaufbau – und liefert ein schlechteres Ergebnis.

Wie man ehrlich kalkuliert

Der vorgelagerte Audit ist der lohnendste Schritt im gesamten Projekt. Er beantwortet vier Fragen:

1. Wie viele Drittanbieter-Module sind im Einsatz, und für wie viele davon gibt es eine veröffentlichte 9-kompatible Version?
2. Wie viele Overrides liegen in override/, und werden sie überhaupt noch gebraucht?
3. Wie viele Templates sind im Theme überschrieben, und wie weit weichen sie vom Eltern-Theme ab?
4. Wie viel individuell entwickelter Code steckt im Shop?

Ein sorgfältiger Audit dauert ein bis zwei Tage und macht aus einem groben Angebot eine belastbare Aufwandsplanung. Er fördert außerdem zutage, dass manche Overrides auf längst aufgegebene Anforderungen zurückgehen – und die Migration leichter ausfällt als befürchtet.

Migrieren Sie nie ohne Rückfallplan

Drei Vorsichtsmaßnahmen sind nicht verhandelbar:

• eine Staging-Umgebung, die der Produktion entspricht und auf der die komplette Migration läuft, bevor irgendetwas im Livebetrieb passiert;
• eine schriftliche Abnahme, die Bestellprozess, Zahlungen, Versanddienstleister, Transaktions-E-Mails und Buchhaltungsexporte abdeckt;
• ein Umstellungsfenster mit wiederherstellbarer Sicherung und einem vorab festgelegten Abbruchkriterium.

Läuft Ihr Update bereits und hängt fest, behandelt unser Beitrag zum Update Assistant die häufigsten Fehler. Und wenn Sie von einer älteren Version starten, ist der Weg ein anderer: siehe die Migration von PrestaShop 1.6.

Ihren Shop prüfen lassen

Wir führen den Kompatibilitäts-Audit durch, kalkulieren die Migration und setzen sie mit Rückfallplan um. Unser Vorgehen finden Sie auf der Seite PrestaShop-Migration.