PrestaShop 8 on extended support: is it time to move to 9?

What "extended support" actually means

PrestaShop 8 moved to extended support in July 2025. That is not the end of support, but it is no longer full maintenance either: the 8.x branch now receives critical bug fixes, security patches and essential hook changes, and nothing else. New features go into version 9 only. Support will genuinely end when PrestaShop 10 is released.

So the question "PrestaShop 8 is reaching end of support, do I have to migrate?" is not about an outage waiting to happen. It is about technical debt piling up.

The three technical facts that really weigh

PHP. PrestaShop 8 tops out at PHP 8.1, whose official security support has now ended. PrestaShop 9 supports PHP 8.1 through 8.4. Sooner or later your host will retire PHP 8.1 from its estate, and the choice will be made for you.

Symfony. PrestaShop 8 runs on Symfony 4.4, which is end of life with no security backports. PrestaShop 9 has moved to Symfony 6.4 LTS, maintained for bug fixes until the end of 2026 and for security until the end of 2027. The PrestaShop team has said explicitly that no backport is planned for the 8.x branch.

Node.js. Compiling themes on version 9 requires Node 20 or higher. This detail catches out agencies still working with an older build environment.

What actually breaks when you move to 9

Going from 8 to 9 is not a routine version bump. These are the breaking changes that generate the workload:

• Libraries removed from the core: Swift Mailer replaced by Symfony Mailer, Guzzle by Symfony HTTP Client, League Tactician by Symfony Messenger. Any module declaring use GuzzleHttp\... will throw a fatal error.
• Admin controllers: FrameworkBundleAdminController is deprecated in favour of PrestaShopAdminController. Controllers now have to be declared as services with dependency injection.
• Removed bundles: sensio/framework-extra-bundle is gone, so route and template annotations no longer work.
• Back office authentication has been moved entirely onto Symfony: in-house SSO or two-factor modules that relied on the legacy cookie stop working.
• Theme: Hummingbird becomes the default theme. It drops Bootstrap and breaks overrides written for Classic. Classic is still shipped, which buys you time.

The decision grid

Stay on 8 for now if your store is stable, your host still maintains PHP 8.1, you depend on third-party modules whose vendors have not released a 9-compatible version, and you are in the middle of your trading season. In that case, apply every 8.2.x security patch without fail.

Plan the migration within 6 to 12 months if your store is a core business asset, you regularly build new features, or your theme is heavily overridden. The longer you wait, the wider the gap between your code and the core.

Consider a rebuild rather than a migration if your theme predates 2020, you have accumulated more than ten overrides, or more than half your third-party modules are no longer maintained. In that situation, migrating often costs more than rebuilding properly, for a worse result.

How to cost it honestly

The upfront audit is the single most profitable step in the whole project. It answers four questions:

1. How many third-party modules, and how many have a published 9-compatible version?
2. How many overrides in override/, and are they still needed?
3. How many overridden templates in the theme, and how far have they drifted from the parent theme?
4. How much bespoke code has been written?

A proper audit takes one to two days and turns a rough quote into a reliable workload plan. It also tends to reveal that some overrides date back to a requirement everyone abandoned long ago, and that the migration will be lighter than expected.

Never migrate without a way back

Three non-negotiable precautions:

• a staging environment identical to production, on which the full migration is run before anyone touches the live site;
• a written test plan covering checkout, payments, carriers, transactional emails and accounting exports;
• a switchover window with a restorable backup, and a failure criterion agreed in advance.

If your upgrade is already under way and stuck, our article on the Update Assistant covers the most common errors. And if you are starting from an older version, the route is different: see migrating from PrestaShop 1.6.

Have your store audited

We run the compatibility audit, cost the migration and carry it out with a rollback plan. See how we work on our PrestaShop migration page.