PrestaShop 8 Migration from 1.7: What to Check Before You Update

A PrestaShop 8 migration starts with checks, not with clicking „Update”. Before you move off version 1.7, check the PHP version on your server and make sure your modules and theme are compatible. Then make a full copy of the store and test the whole process on that copy. Only when the test runs without errors do you plan the update of your live store. Not before.

Is a PrestaShop 8 migration just a regular update?

No. A new major version is not a patch you install on a Friday afternoon (tempting as that is). The database structure changes, some features are replaced by others, and older add-ons can simply stop working. You have two options: update the existing store or move your data to a fresh installation. The official PrestaShop migration documentation describes the second path as the way out for stores that can’t be updated smoothly. When does that make sense? Mostly when the store is heavily customised or the data comes from custom SQL queries or from a completely different system.

Which PHP version does PrestaShop 8 need?

PrestaShop 8 needs a newer PHP version than many 1.7 stores are still running on. So the first step is simple: check what your hosting has. You’ll find the version in your hosting panel or in the configuration information in the store’s admin panel. Compare it with the official system requirements for the new version, not with what someone wrote on a forum three years ago. Oh, and switching PHP also affects your current modules. Some of them will break on a newer interpreter. That’s why you test the PHP switch together with the update, on the copy. Never on the live store.

Module compatibility: which add-ons survive the PrestaShop 1.7 update

Every active module needs to be checked for declared compatibility with PrestaShop 8. Replace or disable unsupported ones before the update. In practice, a simple checklist is enough:

• a list of all installed modules with their versions,
• information from the developer about compatibility with the new store version,
• whether updates are available and the licence is still valid,
• unused add-ons that are worth simply removing.

Where should you start? With payment, shipping and wholesaler integration modules. If one of them fails, sales stop right away, not „at some point”. And what if an add-on has no version compatible with the new store? Then licensed modules with updates and support can save the day, or a custom-built module, for example from K4.pl.

Store theme and custom code changes

In my view, the theme and overrides are the main cause of errors after an update. You need to check their compatibility or plan a switch to the default theme from the start. A quick definition: an override is a file that changes how a PrestaShop class or controller works without touching the core. A good solution, until you change versions. Then these tweaks often no longer fit the new code. The migration documentation states plainly that moving data to the new version means losing your live store’s theme and switching to the classic theme. So the store will look different, and your own template will have to be adapted or rebuilt from scratch. That’s why, before the update, you should list every change in core files, overrides and templates. Every single one.

Backup and testing on a store copy step by step

Before the update, make a full backup of the files and the database. Run the whole process first in a test environment, meaning on a copy of the store, not on production. The order looks like this:

1. Back up all store files and the database.
2. Set up a copy of the store on a subdomain or a separate server.
3. Change the PHP version on the copy.
4. Update modules to versions compatible with the new store.
5. Update the store itself.
6. Test the checkout path, payments, email sending and the admin panel.

After the test, review orders, the cart and product images, including product image compression. Also take a look at redirects for disabled products, because newer versions give you more options here, including a redirect to a category. And two things that are easy to forget: block search engines from indexing the copy and make sure the copy doesn’t send emails to real customers. Nobody likes getting a confirmation for an order they never placed.

When the update fails: migrating data to a new installation

The update on the copy doesn’t go through? Oh well. You set up a clean PrestaShop 8 and move your data into it. Here the built-in CSV import beats loading data with a MySQL client, because it fills in default values for missing columns on its own. You can skip unnecessary columns with the Ignore this column option. One warning: don’t overwrite the tab table in the new store, which stores the admin panel controllers. PrestaShop manages that table, so leave it that way. And if the data came in some other way than through the import feature, images may go missing, so you’ll need to copy them from the old store.

A safe PrestaShop 8 migration without downtime rests on three things: a copy of the store, a verified PHP version and a list of modules with confirmed compatibility. Got them ready? Then updating production basically becomes a repeat of a scenario that has already worked once.

Frequently asked questions