How long does a PrestaShop upgrade take?

It depends almost entirely on the module list and the amount of custom code. A clean 1.7 store with a dozen well-maintained modules is a different job from a heavily customised one with forty. The audit gives you a real estimate; the marketing pages of upgrade modules do not.

Will we lose our Google rankings?

Not if the URLs, canonicals, hreflang and structured data are checked before and after, which is part of every migration I run. Rankings are lost when someone treats them as a side effect instead of data to migrate.

Do we have to move to Hummingbird?

Not immediately. Classic still works on 9. But every new theme feature and most new modules will assume Hummingbird, so a store planning to live on 9 for years should plan the port rather than accumulate two generations of theme debt.

Can you do the upgrade on our own servers or AWS account?

Yes. I run the estate I manage on AWS and work inside client accounts routinely. Nothing needs to move to infrastructure I control.

Paths1.6 → 1.7 → 8 → 9Kept intactOrders, customers, URLsEngagementDirect, no agency layer

PrestaShop upgrade and migration, with the orders, customers and URLs still there afterwards.

Every version jump in PrestaShop is a small migration: 1.6 to 1.7 changed the theme layer, 1.7 to 8 moved the PHP floor, 8 to 9 replaced the Symfony core and the admin API and made Hummingbird the future theme. I am running exactly this migration across a 26-storefront estate, which is why I can tell you in advance which of your modules will break.

Start a project

What changes between versions, and what it breaks

PrestaShop 8 raised the PHP requirement and cleaned up a decade of legacy, which is exactly where old modules fail. PrestaShop 9 goes further: a current Symfony, PHP 8.1 or newer, a new Admin API, and Hummingbird as the supported modern theme, built on Bootstrap 5 without the jQuery that half of the module ecosystem still assumes.

The practical effect is that an upgrade is never just running the upgrade module. It is an audit of every installed module against the target version, a decision for each one - update, replace, rewrite or drop - a theme port or rebuild, a server that runs the new PHP, and a test plan for checkout, payments, shipping and the admin flows your team uses daily.

Module compatibility audit with a verdict per module: keep, update, replace, rewrite or drop
Theme path: patch Classic for the target version, or port to Hummingbird and lose the jQuery debt
PHP and server move, including the AWS side if that is where you run
Custom code and overrides ported to hooks and services that survive the next release
Data preserved end to end: catalog, combinations, customers, orders, invoices, URL rewrites

How the migration runs without touching the live shop

The upgrade happens on a full staging copy - database, files, modules, server configuration. I run the upgrade there, fix what breaks, and rerun it from a fresh copy until the run is clean and repeatable. Only then is it scheduled against production, with a tested rollback and a maintenance window sized to the real duration, not a guess.

Search rankings are treated as data to preserve, in the same list as orders. Every URL that has impressions in Search Console is checked before and after: same address, same canonical, same hreflang, same structured data. Where a URL must change, it gets a 301 and stays on the redirect list until Google has moved on.

Migrating to PrestaShop from somewhere else

Moving into PrestaShop from WooCommerce, Magento, OpenCart or a custom shop follows the same discipline with a different first step: mapping the old data model onto PrestaShop categories, combinations, features and customer groups before a single row is imported. The catalog import is scripted and rerunnable, the URL map is written before launch, and the old shop stays frozen as a reference until the numbers match.

If you are leaving PrestaShop for Shopify, that is its own page under the Shopify cluster - the reasoning is different and so is the work.

When not to upgrade yet

Sometimes the honest answer is to wait. A store on 1.7 with a stable, patched module set and a busy season ahead has no business migrating in October. A store on 1.6 has no such luxury: it is out of support, and every month it stays there is a month of unpatched exposure. The audit tells you which of those you are, and I will say so even when it means no project.

Questions people ask first

How long does a PrestaShop upgrade take?: It depends almost entirely on the module list and the amount of custom code. A clean 1.7 store with a dozen well-maintained modules is a different job from a heavily customised one with forty. The audit gives you a real estimate; the marketing pages of upgrade modules do not.
Will we lose our Google rankings?: Not if the URLs, canonicals, hreflang and structured data are checked before and after, which is part of every migration I run. Rankings are lost when someone treats them as a side effect instead of data to migrate.
Do we have to move to Hummingbird?: Not immediately. Classic still works on 9. But every new theme feature and most new modules will assume Hummingbird, so a store planning to live on 9 for years should plan the port rather than accumulate two generations of theme debt.
Can you do the upgrade on our own servers or AWS account?: Yes. I run the estate I manage on AWS and work inside client accounts routinely. Nothing needs to move to infrastructure I control.

In this cluster

Start a project All services