# Migrating your PrestaShop shop to 1.7, 8 or 9

> Moving from PrestaShop 1.6 to 1.7, 8 or 9 isn't a routine update: the theme engine changes completely, the back office shifts to Symfony version after version, and a good number of 1.6 modules no longer work as they are.

- Source canonique : [https://allaux.fr/en/prestashop/migration](https://allaux.fr/en/prestashop/migration)
- Langue : EN
- Dernière mise à jour : 2026-09-30

## Direct answer

> Start by noting your exact version under Advanced Parameters > Information, then the PHP version your host offers: those two figures alone decide which target version is within reach. Then copy files and database to a test environment and run the migration there, never on the live shop.

## Why it's not a simple update

PrestaShop 1.6 uses a theme system built entirely on Smarty and classic .tpl templates. From 1.7 onward, part of the admin and some front controllers run on the Symfony framework, with a new folder structure (src/, var/) and a different override system. The default theme also changes name (Classic instead of Default), which means in practice that a 1.6 theme, even a customised one, doesn't install as-is on 1.7 or 8: it has to be rebuilt or adapted template by template.

On the module side, each module has to declare its compatibility with the target version in its configuration file. A module that works perfectly on 1.6 can be entirely absent from the marketplace for 1.7/8, or require a different paid version from its publisher. This is often what derails a migration budget that wasn't properly estimated at the outset.

The database structure also changes between major versions (new tables, renamed columns), which calls for a data migration script rather than a plain SQL export-import.

## How I run a migration

1. **Audit of the existing setup** — I list the installed modules and their versions, and check which ones have a compatible equivalent for the target version.
2. **Migration on a test environment** — I run the migration first on a copy of the shop, never directly on production, to identify every blocker before touching the live site.
3. **Rebuilding the theme** — Depending on the gap between versions, I adapt the existing theme or rebuild it from the target version's default theme, keeping the visual identity.
4. **Replacing incompatible modules** — I find working equivalents for modules that don't migrate, or rewrite the specific functionality as a custom module if needed.
5. **Going live** — Once the test version is approved with you, I schedule the switch for a low-traffic window to limit the impact on orders in progress.

## 1.7, 8 or 9, depending on your situation

- **PrestaShop 1.7** — A step on the way rather than a destination: it is the version you have to reach before continuing to 8 or 9 when starting from 1.6, since the update tool skips no step. ([/prestashop/migration/1-6-vers-1-7](/prestashop/migration/1-6-vers-1-7))
- **PrestaShop 8** — A sensible target when the shop's modules aren't declared compatible with 9 yet, or when the hosting doesn't offer a PHP version that 9 accepts. ([/prestashop/migration/1-7-vers-8](/prestashop/migration/1-7-vers-8))
- **PrestaShop 9** — The latest major branch: a back office fully on Symfony and Twig, legacy admin controllers removed, higher PHP requirements. The natural target for a new project, module compatibility permitting. ([/prestashop/migration/8-vers-9](/prestashop/migration/8-vers-9))
- **Staying on 1.6, cautiously** — Workable short-term for a stable shop, but 1.6 is no longer maintained by the publisher, which exposes you to unpatched security flaws. ([/prestashop/migration/1-6-vers-9](/prestashop/migration/1-6-vers-9))
- **Coming from PrestaShop 1.5** — No tool makes that jump: the shop is rebuilt on 8 and the data carried over. A project to scope like a rebuild. ([/prestashop/migration/1-5-vers-8](/prestashop/migration/1-5-vers-8))

## What to check beforehand

- **Pre-migration checklist** — Backups, module inventory, PHP version, rollback plan: what must be in place before touching the shop. ([/prestashop/migration/checklist-avant-migration](/prestashop/migration/checklist-avant-migration))
- **Incompatible modules** — The line that makes budgets drift: how to know which of your modules will not follow, before you start. ([/prestashop/migration/modules-incompatibles](/prestashop/migration/modules-incompatibles))
- **Migrating without losing SEO** — The redirect plan and checkpoints that stop the migration being paid for in lost traffic. ([/guides/migrer-sans-perdre-referencement](/guides/migrer-sans-perdre-referencement))
- **Modules that no longer install** — After the upgrade, a module refuses to install or vanishes from the back office: causes and fixes. ([/prestashop/problemes/module-refuse-installation](/prestashop/problemes/module-refuse-installation))
- **Payment method gone after the update** — The costliest symptom of a poorly tested migration, and how to deal with it. ([/prestashop/problemes/moyen-paiement-disparait-apres-maj](/prestashop/problemes/moyen-paiement-disparait-apres-maj))
- **Migrate or rebuild?** — When the upgrade costs almost as much as a rebuild, the question deserves a straight answer. ([/creation/refonte-ou-reparation](/creation/refonte-ou-reparation))

## Never migrate directly on production

> A migration is always tested on a copy of the shop first. That's what lets me price the module and theme work accurately before committing to a firm deadline.

## FAQ

### Will I lose my orders, customers or catalogue during the migration?

No, the migration runs on a copy of the shop. Production data stays untouched until the final switch, which picks up orders placed in the meantime.

### How long does a migration take?

It mostly depends on the number of modules and the complexity of the theme. A simple shop migrates in a few days; a shop with custom modules or a heavily customised theme can take several weeks.

### Will my SEO be affected?

If URLs and page structure are kept, the impact is limited. I pay close attention to redirects and tag structure so existing rankings aren't lost.

### What happens if a module has no equivalent on the new version?

I first look for an equivalent module from another publisher. If nothing on the market fits, I build the feature as a custom module suited to the new architecture.

### What access do I need to give you?

FTP or SSH access, database access, and access to the current back office to inventory the modules and configuration.