Staying on PrestaShop 1.6 or 1.7: the risks and how to assess them

"If it works, don't touch it" is good advice for almost everything except software that is exposed to the Internet and takes card payments. A store on PrestaShop 1.6 or 1.7 can sell every day without a single visible error and, at the same time, build up risks that go unnoticed until they blow up.

This is not about scaremongering. It is about understanding what being out of support means, so that the decision to stay or migrate is yours and based on facts.

What "unsupported" means in practice

The core no longer receives patches

The 1.6 branch ended with 1.6.1.24 and the 1.7 branch with 1.7.8.11. When a new vulnerability is discovered in the core, the fix is released for the maintained branches. For yours, at best, someone writes an unofficial patch; at worst, there is nothing.

And even if you are on 1.7, which 1.7 are you on? Many stores are still on a 1.7.6 or a 1.7.7 without the later fixes from that same branch, which included security fixes.

Modules fall behind

Module developers focus their work on current versions. Over time, this happens:

• New versions of modules are no longer compatible with your store.
• When a security flaw is published in a module, the fixed version requires a more recent PrestaShop.
• Some authors abandon their modules and nobody reviews them again.
• Payment gateways change their APIs and requirements, and old modules stop working or lose features.

In practice, this is the biggest risk. Mass campaigns against PrestaShop usually exploit vulnerabilities in modules, and a store that cannot install the fixed version stays exposed indefinitely.

Unsupported PHP

PrestaShop 1.7.8 goes up to PHP 7.4 at most, and earlier versions even lower. PHP 7.4 stopped receiving security patches years ago. That means the very language your store runs on has known flaws that will not be fixed.

On top of that, hosting providers remove old PHP versions from their servers. One day the provider announces it is going to upgrade the version, or simply upgrades it, and the store stops working. Migrating in a rush because of that is the worst way to migrate.

How to assess your risk

Not all old stores carry the same risk. These questions help you place yourself:

A store with high turnover, many third-party modules and no monitoring is the one with the most to lose and the most likely to be attacked successfully.

What you can do in the meantime

If migration cannot happen right away, there are measures that reduce the risk:

• Upgrade to the latest version of your branch: 1.7.8.11 if you are on 1.7. It is far less work than a migration and closes known flaws.
• Upgrade PHP to the highest version your PrestaShop supports, testing on a copy first.
• Inventory your modules and remove the ones you do not use, including the folders of uninstalled ones.
• Update the modules that have a compatible version, especially those with public controllers.
• Block direct PHP execution in modules/ and in the data folders.
• Turn on monitoring of files, employees and payment settings, so you find out quickly if something happens.
• Backups every day, off the server and tested.

All this buys time. It does not turn an unsupported store into a supported one. And the longer it drags on, the more expensive the way out becomes: every year that passes there is more distance between your version and the current one, more modules with no direct equivalent and more data to carry over. The simplest migrations we do are for stores that made the jump while they could still choose the moment, not those that waited until something stopped working.

How to plan your way out

1. Decide on the destination. Today the sensible thing is to jump straight to PrestaShop 9, with no intermediate stop at 8, unless an essential module does not yet exist for 9.
2. Inventory functions, not modules. List what the store does (invoicing, shipping, ERP, payments, SEO) and, for each item, which module handles it today and which will in 9. Often a good share turns out to be unnecessary.
3. Estimate the theme work. A 1.6 theme is no use in 9, and a 1.7 one rarely works as is. It is the biggest item in many migrations.
4. Choose the moment. Avoid your sector's peak campaigns. A well-planned migration needs weeks of testing, not days.
5. Do a full rehearsal on a copy before switchover day.

The advantage of planning it well in advance is that you set the timetable. If you wait for the hosting to remove PHP 7.4 or for an incident to happen, someone else will set it.

How to solve it in PrestaShop

At Rekire we work every day with stores on 1.6, 1.7, 8 and 9, and with our support hours packs we do exactly this work: an audit of your store's version, PHP and modules with a risk assessment, an upgrade to the latest version of your branch if you want to buy time, and the migration plan to PrestaShop 9 with its inventory of functions, replacement modules and theme work. Hours are used according to the actual work, and you can start with the audit and decide afterwards.