# PrestaShop 1.7 to 9: Symfony 6.4 and overrides to rewrite

> Jumping straight from 1.7 to 9 means crossing Symfony 6.4, a PHP 8.1 minimum and a fully Twig back office all at once: a heavier leap than it looks.

- Source canonique : [https://allaux.fr/en/prestashop/migration/1-7-vers-9](https://allaux.fr/en/prestashop/migration/1-7-vers-9)
- Langue : EN
- Dernière mise à jour : 2026-09-30

## Direct answer

> Inventory the override/ folder first: in 9 the last legacy admin controllers are gone, and an override written for 1.7 fails at load time instead of warning you. Allow for a jump from PHP 7.4 to PHP 8.1 as a minimum, with no overlap between the two, so the hosting has to be ready before you switch, not after.

## What changes between 1.7 and 9

Between PrestaShop 1.7 and 9, the gap is a generation change, not just a version number. 1.7 runs a hybrid architecture: part of the back office and some front controllers on Symfony, the rest on plain Smarty with legacy admin controllers. PrestaShop 9 removes those: the back office now runs entirely on Symfony and Twig, and Symfony itself jumps to 6.4 LTS, against a much older 1.7/8 base. On PHP, 1.7 tops out at 7.4, while 9 needs 8.1 minimum and supports 8.2 to 8.4: no overlap between the two ranges.

PrestaShop 9 also adds a new Admin API, built on API Platform with OAuth authentication. On themes, 9 introduces Hummingbird, but Classic stays default at release: no mandatory rebuild, unlike 1.6-to-1.7.

The database structure changes at every major version; here, two steps (1.7 to 8, then 8 to 9) need covering by autoupgrade’s update scripts, whether run as one operation or two.

## What breaks on a gap this size

- A module relying on a legacy Smarty admin controller finds that controller gone in 9: it doesn’t crash, it disappears.
- A core method override for 1.7 ignores the return types required since PHP 8.1: fatal error, not a warning.
- A module using curly-brace syntax for an array or string ($array{0}) stops running under PHP 8.1 or later.
- An integration built against the old web service API isn’t designed for the Admin API’s OAuth and needs revisiting.
- A module whose config.xml only declares compatibility up to 8 is rejected at install time on a 9.

## How I approach this jump

1. **Audit and route decision** — I list modules, controller and back-office overrides, and integrations using the web service API, then decide how to split the work. autoupgrade steps through each version in turn and skips none: the update scripts for every intermediate version run either way, so the only question is whether I let them run in a single pass or stop at 8 to check the shop, especially with legacy modules still in use.
2. **Independent full backup** — A full SQL dump and complete file copy before anything else, plus autoupgrade’s own internal backup, kept off the server being changed.
3. **Migration on a copy of the shop** — The whole procedure is rehearsed on a test environment with target PHP in place, so return-type errors and missing controllers show up before they touch the live site.
4. **The point of no return: running the database scripts** — Once the schema scripts start running, only restoring the dump taken beforehand allows a clean rollback, triggered once modules and overrides are fully validated on test.
5. **Rewriting legacy controllers and modules** — Admin controllers still on Smarty and the modules depending on them are rewritten for the 9’s Symfony/Twig architecture, not just updated.
6. **Going live** — Once the test version is approved and target PHP confirmed, I schedule the switch for a low-traffic window.

## What I back up before touching anything

> A full SQL dump, complete file copy, list of active modules with versions, and an inventory of controller or back-office template overrides: those need the most rewriting, not just updating.

## How I check afterwards

I compare order, customer and product volumes between old and new databases after each step. I test checkout on every payment method, that rewritten controllers work for each back-office profile, and that no API integration is stuck on the old authentication. I watch the PHP error log during the first days, particularly return-type errors surfacing only when a rarely used feature gets exercised.

## Related pages

- **PrestaShop migration from 1.7 to 8** — The first step before 9, for module ecosystems not ready for a direct jump. ([/prestashop/migration/1-7-vers-8](/prestashop/migration/1-7-vers-8))
- **PrestaShop migration from 8 to 9** — The second step, once PHP 8 compatibility is in place. ([/prestashop/migration/8-vers-9](/prestashop/migration/8-vers-9))
- **Incompatible modules after a migration** — Why a module that used to work crashes or disappears after an update. ([/prestashop/migration/modules-incompatibles](/prestashop/migration/modules-incompatibles))
- **Checklist before a migration** — What to check and back up before a migration. ([/prestashop/migration/checklist-avant-migration](/prestashop/migration/checklist-avant-migration))

## FAQ

### Do I have to go through version 8 before 9?

Not as a compulsory stop, no: autoupgrade steps through each version in turn and skips none, so the 8 scripts run even when you target 9 directly. But the bigger the gap, the more update scripts run in a single pass, and the longer the risk window. I decide case by case whether stopping at 8 reduces the risk.

### Will my custom Smarty admin controllers keep working on 9?

No, not as they are. PrestaShop 9 removes the last legacy admin controllers: any back-office controller still on Smarty must be rewritten for the 9’s Symfony/Twig architecture; it doesn’t update itself.

### How long does a jump like this take?

Noticeably longer than a plain 1.7-to-8 update: audit, legacy controller rewrites and testing on a copy add up to weeks rather than days once there’s admin customisation.

### Will my SEO be affected?

Not by the version change itself, if URLs and page structure are kept. I watch redirects closely throughout the operation, especially in two steps.