# PrestaShop 1.7 to 8: PHP 8 and a TypeScript back office

> The most common upgrade today: PHP 8 compatibility, admin JavaScript migrated to TypeScript, and modules that need checking one by one before anything is touched.

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

## Direct answer

> Treat it as two separate jobs: the move to 8, then the move to PHP 8. Before starting, open each module config.xml to read its upper compatibility bound, plus the $ps_versions_compliancy property in its main class: a module frozen on 1.7 stays greyed out after the update. Review any bespoke admin scripts too, since back office JavaScript moved to TypeScript.

## What actually changes between 1.7 and 8

Technically, the 1.7-to-8 jump is less radical than 1.6-to-1.7: the hybrid Smarty/Symfony architecture and Classic theme stay in place. What really changes is PHP compatibility: PrestaShop 8 needs PHP 7.2.5 minimum, supports 8.0 and 8.1 from launch, then 8.2 from version 8.2 (September 2024). No 1.7.x version runs under PHP 8, Smarty crashes immediately: migrating to 8 almost always means raising PHP alongside PrestaShop, multiplying failure points.

On the back office side: admin JavaScript migrates to TypeScript from 8.0, and custom overrides or scripts built for 1.7 no longer plug in the same way. Many core methods now also declare a return type, a consequence of PHP 8.1: an override that doesn’t match that signature triggers a fatal error, not a warning.

The database structure also changes at every major version: new tables, renamed columns. Restoring a raw SQL dump as-is on a fresh 8 isn’t reliable; autoupgrade runs the matching update scripts.

## Modules and functions that cause trouble

- The back office throws a fatal error at first access after PHP 8.1, from a missing return type on an overridden method.
- A module installed under 1.7 is missing or greyed out after the update, since config.xml doesn’t declare compatibility with 8.
- A custom module still uses curly-brace syntax for arrays or strings ($array{0}), removed in PHP 8: the page crashes with a syntax error.
- A custom back-office script or override stops working because of the JavaScript-to-TypeScript move in the admin.
- A module’s $ps_versions_compliancy property, frozen on the old version, blocks activation even though the code would work unchanged.

## How I run this migration

1. **PHP and module audit** — I check the current and target PHP version, and list modules with compatibility declared in config.xml and $ps_versions_compliancy.
2. **Independent full backup** — Database dump and full file copy before anything, plus the internal backup autoupgrade creates itself.
3. **Migration on a copy of the shop** — Autoupgrade first runs on a test environment: file and database backup, then the schema update scripts.
4. **The point of no return: the database update** — Once the database scripts start running, going back isn’t a matter of undoing files: only restoring the dump taken beforehand allows a clean rollback, triggered only once files and modules are confirmed ready.
5. **Fixing modules and overrides** — I update or replace modules blocked by outdated compatibility or the curly-brace syntax removed in PHP 8, and adapt back-office overrides affected by TypeScript.
6. **Going live** — Once the test version is approved, I schedule the switch for a low-traffic window, PHP included, to limit impact on orders.

## What I back up before touching anything

> A full SQL dump (not just autoupgrade’s own backup, in /autoupgrade/backup), a full copy of every file, and the list of active modules with versions. Backups kept off the server being changed.

## How I check nothing was lost afterwards

After going live, I compare orders, customers and products between old and new databases. I test the full checkout flow on every payment method, the key front pages (home, category, product) and back-office access. I also check the PHP error log during the first hours: that’s usually where overrides missing a return type show up.

## Related pages

- **Checklist before a migration** — What to check and back up before any migration. ([/prestashop/migration/checklist-avant-migration](/prestashop/migration/checklist-avant-migration))
- **Incompatible modules after a migration** — Why a working module crashes or disappears after an update, and how to check compatibility. ([/prestashop/migration/modules-incompatibles](/prestashop/migration/modules-incompatibles))
- **Moving PrestaShop to PHP 8** — What a hosting PHP version change involves, regardless of PrestaShop version. ([/prestashop/migration/passer-a-php-8](/prestashop/migration/passer-a-php-8))
- **PrestaShop migration from 8 to 9** — The next step once the shop is stable on 8. ([/prestashop/migration/8-vers-9](/prestashop/migration/8-vers-9))

## FAQ

### Do I need to be on the latest 1.7.8 sub-version before moving to 8?

Not strictly required, but the most tested setup for autoupgrade: I check your 1.7 install first, and update it to the latest 1.7 sub-version if needed.

### Will the new back office’s TypeScript break my admin customisations?

Only with custom JavaScript scripts or overrides built for the back office. Standard admin behaviour isn’t affected; custom code needs adapting.

### How long does a 1.7 to 8 migration take?

Mainly on the number of modules and custom overrides. A shop with few modules and a standard theme migrates in days; heavier customisation takes longer.

### Does my hosting need to change before migrating?

Usually yes. I check the host’s PHP version against what PrestaShop 8 needs; if it’s missing, I flag that change first.