# Moving to PrestaShop 9: what changes, what breaks and how to prepare
Table of Contents
Anyone running a PrestaShop store eventually asks the same question: is it worth moving to version 9, or is it better to leave everything as it is while it works? The honest answer is that "while it works" has an expiry date, and the store doesn't set it: it's set by the PHP versions your host keeps offering, by modules that stop being updated, by vulnerabilities that only get fixed in new versions.
The good news is that moving to 9 is not a leap in the dark. You prepare it, test it on a copy and take it live in a short window. In this article we look at what really changes, what usually breaks, and the method that avoids finding out on the first day of the sales.
What really changes with PrestaShop 9
The most concrete difference is under the hood: PrestaShop 9 requires at least PHP 8.1 and, with 9.2 released on 30 September 2026, supports up to PHP 8.5. PHP is the language PrestaShop is written in, and every version has a limited life: when it ends, it no longer receives security fixes. We covered this in the article on the risks of an unsupported PHP.
Here's the point: PrestaShop 8 stops at PHP 8.1, and PHP 8.1 left security support on 31 December 2025. A store on version 8 today necessarily runs on a PHP version that no longer gets patches. Version 9 is the way back to a supported PHP.
Then there are the visible new features:
- a native one-page checkout, introduced in 9.2, which the merchant can switch on or off from the back office;
- Hummingbird as the default theme since 9.1, lighter and more modern than the old Classic;
- a back office that keeps moving to Symfony, the PHP framework PrestaShop is rebuilding its admin pages on.
What usually breaks
The PrestaShop core upgrades well. What breaks is almost always around it:
- third-party modules written for 1.7 or 8 that use removed or changed functions. Many modules on sale are still declared compatible only up to 8;
- overrides, meaning core classes replaced by a module or a developer: if the core changes, the override no longer fits;
- themes bought years ago and customised directly, without a child theme: they need adapting or replacing;
- integrations with management software, couriers and marketplaces, which often go through those very modules.
A typical example: a store with 18 modules. Twelve already have a version for 9, three are no longer used and can be removed, two are replaced with up-to-date alternatives, and one, custom-built years ago to link the management software, needs adapting. That's where the work concentrates, not in the core.
The method: the copy first, then the real store
The most expensive mistake is upgrading the live store directly. The method we use is always the same.
- Inventory: current version, list of modules with their compatibility, theme, PHP version available on the host.
- Full backup of files and database, and verified: a backup nobody ever tried to restore is a hope, not a plan. The 3-2-1 backup rule is still the reference.
- Test copy of the store, separate from the real one, where the upgrade happens.
- Tests on what makes sales: search, categories, product page, cart, checkout, payments, shipping, order emails.
- Go-live in an agreed, low-traffic window, with the backup ready to roll back.
Done this way, the real store stays open for the whole testing period; the final maintenance window usually takes less than an hour.
The theme: adapt or change?
The theme is the part customers see, so decisions weigh most there. There are three paths: a theme already compatible with 9, which you just update; a theme to adapt, with development work that needs estimating; or switching to Hummingbird, the default theme, customised with colours, logo and little else. The third path is often the cheapest in the long run, because a default theme gets updated along with PrestaShop.
How much it costs and how long it takes
The cost depends on three variables: how many third-party modules there are, how many need adapting and how customised the theme is. For a store with around fifteen modules and a compatible theme, the move takes a few days, mostly of checking. We do it at a fixed price for the upgrade to PrestaShop 9, with modules to adapt estimated separately before we start.
If the store is also slow, it's worth using the upgrade to fix the causes: they're often the ones described in the article on slow PrestaShop, and a newer PHP alone already brings an improvement.
In short
PrestaShop 9 is not a cosmetic update: it brings the store back to PHP versions that still receive security fixes, and with 9.2 it adds new features such as the one-page checkout. The core upgrades well; the work lies in modules, overrides, theme and integrations. With an inventory done first, a test copy and a verified backup, the move happens without stopping sales. Putting it off costs nothing today, but every month makes the jump bigger, just like PHP vulnerabilities piling up.
Sources
- PrestaShop 9.2 is available - PrestaShop Project, 30 September 2026
- System requirements - PrestaShop 9 - official documentation
- System requirements - PrestaShop 8 - official documentation
- Unsupported Branches - php.net, end-of-life dates for PHP versions
