Modules, PrestaShop 9 upgrades and themes
Build online stores withprofessional PrestaShop development services
PrestaShop is open-source and self-hosted, so your store's long-term cost depends on how its customisations are written. We build modules on hooks and services rather than core overrides, and plan upgrades to version 9 around what each module and theme can actually support.
PrestaShop versions, as of October 2026
The 9.x line changed enough underneath that an upgrade should be planned as a project in its own right.
PrestaShop 9.1
Announced in March 2026. It supports PHP 8.1 to 8.5, and PrestaShop now recommends 8.5. The database minimum is MySQL 5.7 or MariaDB 10.2, with a recent version recommended.
Symfony underneath
PrestaShop 9.0, released in June 2025, moved to Symfony 6.4 LTS and added an Admin API built on API Platform. More back-office pages keep moving to Symfony, so older module code that touches them can need rewriting.
Hummingbird becomes the default
Hummingbird 2.0, on Bootstrap 5, replaces Classic as the default theme for new 9.1 installs. An existing store keeps its theme, and a child of Classic does not turn into a Hummingbird theme. Changing is its own piece of work.
Experimental features
9.1 adds multi-carrier shipping and a redesigned discount system behind feature flags, which PrestaShop advises testing outside production. We do not build a live store's core process on them until that changes.
PrestaShop development work
How a change is written decides how much rework the next upgrade needs.
Modules built on hooks
Action hooks run code on events, such as when an order is created, and display hooks add output to a page. A module registers them on install. If PrestaShop lacks a hook where you need one, a module can create its own.
Avoiding overrides
PrestaShop's own docs discourage overrides, forbid them in partner modules and note that two modules cannot reliably override the same behaviour. For Symfony-based parts of core, we use service decoration instead.
Cleaning up an old store
We list the store's overrides and edited core files, and either move them into modules or remove them. It is often the most useful work on an older store, because it is what makes upgrades possible at all.
Admin API integrations
On 9.x, ERP, stock and order integrations can use the Admin API, rather than custom endpoints. On older stores, we check what the existing webservice offers and keep the integration separate from the upgrade work.
When PrestaShop is the right choice, and when it is not
PrestaShop suits a merchant who wants to own the store, and is prepared to pay for looking after it.
A good fit when
- You want an open-source platform with no platform fee on sales.
- You are prepared to fund hosting, updates and module compatibility checks.
- Your catalogue and checkout need custom modules that a hosted platform may not allow.
A poor fit when
- You want the vendor to handle hosting, patches and upgrades.
- Your store depends on paid modules whose authors have no version 9 release.
- You have no one, in-house or external, to maintain it after launch.
How PrestaShop projects run
Upgrades and new builds run differently, but both begin by finding what can break.
Inventory
For an existing store: current version, PHP version, modules, theme, overrides and edited core files. For a new store: catalogue, carriers, payment methods and languages.
Compatibility decisions
Each module is marked as keep, replace, rewrite or drop, based on whether it supports your target version. You get this list with the price.
Staging
We upgrade a copy of the store. From 9.0.x, PrestaShop's route is the Update Assistant module, version 7.6.0 or later, with files and database backed up first, and test orders run through each carrier and payment method.
Go live
We release outside your busy period with a rollback plan, then check orders, emails and tracking. Afterwards your team can take over, or we keep the store updated.
Named projects and how we engage
No PrestaShop projects are named on this page. Most of our work is delivered under NDA, so many projects cannot be named.
Module work and upgrades are quoted after we have the inventory, because a store with a few clean modules is a very different job from one with years of overrides. We are an engineering team in India with 3–5 hours of overlap with the UK and Europe; US calls by appointment. The overlap suits European merchants for daytime calls.
PrestaShop questions
Should we upgrade to PrestaShop 9?
Probably, but first check your modules and theme. The deciding factor is rarely PrestaShop itself. It is whether the modules you rely on have releases for version 9, and how much custom or override code your store contains.
Do we have to change to the Hummingbird theme?
No. Hummingbird 2.0 is the default for new 9.1 installations, not a forced change for existing stores, though your current theme must work with your target version. We check that on staging, and advise on a theme change as separate work.
Can you fix a store full of overrides?
Yes. We move overrides into modules using hooks or, for Symfony-based parts of core, service decoration. Where no clean route exists we leave the override in place, document it and tell you what it will mean at the next upgrade.
Can you migrate us to PrestaShop from another platform?
Yes. Products, customers and orders are the straightforward part. We plan the redirects and any rebuilt features separately. Our PrestaShop migration page has more on how that works.
Related services
Tell us about your PrestaShop store
Send your store's address, your PrestaShop version and the modules you can't lose. We will come back with what stands between you and a clean upgrade.
We reply within one business day (IST).