Migrating from PrestaShop 1.7 to 9 step by step: the plan that avoids surprises

A PrestaShop 1.7 to 9 migration goes well when switchover day is boring. For that to happen, everything difficult has to have been dealt with beforehand, on a copy, with time to make mistakes. This is the plan we follow, with the pitfalls we usually find in each phase.

1. Inventory: what your store does

Before touching anything, make two lists:

• Installed modules, with their version, author and whether they are enabled. Pull the list from the database so none slips through.
• Store functions: how payments are taken, how orders are shipped, how invoices are issued, what it connects to (ERP, marketplaces, carriers), what there is for SEO, which email automations.

For each function, decide what will handle it in PrestaShop 9: the same module updated, a replacement, something already built into the core, or nothing, because it is no longer used. It is common for a store with years behind it to discover that part of its modules are not needed.

Also review the override/ folder. Every override is code that modifies the core, and many classes have changed in PrestaShop 9. Anything that depends on an override has to be redone, ideally with hooks.

2. The local copy

Bring a full copy of the current store (files and database) to a test environment that is not on the same server as the live store and cannot send emails to customers. That last point matters: a copy with the real database and email configured can write to a real customer with a simple order status change.

Anonymise personal data if more people are going to handle the copy, and disable or switch to test mode the payment gateways, ERP connections and any cron job that talks to the outside world.

3. Choosing the route: upgrade or migrate data

There are two ways to get to PrestaShop 9:

• Upgrade the existing installation with the official assistant. It keeps everything, but it also drags along years of leftovers: tables from uninstalled modules, old configuration, overrides.
• A clean PrestaShop 9 installation and data migration: catalogue, customers, orders, addresses, CMS. More work at the start, but the new store only has what you decided to bring.

With a 1.7 that has many third-party modules, overrides and a heavily modified theme, the second usually causes fewer problems in the medium term. With a well-kept 1.7.8 and few modules, upgrading may be enough. Decide based on the copy, not on theory.

4. The data

When migrating data, check each type with numbers, not by eye:

• Products, combinations, specific prices, stock and images: the same count at source and destination.
• Customers, addresses and groups, with their discounts.
• Orders, with their statuses, invoices and credit slips. Invoice numbering must continue, not restart.
• Active cart rules and vouchers.
• CMS pages, categories with their descriptions and SEO metadata.
• Translations for every language.

Keep product and category IDs whenever you can: they make redirects, integrations and reports easier.

5. The theme

A 1.7 theme rarely works as is in PrestaShop 9. The usual options are to adapt it, build a child theme of the PrestaShop 9 default theme with your design, or choose a compatible commercial theme. Bear in mind that the theme is not just design: it also carries email templates, translated texts and sometimes its own modules. Review the store on mobile and desktop, page by page.

6. URLs and 301 redirects

If the URLs change, Google needs to know. Ideally keep the same URL structure; if that is not possible, every old URL with traffic or links must redirect with a 301 to its new equivalent, not to the home page. Get the list of old URLs from the sitemap, Search Console and the server logs, and check the redirects with a crawl before switchover day.

7. Payments in test mode

Every payment method is tested end to end in sandbox mode: successful payment, declined payment, cancelled payment, refund and, if you use it, payment with strong customer authentication. Check that the order is created with the right status and that the gateway notification arrives. In PrestaShop 9, modules that received those notifications in a direct .php inside modules/ may run into a 403, because the stock .htaccess denies those requests. It is one of the most common causes of "the customer paid and there is no order" after a migration.

8. The dress rehearsal

With everything ready, repeat the whole migration from a fresh copy of the live store, timing each step. The rehearsal serves three purposes: confirming the process is repeatable, knowing how long the store will be in maintenance mode and discovering what has changed in the live store since the first copy.

9. Switchover day

1. Give advance notice if there is going to be a maintenance window.
2. Put the old store into maintenance mode and stop its cron jobs and integrations.
3. Migrate the orders, customers and catalogue changes since the last copy.
4. In the new store, switch the gateways to live mode and turn on the ERP connections and cron jobs.
5. Point the domain to the new store and check the certificate.
6. Place a real order with each payment method and refund it.
7. Submit the new sitemap to Search Console and watch for 404 errors over the following days.
8. Keep the old store stopped and without public access for a while, in case you need to look something up.

What tends to break

• Overrides that no longer fit the core classes.
• Modules that do not install or do not show their configuration in PrestaShop 9.
• Cron jobs that pointed to module .php files and now get a 403 without anyone noticing.
• Email templates that revert to the defaults or lose translations.
• Invoice numbering that restarts.
• Images that need regenerating with the new formats and sizes.
• Analytics and pixels left behind on the old store.

And an advantage that gets forgotten: once finished, your store is on a supported version, with current PHP and up-to-date modules. From then on, keeping it updated is far less work than jumping several versions at once again.

How to solve it in PrestaShop

Migrations from 1.6 and 1.7 to PrestaShop 9 are a major part of our work at Rekire. With our support hours packs (20, 50 or 100 hours, depending on the size of the store) we handle the whole project or the part you need: inventory of modules and functions, a copy in a test environment with no outgoing email, data migration verified by numbers, theme adaptation, redirects, payment testing, rehearsal and support on switchover day. Hours are used according to the actual work.