How to upgrade PrestaShop 1.7 to 9 without losing the store

PrestaShop 1.7 is no longer maintained. PrestaShop 8 replaced it, then 9, and the current release is 9.1. The 8.x line is in extended support, so it still gets critical bug and security fixes but nothing new. Version 1.6 and anything older is end of life and gets no security fixes at all.

We have worked in PrestaShop's code for most of its life, from 1.5 to 9.1, and we have done every migration path between those versions. A good number of them were upgrades someone else had started and left half-finished. This post covers what moving a real store from 1.7 to 9 involves, why the built-in tool isn't enough, and how we do it so the store never disappears along the way.

Why the upgrade isn't a button

PrestaShop ships an upgrade module, and on a fresh demo store it works. Your store is not a fresh demo. It has years of changes on top of 1.7, and each of them has to survive the move.

Modules come first. A typical 1.7 store has thirty or more. Some have versions that run on 9, some need a paid upgrade, some were abandoned by their authors years ago, and usually a few do something essential that nobody remembers installing. Then there are overrides. PrestaShop lets a module or a developer replace core classes, and every override written against 1.7 is an open question on 9.

The theme is a job of its own. A customized theme has to be carried over or rebuilt, and 9.1 ships Hummingbird 2.0 as its default theme, which is not a drop-in replacement for a theme built on the older default. The database holds years of orders, customers, carts and logs, in tables that grew without anyone adding the indexes the newer queries expect. PrestaShop 9 also needs a current PHP. Whether your host provides it, and what else on the server breaks when PHP changes, is part of the work.

Run the upgrade tool over all of that on the live store and the usual result is what we get called in to recover. Half the store is on one version and half on the other, the checkout no longer works, and there is no clean way back.

How we do it

We deliver an upgrade as a Store Rescue. It takes 30 working days at a fixed price, and the work happens on a staging copy with a rollback path. The order of the steps matters, so here it is week by week.

Week 1: audit and baseline

Nothing changes yet. We go through the code, the database and the server, and we record a speed baseline with Google's own tools on the home page, the top category and the top product page. Every module, override and theme change goes on a list with a decision next to it: keep, replace, remove or rewrite. You see that list before you commit to anything.

Weeks 2 and 3: the upgrade, on staging

The live store keeps selling while we work on a copy. We bring PHP up to date, upgrade the platform to 9.1 and then go down the module list. Modules with a compatible version get updated. Abandoned modules that your business depends on get rewritten. A module that does nothing for you except cost page speed is removed, once you agree. Overrides are ported or retired, and the theme is carried over or rebuilt so that everything the store does today still works.

Week 4: performance, security and load testing

Since the store is open on the table anyway, this is when we fix the slow queries that grew with the catalog, add the missing indexes and configure Smarty and PrestaShop's performance settings properly. We also load-test the staging copy, so the first busy day after the upgrade isn't also its first test.

Week 5: cutover and handover

A backup is taken before anyone touches the live store. The cutover is planned, and if anything is wrong there is a way back. Then we check the speed against the guarantee and hand over the staging environment, a deploy process with rollback, backups, monitoring and written documentation. The code repository is yours from day one.

What it costs

It starts with a free store review. There is no charge and no obligation, it takes 3 business days from when we receive access, we work on a copy of the store, and you get written findings ranked by business impact, the upgrade path for your version and a fixed quote. We never quote an upgrade before we have seen the code.

The rescue itself has three public tiers, set by how much store there is to move rather than by your revenue. Essentials is from $4,500, for up to about 1,000 products, a standard theme and up to about 30 modules. Standard is $7,500, for up to about 10,000 products with a custom theme or a few integrations. Complex is $9,500, for a larger catalog, custom code, several integrations or multistore. You pay 50% at the start and 50% on delivery. The full tables are on the pricing page.

After the upgrade

An upgraded store left alone on generic hosting is slow and out of date again within a year or two. That is how most 1.7 stores got where they are. So every rescue ends on a monthly plan on a dedicated server we manage: Store Care from $395 a month (Store Care for PrestaShop from $495), or Managed Engineering from $950 a month if you also want engineering hours. There is no minimum term. Running the server ourselves is what lets us put the speed in writing: a mobile Lighthouse Performance score of 80 or more within 30 days of the rescue being finished, or the next month is free.

Should you upgrade at all?

Sometimes the answer is no. PrestaShop has been losing stores, most agencies have moved on, and for some merchants moving to another platform is the right call. If that is what we find in the review, we will say so. For a store that works, sells and has custom features its owner relies on, an upgrade keeps every page address, every ranking and every feature, and it is done in 30 working days. A move to a new platform keeps none of those.

To get the upgrade path for your version and a fixed quote, start on the PrestaShop upgrade page. Or book a call and we will tell you on the phone whether the upgrade is worth doing.