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. That maintenance work, the announcement says, "consisted mainly of fixing critical bugs or security vulnerabilities". Since then your shop's core has received no fix at all, security included. It is now 2026: more than seven years.

A second layer, more often forgotten, 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. 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.

So a 1.6 shop 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: "no longer maintained" does not mean "broken". A well-kept 1.6 takes orders every day. It works; the question is the risk you are carrying and the cost you are accepting.

The risk is in your modules

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 alert notes that attackers target "shops using outdated software or modules, vulnerable third-party modules, or a yet-to-be-discovered vulnerability". The fix shipped as 1.7.8.7, 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".

Together they draw 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 the way in". The distinction matters, because it tells you which inventory to run.

What can be updated on a 1.6, and what cannot

For the core, community patches exist for specific 1.6 vulnerabilities, including the 2022 chain. They are genuinely useful, but installing one makes you the owner of its correctness, its follow-up and its compatibility with everything else. A defensible way to buy time, not a long-term strategy.

Repurchasing modules, vendor by vendor

This is the line item that tips most quotes, and the one surrounded by the most guesswork. 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, 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 catalog 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 license 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 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

The order of magnitude: a full overhaul (theme rebuilt, modules repurchased and reconfigured, data migrated, redirects secured, acceptance testing) runs into thousands of euros. That is normal, and a high quote is not a dishonest one: 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". Many shops do not need all of it: the inventory tells you, and it costs far less than the rebuild it sometimes avoids. And 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 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: catalog, 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. Moving from 1.6 to a modern version is a migration rather than an update, which is why the module repurchase question exists at all. And the destination sets its own floor, version by version in the official documentation: 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.

Three defensible decisions

There is no single right answer. Which of the three 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 amortized cost of a rebuild.

Rebuild, when the shop's problem is not its version: the buying journey, the catalog, 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

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, 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. 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.

"We'll deal with content after the rebuild" is backwards. Content is the part of the work that survives the rebuild, and 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, justified by the work involved. The figure that concerns you depends on your inventory, and many shops do not need everything rebuilt. That is 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 penalize me for my PrestaShop version? No. Ranking does not depend on a version number. The practical SEO guide covers what actually matters.