# 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. - Source canonique : [https://allaux.fr/en/prestashop/migration/8-vers-9](https://allaux.fr/en/prestashop/migration/8-vers-9) - Langue : EN - Dernière mise à jour : 2026-09-30 ## Direct answer > List your external integrations first: 9 adds the Admin API built on API Platform with OAuth authentication, so an ERP or marketplace wired to the old Webservice API has to be re-checked. Then look at which modules add an admin tab: those going through a legacy controller simply disappear, as those controllers no longer exist in 9.0. ## 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 tag in config.xml. - 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 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 1. **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. 2. **Full backup before any attempt** — Files and full database export, independent of the backup autoupgrade takes itself during migration. 3. **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. 4. **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. 5. **Fixing broken modules and overrides** — I replace or rewrite modules targeting a now-gone controller, and resolve Composer conflicts found during the audit. 6. **Verification and go-live** — I check catalogue, orders, customers and transactional emails in test before switching production over at low traffic. ## What I back up precisely before running autoupgrade > Besides my own file and database backup, autoupgrade drops its own in /autoupgrade/backup before any change, allowing a restore if the database update fails before being confirmed. ## Related reading - **Checklist before any migration** — What to check before starting a migration, whatever the target version. ([/prestashop/migration/checklist-avant-migration](/prestashop/migration/checklist-avant-migration)) - **Incompatible modules** — How to spot a module that won’t migrate as-is, and what to replace it with. ([/prestashop/migration/modules-incompatibles](/prestashop/migration/modules-incompatibles)) - **Keeping your SEO** — What I watch on URLs to avoid losing acquired rankings. ([/prestashop/migration/conserver-son-referencement](/prestashop/migration/conserver-son-referencement)) - **Moving to PHP 8** — The PHP upgrade that often comes bundled with a recent migration. ([/prestashop/migration/passer-a-php-8](/prestashop/migration/passer-a-php-8)) ## FAQ ### Do I also need to upgrade PHP to move to 9.0? If your hosting runs an older version than 8.1, yes: 9.0 requires PHP 8.1 minimum, up to PHP 8.4. I check the version with your host before planning. ### Is the new Hummingbird theme compulsory in 9.0? No. Hummingbird is introduced with 9.0 but Classic remains default at release. A shop already on Classic doesn’t need to change theme. ### Will all my modules work after the migration? Not automatically. I check declared compatibility in config.xml module by module, and replace or rewrite the ones targeting legacy controllers gone in 9.0. ### What happens if the migration fails partway through? Before the database update, I hold a full backup of files and database, in addition to autoupgrade’s own. If the step fails before confirmation, restoring is still possible.