Updating PrestaShop without breaking your store: step by step

To update PrestaShop without breaking the store, always follow the same order: a full backup of files and database, a rehearsal of the update on a copy of the store, the real update during a low-traffic window and a review of checkout, email and modules before calling the job done. The official assistant does the mechanical part; what prevents nasty surprises is everything around it.

This article is about «maintenance» updates: within the same branch (8.1 to 8.2) or to the next minor version (9.0 to 9.1). A jump from 1.6 or 1.7 to 9 is something else, a migration project, and we cover it separately.

Updating or migrating: not the same thing

They are used as synonyms but they are not, and mixing them up leads to poor planning:

• Updating means replacing the PrestaShop core with a newer version on the same store. The data, theme and modules stay; the database is adapted by the new version's scripts.
• Migrating means moving the store to a version with fundamental changes (or to another server), where the theme, some of the modules and the overrides are rebuilt and what is kept is mainly the data.

Between close versions, updating is normal and advisable. The longer you go without doing it, the more each update looks like a migration: more modules without a compatible version, more accumulated changes in the theme and a bigger gap in the PHP version.

Before touching anything: the inventory

Ten minutes of inventory saves hours on update day. Write down:

• Current PrestaShop and PHP versions, and which PHP version the target version requires. Check that version's requirements first: if the server does not meet them, the PHP change comes first, also tested on a copy.
• Theme: whether it is the default one, a child theme or a purchased theme, and whether anyone has edited its templates directly.
• Third-party modules, with their version and whether the author states compatibility with the target version.
• Overrides in the override/ folder: each one is code that replaces part of the core and may stop fitting.
• Manual changes to core files: lines added in config/, rules in the .htaccess, password protection on the admin folder. The update overwrites them.
• Integrations that call the store: ERP, marketplaces, carriers, the webservice.

The full backup, and tested

The upgrade assistant offers to make its own backup, and it is fine for it to do so, but it should not be the only one. Before starting, make your own backup of all files and the database, store it off the server and check that it can be restored. A backup nobody has ever restored is a hope, not a backup.

The rehearsal on a copy of the store

The rule that prevents the most trouble: the update is done first on a copy, on another server or in a local environment, with the same files and the same database as production. That is where you see which module fails, which theme template throws an error and how long the process takes, which is the figure you need to choose the right time slot.

On the copy, it is wise to disable everything that could reach the outside world: email (sent to a test mailbox, not to your customers), payment gateways (in test mode), scheduled tasks that talk to third parties and integrations that send orders to the ERP. A copy of the store with real email configured can write to real customers with a simple order status change.

During the update: what we have seen fail

PrestaShop's official assistant (the 1-click upgrade module) works well in most stores, but some situations keep recurring in real stores:

• Closing the browser halfway. The assistant advances in steps from the back office page itself. If the tab is closed or the connection drops, the process stops. Leave the computer connected and untouched until it finishes; if it is interrupted it can be resumed from the command line, but it is better not to get there.
• Integrations that keep calling. Maintenance mode hides the store from customers, but it does not cut off the webservice. An ERP that keeps syncing during the update can regenerate the cache while the assistant deletes it, and the process stops. Pause integrations before starting.
• Low memory on the command line. On some hosting, command-line PHP has less memory than web PHP. If the update is run from the command line, check that limit first.
• Core files replaced. The update replaces files such as config/config.inc.php or the .htaccess of the admin folder. Anything added there by hand disappears without warning, including password protection for the panel. Save it beforehand and put it back afterwards.
• Incomplete database. In some minor version upgrades we have seen the updated store lack tables or settings that a fresh installation of that version does have, and the storefront failed on many pages. That is why the rehearsal has to go through the whole store, not just the home page.

When it finishes, it is normal for the back office to log you out: you have to log in again.

After updating: the checklist

An update is not finished when the assistant says it went well, but when you have checked this:

How often to update

Maintenance releases fix bugs and, often, security issues. The healthy approach is not to let too much time pass after a release in your branch comes out, with the usual rehearsal beforehand. A store that is updated regularly has small, predictable updates; one that is touched every few years accumulates changes and every update becomes a project.

The same goes for modules and PHP: keeping up to date bit by bit is cheaper than catching up all at once. If the store has not been touched for a while, the prudent thing is to start with a review that says what is installed and what order to follow.

When to ask for help

A minor update on a store with the default theme and few modules can be done by someone experienced with the back office, always with a backup and a rehearsal. It is best done by a technician when there are overrides, a heavily customised theme, ERP or marketplace integrations, or an order volume that cannot afford the store failing for even a morning. In the PrestaShop migrations and updates service we rehearse on a copy, tell you what breaks before touching production and leave the store checked. And if you prefer someone to take care of this regularly, PrestaShop maintenance includes updates with their backup and checks.

Frequently asked questions

Can PrestaShop be updated without losing data?

Yes. An update keeps products, customers and orders, because it adapts the existing database. Even so, always make a full backup first: it is what protects you if the process is interrupted.

How long does a PrestaShop update take?

It depends on the size of the store and the server. The rehearsal on a copy gives you the real time, and with it you choose a low-traffic window to do it in production.

Do I have to update the modules too?

Usually yes, especially those the author marks as compatible only with specific versions. Check each one's compatibility before updating the core.

What do I do if the update fails halfway?

Do not run it again blindly. Check which step it stopped at: sometimes it can be resumed, and if not, restore the backup and repeat the rehearsal to find out what stopped it.