This piece shows how that debt builds, how to spot it, how many hours a month a store consumes, and what maintenance keeps it from growing. We are not predicting the end of the world on older versions. We are showing you the bill.
The version landscape, without the scare tactics
Three facts draw the map. PrestaShop 8 shipped in October 2022 and requires PHP 8.1. PrestaShop 9 shipped in June 2025: Symfony 6.4, PHP support up to 8.4, a new admin API, a new theme. PrestaShop 9.1 shipped in April 2026. Versions 1.6 and 1.7 are historical.
We will not quote an end of support date for 1.7: we cannot verify one and will not invent it. Something more practical: a store on 1.7 sits on a branch nobody develops, and paid modules stop getting updates for it. That hurts sooner. A payment or carrier vendor ships a build for PrestaShop 8 and 9, and leaves 1.7 with a release from years ago. It works until the vendor changes the API, and then it ends in one day.
Check this yourself in fifteen minutes: read the PrestaShop and PHP versions in the back office, then count the modules last updated more than two years ago. That number is a better risk indicator than the store version alone.
Why a store stays on an old version
It is rarely about the core, which upgrades relatively predictably. The store stays because the modules and the theme stay.
After a few years a typical store runs from 30 to 60 modules: a dozen or so paid, two or three custom built, the rest added during a campaign and never switched off. The theme was bought and then modified, often with core templates overridden. At upgrade time somebody must answer one question for every item: is there an equivalent compatible with the target version, and if not, what next. For most, the answer is easy. For three it reads "there is none, it has to be written". The project stalls on those three.
The mechanism runs one way only: the longer you stand still, the more expensive it is to move. A store on PrestaShop 8 going to 9 makes one jump. A store on 1.7 crosses two major versions at once, so changes from both branches pile into one project, tested all together. Then there is PHP: a language version jump can take down older modules regardless of PrestaShop. Deferring is not neutral. It is a loan at a rising interest rate.
What actually breaks PrestaShop stores
Five things that most often end in a ticket, each with the order of magnitude of time needed to restore operation. That is an observation from our work, not a contractual commitment: we guarantee response time, not repair time.
Module conflicts after the same files get overridden. Symptom: a cart button disappears or prices display wrongly after a new module goes live. Cause: two modules override the same template or class, and the later one wins. Order of magnitude: from 1 to 4 hours, if it is known what was deployed and when.
Performance with a large catalogue. Symptom: product list and search grind for seconds, the back office stalls when editing a product. Cause: many combinations and attributes, missing or unrebuilt indexes, an ineffective cache. Order of magnitude: from 4 to 16 hours for diagnosis and first fixes: work on data, not a switch.
Wholesaler and ERP integrations. Symptom: stock levels drift apart, or the import halts overnight and nobody notices until morning. Cause: a format change on the wholesaler side, an expired key, no error handling in the import script. Order of magnitude: from 2 to 8 hours, plus waiting on the other side, which is outside our control.
Payment and carrier modules after vendor changes. Symptom: the customer never finishes the order, logs show a gateway rejection, labels stop generating. Cause: the vendor changed the API or withdrew the older module, and your version has no compatible release. Order of magnitude: from 2 to 6 hours with a replacement available. Without one, this is no longer a ticket, it is a project.
A 500 error after an update. Symptom: a blank page or a server error right after a patch goes out. Cause: a module incompatible with the new PHP or core version, less often permissions and cache. Order of magnitude: from 30 minutes to 3 hours, provided a backup exists and the change can be rolled back. Without a backup, different numbers entirely.
We covered these categories more broadly in our piece on common store failures.
What honest PrestaShop maintenance looks like month after month
In practice it is five repeatable activities. None of them is spectacular.
First, a module inventory: every module with its version, vendor, licence expiry and whether a release compatible with the next major version exists. It is kept current, not produced once. Second, a staging environment copying production, where every update lands before it touches the store. Third, updates run after your approval and billed against the hour pool, not quietly at night. Fourth, watching PHP compatibility, because the hosting provider changes the language version, often without asking, the most common cause of a sudden 500 error. Fifth, backups with a quarterly restore test, because a backup nobody has restored is a hypothesis, not a safeguard.
What is not on that list: a promise that nothing will break. We do not make it. We promise that when something breaks, there is something to come back to, and it is clear what changed last.
How many hours PrestaShop eats
Three profiles from our practice, for picking a technical support package.
A stable store: up to 2,000 products, a dozen or so modules, one integration, changes mostly in content and banners. Realistically from 6 to 10 hours a month. The Basic package, 250 USD, a pool of 10 h.
An active store: a large catalogue with combinations, an ERP or wholesaler integration, regular campaigns, several paid modules with licences to track. From 15 to 22 hours. The Advanced package, 500 USD, a pool of 20 h.
A complex store: multilingual or multistore, several integrations, custom built modules, frequent changes to checkout. From 30 to 40 hours. The Premium package, 1,000 USD, a pool of 40 h.
One note for the budget: a store mid migration consumes from two to three times more hours than usual, through the project and for several weeks after the switch. Plan a higher pool for that period. An hour inside the package costs 25 USD, an hour beyond the pool 40 USD, so ad hoc excess hours are simply more expensive. The full cost picture is in our separate piece on store maintenance costs.
A version migration is a project, not a task from the pool
We do not drop migrations into the subscription or pretend they fit inside the hour pool. We quote them separately: scope follows from the inventory, not the calendar.
Five parts. An audit of modules and theme: what has an equivalent, what has a paid one, what must be written from scratch, and what can be switched off as unused for three years. Business decisions from that audit, made by you, not by us. The theme: adapted, or rebuilt on a new one. Data: migration and verification of catalogue, orders, customers, redirects. Testing on an environment copying production, checkout and payments included. Finally the switch, with a planned window and a ready rollback.
One practical point: do not migrate in November, nor in the second half of October. Every migration produces a wave of small defects in the first two weeks after the switch, exactly when you do not want to split attention between season and fixes. Best windows: January, February, and May to August.
A checklist to run against your current provider
Seven questions. The answers tell you more than any presentation.
- Who owns the paid module licences: you or the agency? If the agency, you lose the right to updates when you part ways.
- Is the store code in a repository, and do you have access?
- Is there a register of overrides and non standard modifications, or must it be reconstructed from the files?
- Who has access to the server and hosting panel, and are you on that list?
- Is anybody reading the error logs, or are we waiting for a customer to report it?
- When was a backup last restored on a staging environment?
- What is the expiry date of the oldest module licence, and who tracks it?
If three of these have no answer, your maintenance is a reaction to outages, not upkeep. That need not mean changing providers, sometimes filling the gaps is enough. But it is worth knowing what you pay for, and whether a subscription or hourly billing fits better.
Compare package scopes and prices at /en/sla-help-desk and pick the one matching your hourly profile. To see where your store stands first, run Tester eCommerce: give it your store address and get a free diagnosis, with no sales call up front.