PrestaShop 1.6 in 2026 — maintain, update or rebuild?

Your shop runs on PrestaShop 1.6, it sells, and everyone tells you it is time to rebuild. You have probably received a quote, perhaps several, and no way to judge whether the figure is fair or whether someone is selling you a worry. This article will not decide for you. It gathers what is verifiable — official dates, published security alerts, supported PHP versions — and separates the decisions that rest on facts from the ones that rest on your situation.

The search-engine side is covered separately in our practical PrestaShop SEO guide. This piece is about risk, maintenance and money.

"No longer maintained": what that means, to the day

PrestaShop announced the end of maintenance for 1.6 on 30 June 2019. The announcement is explicit about what stopped: that maintenance work "consisted mainly of fixing critical bugs or security vulnerabilities". Since that date your shop's core has received no fix at all — security included. It is now 2026: that is more than seven years.

There is a second layer, more often forgotten, and it is the one that will reach you first: PHP. The 1.6 line is contemporary with PHP 5 and the very start of PHP 7 — PrestaShop's developer documentation only begins at 1.7, whose floor is PHP 7.1.3. And the whole of PHP 7 is out of support: php.net now lists only the 8.2 branch and later as still receiving security fixes.

That is the point worth keeping, and it has the advantage of not depending on version detail: none of the PHP branches a 1.6 can run is still being fixed. A 1.6 shop therefore runs two unmaintained pieces of software stacked on top of each other, and the second one is not your call — the day your host retires PHP 7, the decision is made without you.

One clarification, because it sets the tone for everything that follows: "no longer maintained" does not mean "broken". A well-kept 1.6 takes orders every day. The question is not whether it works — it works. The question is the risk you are carrying and the cost you are accepting.

The real risk is not where you think: it is in your modules

This is the counter-intuitive part, and PrestaShop documents it itself.

July 2022. PrestaShop published an alert about an attack wave in progress: an SQL injection chained with the Smarty cache stored in the database, leading to code execution and payment data theft. The shops concerned were those on 1.6.0.10 and above as soon as they were exposed to an SQL injection. The sentence worth keeping from that alert: attackers are targeting "shops using outdated software or modules, vulnerable third-party modules, or a yet-to-be-discovered vulnerability". The fix itself shipped as version 1.7.8.7 — that is, on a maintained branch. For 1.6, there was none.

January 2025. Another official alert, same family of attack: an injection into the PS_SHOP_NAME configuration value serves JavaScript to the shop's customers in order to capture their data. This time the alert is categorical about the origin: "this vulnerability is not in the PrestaShop core but in third-party modules" — flaws "many of which were fixed a long time ago but remain unpatched in some stores".

Put the two together and you get a risk map that is not the one people picture:

• the way in is almost always a module, not the core;
• what protects you is having applied those modules' fixes;
• on 1.6, module updates are precisely what you no longer receive.

So the problem is not "my core is old, therefore I am in danger". It is: "my modules are no longer maintained, and that is where people come in". The distinction matters, because it tells you which inventory to run.

What can be updated on a 1.6, and what cannot

| Layer | Can it be updated? | |---|---| | PrestaShop core | No. Maintenance ended in June 2019; no official fix since. | | PHP | No, beyond 7.1 — the 1.6.1.x branch is not compatible past it. | | Paid modules | Case by case, depending on the vendor — see the next section. | | Free or in-house modules | Yes, but you (or your agency) become the maintainer. | | Theme | Yes, it is your code. But the 1.6 theme architecture does not carry over to later branches as-is. | | Your content | Yes, always, and independently of any version. |

For the core, community patches exist for specific 1.6 vulnerabilities, including the 2022 chain. They are genuinely useful, and it is worth knowing what you take on by installing one: a third-party patch on unmaintained software means you own its correctness, its follow-up and its compatibility with everything else. That is a defensible way to buy time, not a long-term strategy.

Repurchasing modules: the only question that matters, vendor by vendor

This is the line item that tips most quotes, and the one surrounded by the most guesswork. The honest answer is that there is no general rule — it depends on the module. A module sold as compatible with both your current branch and the target branch does not need repurchasing. A module that only exists for 1.6 means buying its equivalent on the destination version, when such an equivalent exists.

Hence a method rather than an estimate. For every installed module, four questions, in this order:

1. Do I still need it? The first saving in a rebuild is the list of modules you do not reinstall. Plenty of shops carry modules installed once and never removed.
2. Is it still sold? A module that has vanished from its vendor's catalogue is not a budget problem but a functional one: you need a replacement, or you drop the feature.
3. Does it exist for the target version, from the same vendor? If so, ask them in writing whether your licence covers that version. That question belongs to the vendor, not to a forum thread.
4. How much, and for what? Purchase price, plus reconfiguration time — usually the hidden line.

