Upgrading PrestaShop (1.7 → 8 → 9) without breaking the store

Why upgrading is a security matter

Every PrestaShop release fixes flaws that are then published with their identifier. For example, in August 2026 8.2.8 and 9.1.5 came out together with five security advisories, among them an SQL injection in the back-office list filters and an SSRF in the CSV import (PrestaShop security advisories). From the moment they are published, anyone can read what was wrong.

And some versions no longer get fixes at all. According to the PrestaShop team, the 1.7.8 branch stopped being maintained when PrestaShop 9.0.0 was released (June 2025); the last 1.7 version is 1.7.8.11, from January 2024. The 8.2 branch is in extended support, which will end when PrestaShop 10.0.0 comes out. If you are on 1.6 or 1.7, every new flaw that is discovered will stay open in your store.

Upgrading does not fix everything: third-party modules have their own flaws and are updated separately. The best-known ones are listed in PrestaShop modules with vulnerabilities. And if you suspect the store is already compromised, do not upgrade on top of it: first check and clean it, because an upgrade does not remove a backdoor or a malicious override. The free scan tells you from the outside which version it detects and which visible modules have published flaws.

Which version you should move to

Check your version under Advanced Parameters → Information in the back office (or in the corner of the dashboard). Then:

• 1.6.x: first you have to move to 1.7 with version 4.14.3 of the upgrade module (the last one that supports 1.6), and continue from there. It is a big jump: the theme changes completely and many modules have no equivalent. Often a migration (fresh install plus data transfer) makes more sense than an upgrade.
• 1.7.x: the goal is to reach 8.2 and then 9. Below I explain why it is almost always two steps.
• 8.0 or 8.1: upgrade to the latest 8.2 and plan the move to 9.
• 8.2.x: apply the latest patch (8.2.8 as of this guide) and plan the move to 9 calmly.
• 9.x: stay on the latest patch of your branch. 9.2.0 was released on September 30, 2026.

Requirements: the PHP version decides

The requirement that constrains you most is PHP. According to the official requirements tables for 1.7, 8 and 9:

For 8 and 9 you also need at least MySQL 5.7 or MariaDB 10.2, Apache 2.4 or Nginx, and for 9 a memory_limit of at least 512M is recommended. The usual PHP extensions (cURL, DOM, GD, Intl, Mbstring, Zip, PDO MySQL…) come with most hosting plans, but check.

The upgrade module does this math for you: it only offers the highest version compatible with the PHP the server is running at that moment.

Inventory of modules and overrides

This is the step most stores skip and the one that prevents the most problems. Before touching anything, make a list of:

• Every third-party module: technical name, installed version, where it came from (Addons, another vendor, custom) and whether the author publishes a version compatible with your target version. The ones that do not are your biggest risk.
• Modules you do not use: uninstall and delete them before upgrading. Fewer things to migrate and less attack surface.
• Overrides: everything in override/classes/ and override/controllers/. Each one modifies a core class that may have changed in the new version. Note which module or developer created each one.
• The theme: if it is a purchased theme, whether the author has a version for 8 or 9; if it is a child of the default theme, which templates it overrides.
• Changes made directly in the core (files in classes/ or controllers/ edited by hand). The upgrade overwrites them without warning. Comparing the core with the original of your version is the only way to know.

From the command line, the upgrade module itself has a command that lists the modules that need some action before or during the upgrade (you will see it below).

Update Assistant or manual

Update Assistant (the autoupgrade module)

The official upgrade module, technical name autoupgrade, is now called Update Assistant (for years it was "1-Click Upgrade"). Its current versions work for any store from 1.7 on. You install it from the back-office Marketplace, from Addons or from GitHub, and it works in two ways:

• From the back office, with a wizard: pick the version (it suggests the recommended one for your PHP), review the requirements (blockers show in red), choose options and backup, and start the upgrade.
• From the command line, which I recommend for large stores because it does not depend on browser or web server time limits.

The main commands, run from the module folder (modules/autoupgrade), according to its official documentation:

# Does the server meet the requirements?
php bin/console update:check-requirements your-admin-folder

# Modules that need some action
php bin/console update:check-modules your-admin-folder

# Versions available for this store
php bin/console update:check-new-version your-admin-folder

# Backup and upgrade
php bin/console backup:create --config-file-path=config.json your-admin-folder
php bin/console update:start --config-file-path=config.json your-admin-folder

Options worth understanding: disable non-native modules (on by default; according to the documentation, from PrestaShop 9 on this option is ignored), regenerate email templates (on by default; you will lose any customizations you have) and disable all overrides (off by default). The backup can be full, without images or none; if you choose none, the backup is up to you.

Manual

The official documentation only describes the manual upgrade (replacing files and running the database upgrade scripts by hand) for jumps within 1.7, from 1.7.0 to 1.7.8, and recommends the Update Assistant for everything else. When someone asks me to "upgrade PrestaShop manually" to 8 or 9, in practice it means one of two things:

• Using the Update Assistant from the command line with a downloaded package (the local channel, with the version's .zip and .xml in your-admin-folder/autoupgrade/download). It is the most controlled option.
• Migrating: installing the new version clean and moving over the catalog, customers and orders. It is more work, but it leaves behind years of old modules and overrides. It makes sense from 1.6 or for heavily patched stores.

Staging and checkout testing

I never upgrade directly in production. The order:

1. A copy of the store on a subdomain or test server, with the same PHP version production will have. Password-protect it and turn off customer emails and the live mode of the payment gateways (use their test modes).
2. Upgrade the copy following the plan: remove the modules you do not need, update the third-party ones to compatible versions, run the Update Assistant.
3. Go through the official post-update checklist and clear the cache.
4. Test the full purchase flow with every payment and shipping method: customer sign-up, cart, coupons, payment, confirmation email, PDF invoice, order status change in the back office.
5. Check the logs: var/logs/ and the PHP error log. Deprecation notices usually point to the module that will fail.
6. Only when all of that comes out clean, repeat in production during a low-sales window, with the store in maintenance mode.

Rollback plan

Before you start in production, be clear on how to get back in minutes:

• Your own full backup (files and database), in addition to the module's. The module's backup is stored on the same server; yours, off it.
• Restoring from the module: the Update Assistant offers to restore its backup if the upgrade fails, from the back office, or with php bin/console backup:restore --backup=NAME your-admin-folder if you have lost access to the admin.
• PHP: if you raised the PHP version for the new release, note how to lower it in the hosting panel. The restored copy needs its old PHP.
• Orders during the window: if you restore the database, you lose the orders placed between the backup and the restore. That is why you upgrade with the store in maintenance mode.

If you would rather I do it

I do PrestaShop upgrades with this same method: inventory, staging copy, test purchase and rollback plan. The online store maintenance plan (€69/month excluding VAT) includes a module review before every update and one hour of technical work per month; major version jumps are quoted separately depending on the store's modules. Details in PrestaShop maintenance. If you only want to know where your store stands before deciding, the PrestaShop security audit checks every module and version against the published advisories and the integrity of the core files, so you know what to fix first.

Sources

• PrestaShop 1.7, 8 and 9 system requirements (official documentation).
• Updating PrestaShop 9 and updating from the back office.
• The autoupgrade module (Update Assistant) on GitHub: commands, channels and options.
• PrestaShop core security advisories and published releases.
• PrestaShop 1.7.8 in extended support and 8.2.x in extended support.