# PrestaShop 1.5 to 8: rebuild, then bring the data across

> PrestaShop 1.5, released in 2012, has an architecture with little left in common with version 8. No official tool migrates a 1.5 shop straight to 8: this is a rebuild-with-data-recovery project, not an update in the usual sense.

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

## Direct answer

> No tool migrates a 1.5 straight to 8, so settle the method first: stepping 1.5 to 1.6, then 1.7, then 8, one stage at a time on a copy, or a clean 8 install into which you re-import catalogue, customers and orders. Either way, begin with a full SQL dump and a copy of the img/ folder, the only data you actually keep.

## Why this isn’t a routine migration

PrestaShop 1.5 was released in 2012. Its architecture is older still than 1.6’s, which already needs a significant theme rebuild to reach 1.7 or 8. No official tool migrates a 1.5 shop directly to 1.7, 8 or 9: autoupgrade is designed for much tighter version jumps, with scripts matched to each step, not for clearing a gap this wide in one go.

PrestaShop 1.5 hasn’t been maintained by the publisher for a very long time, though I can’t point to a reliable exact date. It also runs on old PHP versions, themselves no longer maintained by the PHP project. A 1.5 shop still online carries two problems at once: unmaintained software, and an unmaintained runtime environment.

## The two real methods, and how to choose

The first is to chain migrations version by version: 1.5 to 1.6, then 1.7, then 8, each step tested separately on a copy. It’s the most reliable way to keep the full history (catalogue, orders, customer accounts) intact, but also the longest, since it multiplies steps and fixes.

The second is to start from a fresh install of the target version and migrate only the useful data: catalogue, customers, order history, through a targeted export-import rather than a raw database restore. In practice, this amounts to a rebuild rather than a migration in the usual sense.

Either way, the theme and nearly all modules have to be redone: neither method avoids that step. The real question isn’t “how to migrate”, but “what do I actually need to keep”. A full order history and long-standing SEO make the case for the cascade. A need for speed, with catalogue and customers recovered cleanly, makes the case for the rebuild.

## Cascade or rebuild

- **Cascading migration** — 1.5 to 1.6, then 1.7, then 8, each step tested separately. Keeps the full history but takes the most time.
- **Rebuild with data recovery** — Fresh install, catalogue and customers recovered through targeted export-import. Faster, but it’s a rebuild, not a migration in the strict sense.
- **Staying on 1.5** — Not advisable beyond the very short term: an unmaintained version, on a PHP environment that’s also old.

## How I approach this kind of project

1. **Audit of the existing shop** — I look at what’s still usable: catalogue size, order history, customer accounts, and the real state of the code (custom modules, overrides).
2. **Choosing the method with you** — Cascade or rebuild with data recovery, depending on what you actually need to keep: full history, long-standing SEO, or simply catalogue and customers.
3. **Full backup of the existing shop** — Before any operation, I export the 1.5 shop’s files and database in full, even though it won’t be restored as-is on the target.
4. **The point of no return** — This is when I stop feeding new orders into the old shop and switch customers to the rebuilt one: any order placed on the old site after this has to be recovered manually.
5. **Rebuilding the theme and modules** — The theme and nearly all modules from a 1.5 shop don’t migrate: I rebuild them for the target version, whether the approach is cascade or rebuild.
6. **Verifying the recovered data** — I compare volumes between old and new shop, number of products, customers, orders, to make sure nothing was lost.

## The theme and modules don’t migrate

> Whichever method is chosen, the theme and nearly all modules have to be redone for the target version: not negotiable, it’s a direct consequence of the gap between the two versions.

## Related reading

- **Checklist before any migration** — What to check before starting a migration, whatever the starting version. ([/prestashop/migration/checklist-avant-migration](/prestashop/migration/checklist-avant-migration))
- **PrestaShop 1.6 to 8 migration** — The intermediate step in a cascade, once the 1.5 to 1.6 move is done. ([/prestashop/migration/1-6-vers-8](/prestashop/migration/1-6-vers-8))
- **PrestaShop 1.7 to 8 migration** — The final step in a cascade, closest to the current architecture. ([/prestashop/migration/1-7-vers-8](/prestashop/migration/1-7-vers-8))
- **Keeping your SEO** — What I watch on URLs to limit the loss of acquired rankings. ([/prestashop/migration/conserver-son-referencement](/prestashop/migration/conserver-son-referencement))
- **Rebuild or repair** — Since 1.5 to 8 is a rebuild, scope it as one: what it commits you to, what it costs, what it loses. ([/creation/refonte-ou-reparation](/creation/refonte-ou-reparation))

## FAQ

### Why can’t a 1.5 shop migrate directly to 8?

Because no official tool does it: autoupgrade handles update steps much tighter than the gap between 1.5 and 8. Two real methods remain: cascading migration, version by version, or a rebuild with targeted data recovery.

### Will I lose my current theme?

In nearly all cases, yes: a 1.5 shop’s theme has to be rebuilt for the target version, whichever method is chosen. That’s a feature of the gap between the versions, not something with a reliable shortcut.

### Which method should I choose, cascade or rebuild?

Depends on what you need to keep. A full order history and long-standing SEO make the case for the cascade. A need for speed, with catalogue and customers recovered cleanly, makes the case for the rebuild.

### How long does this kind of project take?

Longer than a migration between close versions, since rebuilding the theme and overhauling most modules are unavoidable in either method. I give an estimate after the initial audit, not before.