# PrestaShop 8.0 to 8.2: 8.1 moves Vue 2 to Vue 3 > Moving from PrestaShop 8.0 to 8.2 looks like a minor update: same major branch, same default theme, same database structure. That’s misleading. In between sits version 8.1, which moved the back office from Vue.js 2.6 to Vue.js 3.2 — and that’s exactly what breaks custom back-office JavaScript. - Source canonique : [https://allaux.fr/en/prestashop/migration/8-0-vers-8-2](https://allaux.fr/en/prestashop/migration/8-0-vers-8-2) - Langue : EN - Dernière mise à jour : 2026-09-30 ## Direct answer > The turning point is 8.1, which moves the back office from Vue.js 2.6 to 3.2: start by listing the modules and custom work that add an admin screen or component, because those are the only things genuinely at risk. Between 8.0 and 8.2 the front office, the Classic theme and the table structure stay put. ## What actually changes between 8.0 and 8.2 PrestaShop 8.0 requires PHP 7.2.5 as a minimum and adds support for PHP 8.0 and 8.1. The JavaScript of pages already migrated is written in TypeScript, and many methods now declare a return type due to PHP 8.1 compatibility. In between sits version 8.1, released June 2023: it moves Vue.js from 2.6 to 3.2 in the back office, adds multi-shop compatibility on the customer page, and introduces new security features. PrestaShop 8.2, released September 2024, brings full PHP 8.2 support, plus performance and security fixes. The 8.2.x branch is then the only one in the 8 series still receiving critical bug and security fixes; the publisher has not announced an end date for that support. On paper, 8.0 to 8.2 stays within the same major branch: the numbering suggests a minor update. In practice, this path crosses a major-version change in Vue.js, a framework whose internal API isn’t compatible across major versions for anything that manipulates its components directly. ## Why a “minor” update breaks the back office Vue 2 and Vue 3 don’t share the same internal API for defining and manipulating components. A custom admin widget, or a module adding a tab by relying directly on Vue 2 components, stops working once the back office moves to Vue 3: it isn’t a configuration issue, the code that manipulated Vue 2 simply has no direct equivalent left. This sets this version pair apart from a plain security update: the number suggests a minor change, but going through 8.1 carries a real technical break for anything touching the admin interface. On catalogue, orders and the public front office, the impact is generally low. The database structure doesn’t change between 8.0 and 8.2, and the public theme isn’t affected by this JavaScript change. The risk is concentrated on admin JavaScript and modules touching it directly. ## Signs a customisation will break going through 8.1 then 8.2 - A module adds a custom tab or widget by directly manipulating Vue.js components. - A custom development calls Vue 2’s internal API (options API, mixins) rather than an official PrestaShop extension point. - The module hasn’t been updated since before June 2023, when 8.1 was released. - The module’s documentation states no compatibility beyond 8.0. ## How I run this minor-looking migration 1. **Audit of back-office customisations** — I identify modules and custom developments touching the admin interface: added tabs, widgets, custom JavaScript. 2. **Backup of files and database** — Full backup before any operation, on top of the one autoupgrade takes itself in /autoupgrade/backup. 3. **Migration on a copy of the shop** — I run the copy through 8.1 then 8.2 with autoupgrade, to pinpoint exactly which step a customisation stops working at. 4. **Running the update** — The point of no return: once confirmed by autoupgrade, reverting means restoring the full backup rather than undoing the step. 5. **Fixing broken admin JavaScript** — I rewrite customisations that manipulated Vue 2 components to adapt them to Vue 3, or replace them with an official extension point where possible. 6. **Verification and go-live** — I check the back office first (tabs, widgets, forms), then catalogue and orders, before switching production over. ## The catalogue and front office are rarely affected > Most of the risk sits on the back-office side and modules touching it: catalogue, orders and public theme are generally unaffected by the Vue 2 to Vue 3 change. ## 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)) - **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)) - **PrestaShop 8 to 9 migration** — The next step once 8.2 is stable: Symfony 6.4 and the disappearance of the last legacy controllers. ([/prestashop/migration/8-vers-9](/prestashop/migration/8-vers-9)) ## FAQ ### Why would a minor update like 8.0 to 8.2 break anything? Because version 8.1 sits in between, moving the back office from Vue.js 2.6 to Vue.js 3.2. The number stays within the same major branch, but this framework change genuinely breaks customisations that directly manipulated Vue 2 components. ### Should I worry about my catalogue or orders? Generally not: the database structure doesn’t change between 8.0 and 8.2, and the public theme isn’t affected. The risk is concentrated on administration. ### Can I go straight from 8.0 to 8.2 without passing through 8.1? Autoupgrade handles the chain of successive updates. I still test on a copy of the shop to check no customisation breaks while passing through 8.1. ### Why migrate to 8.2 at all if it’s risky for administration? Because 8.2.x is the only branch in the 8 series still receiving critical bug and security fixes. Staying on 8.0 exposes you to unpatched flaws, generally a bigger risk than fixing a handful of admin customisations.