Structured product data means every product fact lives in a typed attribute with a unit, a stable id…
PrestaShop 8 to 9 Upgrade Without Replatforming: Decouple the Frontend
You can take most of the risk out of the PrestaShop 8 to 9 upgrade by moving the storefront off the PrestaShop theme before you touch the core. Once the frontend talks to PrestaShop through an API instead of templates and display hooks, theme rebuilds and front office module breakage are no longer part of the upgrade. What remains is a backend upgrade you can test, schedule and roll back on its own.
What actually changes between PrestaShop 8 and 9
PrestaShop 9.0 was released on June 10, 2025, and it is a real major version. The core moved from Symfony 4.4 to Symfony 6.4, the long-term support line with security updates until November 2027. PHP requirements shift as well: PrestaShop 8.0 to 8.2 runs on PHP 7.2 to 8.1, while PrestaShop 9 requires at least PHP 8.1 and supports PHP 8.4. PrestaShop 9.1 extends support up to PHP 8.5.
The developer notes are long: back office controllers must be defined as services, and bundled libraries such as Guzzle and Swift Mailer were replaced by Symfony components. PrestaShop itself states that some modules and themes may require updates to work correctly.
The storefront changes too. With PrestaShop 9.1, released on March 23, 2026, Hummingbird 2.0 became the default front office theme. It is built on Bootstrap 5, and the developer documentation marks Classic as deprecated for new development. Existing shops can keep Classic for now.
Meanwhile, PrestaShop 8.2 has been in extended support since July 2025. It only receives critical and security fixes, and maintenance ends when PrestaShop 10.0.0 is released. The upgrade is not an emergency, but it belongs on your roadmap.
Why the storefront carries most of the upgrade risk
In a classic PrestaShop setup, the front office is where years of customization live: a purchased or heavily modified theme, plus modules that inject markup through display hooks, such as sliders, reviews, badges and cross-selling blocks.
That creates a chain of dependencies in the upgrade:
- The theme has to be checked, patched or rebuilt for PrestaShop 9, and a move toward Hummingbird means a Bootstrap 4 to 5 migration.
- Every module that renders in the front office needs a PrestaShop 9 compatible version, and its templates have to fit the theme.
- Overrides and child theme changes need to be reapplied and retested.
- SEO markup, tracking and Core Web Vitals have to be validated again after the switch.
Because theme and backend are coupled, the new core and the adapted storefront have to go live together.
Three options PrestaShop merchants are weighing
Most teams facing the upgrade end up comparing three paths:
- Upgrade in place. Update core, theme and modules together, with the highest coordination effort in one release window.
- Replatform. Move to another commerce system. Right if PrestaShop no longer fits your business model, but it replaces catalog, order flows and integrations at once.
- Decouple first. Keep PrestaShop as the commerce backend, move the storefront to a decoupled frontend, then upgrade the core behind it.
If what really holds you back is the storefront and not the backend, option three is a much smaller project. We described the mechanics in replatforming a PrestaShop frontend without touching the backend.
How a decoupled frontend changes the upgrade
With a composable headless frontend, the storefront no longer renders PrestaShop templates. It reads products, prices, cart and customer data through APIs and renders them in its own component layer. PrestaShop stays the system of record for catalog and orders.
For the 8 to 9 upgrade, that changes the scope:
- Theme risk disappears from the customer path. There is no Classic or Hummingbird theme to rebuild in front of shoppers, and Bootstrap versions in the front office theme stop affecting what they see.
- Display module risk shrinks. Content blocks, sliders and badges that used to come from front office modules live as components in the frontend. You maintain them once, independent of the core version.
- The upgrade becomes testable. Your frontend depends on an API contract. You upgrade PrestaShop in staging, run the same API calls against version 8 and version 9, and compare the results before you switch.
- Marketing keeps shipping. Campaigns are built in the frontend layer, for example in Laioutr Studio's visual editor, so a backend freeze does not freeze the storefront.
There are limits. Modules with business logic, such as payment, shipping, tax or ERP connectors, still run inside PrestaShop and still need PrestaShop 9 compatible versions. PrestaShop 9 also introduces a new Admin API built on API Platform, which the project describes as a work in progress and which is meant to eventually replace the existing Web Services. Check which API your frontend relies on and make it part of your upgrade tests.
Laioutr is built for this layer. As a Frontend Management Platform, it sits on top of existing commerce systems, works with 50+ backends and treats performance as a platform property: live Laioutr storefronts reach a median LCP of 1.2 s, with targets of INP under 80 ms and CLS under 0.02. How this looks for PrestaShop is outlined on the headless frontend for PrestaShop page. Whether a ready-made connector or a project-specific setup through Orchestr fits your shop is something we clarify in the demo.
A sequencing plan for the upgrade
Decoupling works best as a sequence. For seasonal businesses, the order also decides how much peak season risk you carry, a point we covered in big bang or progressive frontend migration.
- Audit your modules. Split them into front office display modules, which move into the frontend, and business logic modules, which stay in PrestaShop and need a version 9 check.
- Plan the decoupled frontend against PrestaShop 8.2. Build and test the new storefront against your current backend, which keeps receiving security fixes. Use the old theme's Core Web Vitals as your baseline.
- Freeze the API contract. Document the endpoints and data your frontend relies on and turn them into automated checks.
- Prepare the platform. PHP 8.1 is supported by both PrestaShop 8.2 and 9, so you can move the server to PHP 8.1 before the core upgrade and isolate that change.
- Upgrade the backend in staging, then go live off season. Update to PrestaShop 9 with the Update Assistant, update the remaining business modules and run the API checks. Shoppers keep the same storefront, and if something fails, you roll back the backend without touching the frontend.
One risky release becomes several smaller ones, each with a rollback path.
FAQ
Do I have to upgrade to PrestaShop 9 right away?
No. PrestaShop 8.2 receives critical and security fixes until PrestaShop 10.0.0 is released. Use that window to decouple the frontend first.
Does a decoupled frontend remove all module risk?
No. It removes the risk tied to the front office theme and to modules that render inside it. Payment, shipping, tax and ERP modules still run in PrestaShop and need compatible versions for PrestaShop 9.
What happens to SEO when the storefront changes?
URLs, redirects, structured data and metadata need a migration plan, as with any theme change. The difference: you do it once, in the frontend, not again with every theme update.
Is this only relevant for large shops?
No. It matters most for shops with a customized theme and many front office modules, regardless of size.
Next Steps
If PrestaShop 9 is on your roadmap, start with the storefront: map your modules, define the API contract and plan the frontend launch before the core upgrade. Book a demo with our team and we will walk through the sequence for your setup.