# PrestaShop modules stuck on 8: how to tell if they block the upgrade

When a PrestaShop store puts off an upgrade, the core is almost never to blame. The sentence we hear most often is a different one: "we can't upgrade because module X doesn't work with the new version". The management software module, the courier one, the one bought years ago for reseller discounts.

It's a real problem, but rarely a dead end. In this article we look at how to take inventory of modules, how to recognise the ones that really block the move to PrestaShop 9, and the three ways to unblock them.

Why a module stops working

A module is a piece of code that adds features to PrestaShop by attaching to predefined points, the hooks, or by replacing core classes with overrides. When PrestaShop changes major version, some of these things change:

• old functions and classes are removed or rewritten;
• back office pages move to Symfony, and modules that changed them the old way no longer find their attachment point;
• the minimum PHP version changes, and code written for PHP 7 can throw errors on PHP 8.

A module written by the rules, with official hooks and APIs, usually needs little work. A module full of overrides and shortcuts needs much more. We covered this in the article on what changes when moving to PrestaShop 9.

The inventory: three questions for each module

First of all you need a list. From the back office module manager, you export or copy by hand every installed module, active or not. For each one you need three answers.

1. Is it still used? It sounds trivial, but in a store a few years old some modules were installed for a test, replaced by something else or tied to a finished campaign. Every module removed is one problem less, and often a few queries less too: forgotten modules are a typical cause of a slow PrestaShop.
2. Who maintains it? Does the vendor still exist and publish updates? Is there already a version for 9? On the module page, the declared compatibility is the first clue.
3. Has it been modified? A module bought and then patched by hand can no longer be updated without losing the changes. You need to know beforehand.

Three paths: update, replace, adapt

Three groups come out of the list.

Update. The vendor already has a version compatible with 9: you update it on the test copy and check it. It's the most common and cheapest case.

Replace. The vendor has abandoned the module, but there's a solid, up-to-date alternative doing the same thing. You migrate settings and data where needed, and swap it. It costs some work once, but removes a problem for good.

Adapt. The module is unique, and this is the work we do in PrestaShop development: custom-built, or doing something no alternative does the right way. Then you adapt the code to the version 9 APIs, test it on the copy and document it. A frequent example: the module linking PrestaShop to the management software, written years ago by a consultant who's no longer around. It works, but it uses two overrides and a removed function. Adapting it usually takes a few hours, much less than rewriting it.

The case of abandoned code

A module without maintenance isn't just an obstacle to upgrading: it's also a security risk, because discovered vulnerabilities won't get fixed. It's the same problem as abandoned dependencies in software in general, which we wrote about when covering compromised packages and the supply chain. In the inventory, an abandoned module still in use always deserves an explicit decision: replace it or take it over.

And it's worth remembering that staying behind has a cost that grows: we described it in how much you risk by staying on PrestaShop 1.7 or 8.

How to avoid it happening again

Two habits greatly reduce the problem at the next version:

• no hand edits to bought modules: if you need an extra feature, write a separate module that hooks into the existing one;
• custom code by the rules: official hooks and APIs, overrides only when there's no other way, everything versioned and documented. A release pipeline that tests the module on a copy of the store at every change does the rest.

In short

Modules stuck on 8 are the real reason many stores don't move to PrestaShop 9, but they're almost never an insurmountable obstacle. You take inventory, remove the useless ones, update those with a new version, replace the abandoned ones and adapt the unique ones. The real work concentrates on a few modules, and it pays to know which before starting, with an estimate for each.

Sources

• Module development - PrestaShop 9 - official documentation
• System requirements - PrestaShop 9 - official documentation
• PrestaShop 9.2 is available - PrestaShop Project, 30 September 2026