None of this is glamorous, and it is exactly what lets you judge a quote. Without it you are comparing figures; with it you are comparing scopes.

Rebuilding: price it, don't guess it

Let us start with the order of magnitude, because vagueness helps nobody: a full overhaul — theme rebuilt, modules repurchased and reconfigured, data migrated, redirects secured, acceptance testing — runs into thousands of euros. That is normal: it is several weeks of skilled work, and a provider who prices it there is doing their job properly.

Two things follow, and neither of them is "put the decision off". First, many shops do not need all of it — the inventory is what tells you, and it costs far less than the rebuild it sometimes avoids. Second, a figure means nothing without its scope, hence our stance: we look at your shop and price it for free, before you have to decide anything.

What an article can usefully say is what the invoice is made of — and where it concentrates:

• the theme, to be rebuilt rather than ported;
• the modules, per the inventory above;
• the data: catalogue, customers, orders, including history;
• search visibility: redirect plan, URLs, tags — the line that costs the most when it is rushed;
• acceptance testing and training, systematically underestimated.

Two useful facts for reading a quote. First, moving from 1.6 to a modern version is not an update but a migration — which is exactly why the module repurchase question exists at all. Second, the destination sets its own floor, and the official documentation states it version by version: PrestaShop 8 requires PHP 7.2.5 as a minimum, PrestaShop 9 drops compatibility below PHP 8.1 — and 9.1 adds PHP 8.5, now the recommended version. For many 1.6 shops that means changing hosting at the same time: better planned upfront than discovered halfway through.

And a point we care about: a high rebuild quote is not a dishonest quote. Rebuilding a theme, migrating a catalogue and securing redirects is long, skilled work, and the providers who price it properly are right to. What the merchant lacks is not a lower price — it is the inventory that lets them understand what they are buying.

Three defensible decisions

There is no single right answer. There are three, and which one fits depends on your situation:

Maintain, if you accept explicit conditions: cut the number of modules to the strict minimum, know which ones are exposed, apply the measures the official alerts themselves recommend (a non-default database prefix, a web application firewall, watching security advisories), back up for real — meaning you have restored a backup at least once — and accept that your host's PHP deadline will be imposed on you.

Migrate, when a blocking signal appears: a critical module you cannot find, a host retiring PHP 7.1, a performance ceiling you cannot lift, or an annual maintenance cost that exceeds the amortised cost of a rebuild.

Rebuild, when the shop's problem is not its version: the buying journey, the catalogue, the brand, the conversion rate. There, the version is only a scheduling excuse — which is perfectly fine, as long as it is said out loud.

What depends on no version at all: your content

This is the point that saves you from waiting for the rebuild to act. Content — differentiated descriptions, category pages, a blog — is worked the same way on a 1.6 and on a 9, and it is what builds traffic. The expensive misconception is "my shop is too old for modern tools": that is a vendor architecture choice, not a technical fate.

Publium runs on a 1.6 without touching it. The module is written to work identically from 1.6.1 to 9 — a constraint accepted from the first line, precisely because the 1.6 install base exists and deserves better than abandonment. The version detail is on the compatibility page. So a store built in 2015 can give itself a search-visibility makeover this week: a blog that finally exists, rewritten product descriptions, tags actually filled in, internal linking — no migration, no core modification, no waiting for a rebuild budget. And you can publish without opening the back office while you are at it.

And if you rebuild later, that work does not start over. This is the most useful consequence of the architecture, and it deserves saying out loud: your articles and rewritten descriptions are kept inside Publium, with their version history — not only in your PrestaShop database. The day the store is rebuilt on the same domain, it pairs again and finds its content, republishable to the new version since the module covers that one too. In the meantime the text stays readable and recoverable from the editor, in markdown as well as HTML.

Which turns the usual argument on its head: "we'll deal with content after the rebuild" gets it backwards, because content is precisely the part of the work that survives the rebuild. Starting there means investing in the one thing the migration will not make you redo.

Frequently asked questions

Will my 1.6 stop working? No. Nothing switches off on a given date. What degrades is security and the ecosystem: fewer and fewer compatible modules, and no fix when a vulnerability lands.

Are community patches serious? Some are written by very capable developers and do real good. But by installing one you become responsible for following it. Use them for known vulnerabilities while you decide — not instead of deciding.

How much does a rebuild cost? A full overhaul runs into thousands of euros, and that is justified by the work involved. But the figure that concerns you depends on your inventory — and many shops do not need everything rebuilt. That is exactly what we look at, for free, before advising anything.

Can I work on my search visibility without migrating? Yes, and it is the better order: content depends on no version, and it stays yours the day you migrate. Publium runs from 1.6.1 to 9.

Does Google penalise me for my PrestaShop version? No. Ranking does not depend on a version number — the practical SEO guide covers what actually matters.