Migrating PrestaShop 1.6 to 9: what moves and what is rebuilt

Migrating a store from PrestaShop 1.6 to 1.7, 8 or 9 is not an update: it means moving the data (products, customers, orders, categories) to a new installation and rebuilding the theme, modules and custom changes, because those from 1.6 do not work in current versions. It is prepared on a copy, rehearsed and switched over on a low-traffic day.

Many stores are still on 1.6 because they work, and because every time someone asks about migrating, the answer is frightening. This article explains what it really involves, what can be reused and what cannot, and how to do it without losing sales or Google rankings. If your store is already on 1.7, the route is different and shorter.

What is the risk of staying on PrestaShop 1.6

The 1.6 branch stopped receiving maintenance years ago. In practice, that means:

• No security patches. Every flaw discovered in the core or in an old module stays open forever, and automated attacks look for exactly those stores.
• Unsupported PHP. 1.6 only runs on PHP versions that no longer receive updates. Hosting providers eventually withdraw them, and then the store stops starting or forces you to stay on an old server.
• Abandoned modules. Payment gateways, carriers and connectors stop releasing versions for 1.6. The day your bank changes its payment system, there may be no module that supports it.
• Performance and mobile. Themes from that era are not designed for today's speed requirements, and that shows in conversion and in search engines.

While you prepare the migration, a 1.6 store can be kept going with a few basic precautions: daily backups off the server, employees reviewed and with unique passwords, unused modules removed from the disk, alerts for changes to the payment configuration and error monitoring. It is a stopgap to buy time, not a solution.

Why there is no button from 1.6 to 9

Between 1.6 and 1.7, PrestaShop changed almost everything you can see and much of what you cannot: the theme system, the module structure, the back office (which began moving to Symfony) and the way custom code is hooked in. Versions 8 and 9 continued along that line and require much more recent PHP versions.

That is why a 1.6 theme cannot be installed on 1.7 or later, and neither can most 1.6 modules. The official upgrade assistant is for moving up versions along a supported path, but it does not convert a theme or rewrite a module. What does survive is what is in the database.

What is migrated and what is rebuilt

Two routes: upgrade in steps or migrate the data

In steps (1.6 → 1.7 → 8 → 9)

The installation is upgraded step by step with the upgrade assistant, changing the PHP version at each step. It makes sense when the store is clean, with few modules and hardly any changes to the core. At each jump you have to check that the database is in good shape, and the theme and modules still have to be replaced.

New installation and data migration

The target version is installed from scratch, with its theme and modules, and the data is brought over from 1.6. This is the route that usually works out better for stores with years of history: it does not drag along tables from modules that no longer exist, forgotten settings or files nobody knows the purpose of. It requires careful data mapping and repeating the load on switchover day with the new orders and customers.

There is no universal answer. What decides it is the state of the store: how many modules it has, how much custom code, how much the core was modified and how much data there is.

URLs and SEO: what you cannot lose

• List of current URLs. Before touching anything, extract every URL that receives visits or links: products, categories, CMS pages, brands and images if they rank.
• Same IDs and same friendly URLs wherever possible. If the URL patterns change between versions, they are adjusted to match or 301 redirects are prepared.
• Meta titles and descriptions migrated with the products and categories, not regenerated.
• Languages: if the store is multilingual, each language keeps its URLs and its alternate language tags.
• After the switch: crawl the new store looking for 404 errors, submit the sitemap and keep an eye on Search Console for a few weeks.

Timelines and testing on a copy

Timelines depend on the size and the theme, but the order is always the same:

1. Inventory: version, modules and how they are really used, overrides, integrations (ERP, marketplaces, carriers) and scheduled tasks.
2. Copy of the store in a test environment, protected and not indexed, with email diverted so as not to write to real customers.
3. Setting up the new version with its theme and modules, and a first data load.
4. Full testing: registration and login of an existing customer, orders with each payment method in test mode, emails, invoices, carriers, search and filters.
5. Rehearsal of switchover day, timed, to know how long the store will be in maintenance mode.
6. Switchover: final data load, redirects, change of domain or server and an immediate check of the checkout.

Skipping the rehearsal is what turns a one-day migration into a week of incidents.

How to solve it in PrestaShop

At Rekire we carry out PrestaShop migrations and updates on a copy of your store, never on production: inventory, setting up the new version, data loading, URL review and a rehearsal before switchover day. The work is done with bundles of hours: the 20-hour PrestaShop support bundle covers the inventory and small stores, and the 50-hour bundle covers migrations with more modules or custom code. Before we start, we tell you how many hours we estimate, and only the hours worked are deducted. Asking before your hosting provider withdraws your PHP version is far cheaper than migrating in a hurry.

Frequently asked questions

Can PrestaShop 1.6 be upgraded directly to 9?

Not in a single step. Either you upgrade in steps through the intermediate branches, or you install 9 from scratch and migrate the data. In both cases the theme and modules are replaced.

Will I lose orders and customers when migrating?

No, if it is done properly: orders, invoices, customers and addresses are moved with their IDs. What you need to check is that existing customers can log in and that invoice numbering continues.

Is it better to go to 1.7 or straight to 8 or 9?

If you are going to the effort of rebuilding the theme and modules, the sensible thing is to go to a supported version. 1.7 has also been left behind, and moving to it would mean migrating again before long.

How long is the store closed?

It depends on the volume of data, but if it has been rehearsed, the downtime is usually a matter of hours and at a low-traffic time. The rehearsal is precisely for knowing that time in advance.