PrestaShop 1.6 to 9: the widest gap in the catalogue
Migrating a PrestaShop shop straight from 1.6 to 9 doesn’t exist with the official tool: it’s the widest gap in the range, with a back office now entirely built on Symfony, a PHP 8.1 minimum, and a theme and almost all modules needing rebuilding. Over a gap this wide, I often recommend a redesign rather than a straight migration.
Why this migration is the heaviest of the lot
PrestaShop 9.0 moves the back office from Symfony 4.4 (the 8.x branch) to Symfony 6.4 LTS, entirely built on Symfony controllers and Twig: the last “legacy” admin controllers disappear. It also introduces a new admin API, built on API Platform with OAuth. The PHP minimum rises to 8.1, supporting 8.2, 8.3 and 8.4.
PrestaShop 1.6, by contrast, runs on a proprietary legacy framework, Smarty-only, works at best up to PHP 7.1: three architecture generations to cross (1.7, 8, 9), two theme changes, and a PHP jump from 7.1 to 8.1. Hummingbird appears in 9.0, but Classic stays default at that release: not a forced choice.
As with any PrestaShop migration, there’s no direct jump with autoupgrade: you go through 1.7, and in practice 8 too.
What typically breaks over a 1.6 to 9 gap
- A payment module written for displayPayment (1.6) no longer appears at checkout, that hook having been replaced by paymentOptions since 1.7.
- Almost every 1.6 module using the old curly-brace array syntax (e.g. $array{0}) throws fatal errors under PHP 8.1, that syntax removed in PHP 8.
- The 1.6 theme, Smarty-only and on Bootstrap 3, has no counterpart in the theme architecture introduced in 1.7 and still in place in 9: the front office is rebuilt, not adapted.
- Integrations relying on the previous admin API need checking against the new Admin API, built on API Platform and OAuth, introduced in 9.
How I approach a gap this wide
-
Full audit and a migrate-or-redesign decision
Modules, theme, custom development, rebuild workload: a redesign can cost less than a step-by-step migration.
-
Full backup, kept outside the migration tools
Files, database dump, module list with versions, payment/carrier configuration, before touching anything.
-
Going through the intermediate steps (1.7, then 8) if migration is chosen
Each step tested on a copy of the shop, never production, with its own sign-off before the next.
-
Rebuilding the theme and any custom admin work
Theme rebuilt on Classic (or adapted for Hummingbird), back-office development rewritten for 9’s admin.
-
Replacing incompatible modules
Working equivalents for modules that don’t migrate, or a rewrite.
-
Checking, then going live
Switch scheduled for a low-traffic window once approved.
Migrate or redesign: how I decide
A step-by-step migration means potentially rebuilding the theme more than once (a Classic base for 1.7 and 8, then checking compatibility with 9’s admin), and checking or rewriting every module at each step. A redesign starts from a fresh 9 install and carries over only the data. I recommend it when the theme is already old, custom modules are numerous, or the site hasn’t moved visually for a long time.
Either way, I back up the file tree, database dump, module list with versions, and payment/carrier configuration before starting. After the final switch, I check orders, customers and products match what existed before, URLs respond with the right code, redirects work, and I run a full test order via paymentOptions.
<compatibility>
<min>1.7</min>
<max>9.99.99</max>
</compatibility>To prepare for or complete this migration
- PHP 5.2 to 7.1 PrestaShop 1.6
- PHP 8.1 minimum, up to 8.4 PrestaShop 9
devdocs.prestashop-project.org
Describe your need in one minute
A few targeted questions so I can reply with an estimate rather than another questionnaire.