PrestaShop 8 to 9: legacy controllers gone, new Admin API
Moving from PrestaShop 8 to PrestaShop 9 is a major-version change: the back office moves entirely onto Symfony 6.4, the last legacy controllers disappear, and administration opens up to a new API. This isn’t an update you run on a Friday evening without preparation.
What actually changes between PrestaShop 8 and 9
PrestaShop 8.x partly runs on Symfony 4.4 for pages already migrated, the rest still on legacy controllers. PrestaShop 9.0 changes the Symfony branch entirely: a move to Symfony 6.4 LTS. The back office is now built entirely on Symfony controllers and Twig: the last legacy controllers from 8.x no longer exist in 9.0.
On the PHP side, 9.0 requires PHP 8.1 as a minimum and supports PHP 8.2, 8.3 and 8.4, whereas the 8.1 branch stopped at PHP 8.1. On older hosting, migrating also means a PHP upgrade.
9.0 also introduces the Admin API, on API Platform with OAuth authentication, separate from the older Webservice API, plus experimental access to a Symfony container on the front office. On the theme side, it introduces Hummingbird, but Classic remains default: a shop that stays on Classic doesn’t need to change theme to migrate.
Signs a module will cause trouble in 9.0
- The module adds a tab or widget to the back office by relying on a legacy controller.
- Its listing or documentation mentions no 9.0 compatibility, nor an up-to-date <code><max></code> tag in <code>config.xml</code>.
- A custom override calls a legacy class or controller directly rather than a Symfony service.
- The module uses the older Webservice API for external integrations (ERP, marketplace, price comparison).
Why these things break specifically
The disappearance of the last legacy controllers is the most direct issue: a module or override that targeted one in 8.x has no target left in 9.0, the route or class simply gone. This isn’t a soft compatibility issue, it’s a plain absence.
Symfony’s major-version jump, from 4.4 to 6.4, is the second friction point. A module declaring its own Composer dependencies, say a third-party library pinned to a specific version, can conflict with the Symfony 6.4 used by the PrestaShop 9.0 core. The conflict usually shows up as soon as dependencies are installed, before the module even runs.
Finally, the compatibility declaration needs to be current: the <compatibility><min></min><max></max></compatibility> tags in config.xml and the $ps_versions_compliancy property both need to cover 9.0. A module never updated for 9.0 is, by definition, risky, even if it still works on 8.x.
How I run a PrestaShop 8 to 9 migration
-
Audit of modules and overrides
Module by module, I check declared 9.0 compatibility in config.xml and $ps_versions_compliancy, plus overrides targeting legacy controllers.
-
Full backup before any attempt
Files and full database export, independent of the backup autoupgrade takes itself during migration.
-
Migration on a copy of the shop
I run autoupgrade on a copy, never on production, to see real errors before committing to a deadline.
-
Running the database migration script
The point of no return: once autoupgrade transforms the schema into the 9.0 structure, reverting means restoring the full backup, not undoing the last step.
-
Fixing broken modules and overrides
I replace or rewrite modules targeting a now-gone controller, and resolve Composer conflicts found during the audit.
-
Verification and go-live
I check catalogue, orders, customers and transactional emails in test before switching production over at low traffic.
Related reading
-
Checklist before any migration
What to check before starting a migration, whatever the target version.
-
Incompatible modules
How to spot a module that won’t migrate as-is, and what to replace it with.
-
Keeping your SEO
What I watch on URLs to avoid losing acquired rankings.
-
Moving to PHP 8
The PHP upgrade that often comes bundled with a recent migration.
Describe your need in one minute
A few targeted questions so I can reply with an estimate rather than another questionnaire.