PrestaShop 8 loopt af: overstappen naar versie 9 of niet?

Wat "extended support" concreet betekent

Sinds juli 2025 zit PrestaShop 8 in extended support. Dat is niet het einde van de ondersteuning, maar ook geen volledig onderhoud meer: de 8.x-tak krijgt alleen nog oplossingen voor kritieke bugs, beveiligingspatches en de strikt noodzakelijke hook-aanpassingen. Nieuwe functionaliteit gaat uitsluitend naar versie 9. Het echte einde van de ondersteuning valt samen met de release van PrestaShop 10.

De vraag "PrestaShop 8 loopt af, moet ik migreren?" gaat dus niet over een dreigende storing. Die gaat over technische schuld die zich opstapelt.

De drie technische feiten die er echt toe doen

PHP. PrestaShop 8 komt niet verder dan PHP 8.1, waarvan de officiële beveiligingsondersteuning is afgelopen. PrestaShop 9 werkt met PHP 8.1 tot en met 8.4. Op enig moment haalt uw hostingpartij PHP 8.1 uit het aanbod en hebt u geen keuze meer.

Symfony. PrestaShop 8 draait op Symfony 4.4, dat end-of-life is en geen securitybackports meer krijgt. PrestaShop 9 is overgestapt op Symfony 6.4 LTS, met bugfixes tot eind 2026 en beveiligingsondersteuning tot eind 2027. Het PrestaShop-team heeft expliciet laten weten dat er geen backports voor de 8.x-tak komen.

Node.js. Het compileren van thema's in versie 9 vereist Node 20 of hoger. Dat detail verrast bureaus die nog met een oude buildomgeving werken.

Wat er in versie 9 daadwerkelijk breekt

De stap van 8 naar 9 is geen gewone versieverhoging. Dit zijn de breuken die het werk veroorzaken:

• Bibliotheken die uit de core zijn gehaald: Swift Mailer is vervangen door Symfony Mailer, Guzzle door Symfony HTTP Client en League Tactician door Symfony Messenger. Elke module die use GuzzleHttp\... declareert, levert een fatale fout op.
• Admincontrollers: FrameworkBundleAdminController is afgeschaft ten gunste van PrestaShopAdminController. Controllers moeten als service worden gedeclareerd, met dependency injection.
• Verwijderde bundles: sensio/framework-extra-bundle verdwijnt, waardoor route- en template-annotaties niet meer werken.
• De back-office-authenticatie is volledig op Symfony gezet: zelfgebouwde SSO- of tweefactormodules die op de oude cookie leunden, houden ermee op.
• Thema: Hummingbird wordt het standaardthema. Het laat Bootstrap los en breekt overschrijvingen die voor Classic zijn geschreven. Classic wordt nog wel meegeleverd, wat ruimte geeft om te wachten.

Het beslissingskader

Blijf voorlopig op 8 als uw webshop stabiel draait, uw hostingpartij PHP 8.1 blijft aanbieden, u afhankelijk bent van externe modules waarvan de leverancier nog geen 9-compatibele versie heeft uitgebracht, en u midden in het hoogseizoen zit. Rol in dat geval elke beveiligingspatch uit de 8.2.x-reeks strikt uit.

Plan de migratie binnen 6 tot 12 maanden als uw webshop een kernactiviteit is, u regelmatig functionaliteit laat ontwikkelen of uw thema zwaar is aangepast. Hoe langer u wacht, hoe groter het gat tussen uw code en de core.

Overweeg een herbouw in plaats van een migratie als uw thema van vóór 2020 dateert, u meer dan tien overrides hebt verzameld of meer dan de helft van uw externe modules niet meer wordt onderhouden. In dat scenario kost migreren vaak meer dan netjes opnieuw bouwen, met een slechter resultaat.

Een eerlijke kostenraming maken

De audit vooraf is de meest rendabele stap van het hele project. Die beantwoordt vier vragen:

1. Hoeveel externe modules hebt u, en van hoeveel bestaat er een 9-compatibele versie?
2. Hoeveel overrides staan er in override/, en zijn die nog nodig?
3. Hoeveel templates zijn in het thema overschreven, en hoe ver staan ze van het bovenliggende thema af?
4. Hoeveel maatwerkcode is er ontwikkeld?

Een serieuze audit kost één tot twee dagen en verandert een ruwe schatting in een betrouwbare planning. Vaak blijkt daarbij dat sommige overrides voortkomen uit een behoefte die allang is losgelaten, en dat de migratie lichter uitvalt dan gedacht.

Migreer nooit zonder terugvalplan

Drie voorzorgsmaatregelen waarover niet te onderhandelen valt:

• een acceptatieomgeving die identiek is aan productie, waarop de volledige migratie draait voordat er iets live gebeurt;
• een uitgeschreven testplan voor het bestelproces, de betalingen, de vervoerders, de transactionele e-mails en de boekhoudexports;
• een omschakelmoment met een terugzetbare back-up en een vooraf afgesproken afbreekcriterium.

Loopt uw update al en zit die vast, dan behandelt ons artikel over de Update Assistant de meest voorkomende fouten. Vertrekt u van een oudere versie, dan verloopt het traject anders: zie de migratie vanaf PrestaShop 1.6.

Uw webshop laten doorlichten

Wij voeren de compatibiliteitsaudit uit, begroten de migratie en voeren die uit met een terugvalplan. Bekijk onze aanpak op de pagina PrestaShop-migratie.