Updating PrestaShop without breaking your store: a step-by-step method

A PrestaShop update that goes wrong gives no warning: the back office opens, the home page loads, and it is the checkout that throws an error, or a shipping module that no longer calculates anything. The method below is the one I follow for every upgrade, from 1.6 to 9. It comes down to one idea: you never update a store that is selling. You update a copy, and you only switch once the copy has been checked.

First, know what you are updating

"Updating PrestaShop" covers four operations with very different risks and costs:

• A patch within the same branch, for example from 8.1.5 to 8.1.7. It fixes security holes and bugs without changing how things work. Low risk, and urgent when security is involved.
• A major version, for example from 1.7 to 8, or from 8 to 9. The core changes, features disappear, and part of your modules and theme must follow.
• Modules and theme, which have their own versions and their own incompatibilities.
• The PHP version of the server, which your host upgrades and which can, on its own, break a store left without updates for too long.

The right order depends on where you start. A 1.7.8 store running PHP 7.4 is not handled like an 8.1 store that only needs a patch.

Check the PHP version first

Each PrestaShop version accepts a range of PHP versions, and that range often sets the schedule:

• PrestaShop 1.6 does not run beyond PHP 7.1.
• PrestaShop 1.7.8 requires PHP 7.1 to 7.4.
• PrestaShop 8 requires PHP 7.2 to 8.1.
• PrestaShop 9 requires at least PHP 8.1, 512 MB of memory per script, and MySQL 5.7 or MariaDB 10.2.

If your host announces the end of PHP 7.4, a 1.7 store has no choice: it must move to 8 before that date. You can read the PHP version in the back office, under Advanced Parameters > Information.

Back up, and check that the backup restores

A full backup means two things: the site files and the database. The PrestaShop update tool offers to make one, but I never rely on it alone: I take my own copy of the files and a database export, stored outside the server.

A backup that has never been restored is only a hope. The simplest test is to use it to build the working copy described below: if the copy works, the backup is good.

Work on a copy, never on the live store

The test copy (often called staging) is a second store, identical to the real one, installed on a password-protected subdomain and hidden from Google. The whole update happens there. Two precautions before starting:

• Turn off customer emails on the copy, otherwise your customers receive messages from the test store.
• Switch payments to test mode, so trial orders charge nobody.

Meanwhile, the real store keeps selling. Nothing is rushed, which is exactly the point.

List your modules and theme

Most failed updates come from a module, not from the PrestaShop core. Before launching anything, I list the installed modules and, for each one, check that its publisher offers a version compatible with the target. Three situations come up again and again:

• The module is no longer maintained. It must be replaced, or disabled if nobody really uses it.
• The module was edited by hand by a former developer. Updating it erases those changes, so they must be found first.
• The theme contains overrides, files that replace PrestaShop's original behaviour. They often stop working after a major version.

Run the official update tool

PrestaShop provides a dedicated module, the Update Assistant (formerly "1-Click Upgrade", or "autoupgrade"). It checks the requirements, backs up, replaces the files and updates the database. On the test copy:

1. install or update the Update Assistant to its latest version;
2. read its checklist and fix everything flagged in red before going further;
3. choose the target version;
4. launch the update and let it finish without closing the page;
5. clear the cache, then check the error log.

On a large store, the tool can also run from the server command line, which avoids a browser page stopping halfway.

For big jumps, go step by step

Jumping from 1.6 to 9 in one go is the best way to lose track of where an error comes from. I go in stages, checking the store at each step: 1.7, then 8, then 9.

For a store still on 1.6, an in-place upgrade is rarely the right choice. Themes and modules from that generation do not carry over to 8 or 9. Instead, a new store is built on the current version, then the catalogue, customers and orders are imported, keeping page addresses so the store does not lose its place on Google. I explain this in the guide on migrating to PrestaShop 8.

Test everything before switching

Once the copy is updated, I go through it as a customer, then as the merchant. The list is the same for every store:

• place a complete order with each payment method in test mode;
• check shipping costs for each carrier, at home and abroad;
• make sure order emails arrive, for the customer and for the store;
• search, filter a category, add to cart from a product page;
• in the back office, open an order, change its status, print the invoice;
• read the server error log after all these tests.

If everything is clean, the switch happens at a quiet time: back up the live store, apply the same update or replace it with the validated copy, then run the same tests, for real this time.

If something breaks

The rule is simple: you do not repair a selling store live. If an error appears after the switch, restore the backup, the store goes back to its previous state, and the cause is investigated calmly on the copy. That is exactly why the backup was checked at the start. If you are already in that situation, here is how I handle a PrestaShop store that is down.

How often should you update?

Security patches are applied as soon as they are released, after a quick pass on the test copy. Major versions are planned, once the modules you depend on are ready. Between the two, the most expensive option is doing nothing for years: you end up three versions behind, on a PHP version your host no longer provides, and the update turns into a rebuild.

If you would rather hand this over, I handle PrestaShop updates end to end, on a copy of your store, with the same method. For ongoing care, monthly maintenance includes security patches.