# Checklist before a PrestaShop migration

> A PrestaShop migration that goes wrong is almost always one that was poorly prepared beforehand. Here’s what I systematically check before touching a single file, whatever the starting or target version.

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

## Direct answer

> Before touching a single file, build three inventories: the module list with vendor and exact version number, the contents of the override/ folder, and the cron jobs registered on the server. Then back up the whole database and the img/ folder, and restore that backup somewhere else to prove it actually works.

## Why this step isn’t optional

A migration is prepared before it starts, not during. If the inventory is incomplete, problems surface along the way, often at the worst moment: a module whose licence has expired, a code override nobody remembers, a database backup that turns out not to contain everything. Each of these oversights costs time, and sometimes unrecoverable data.

This checklist applies to any pair of PrestaShop versions, from 1.5 to 9. What changes from one migration to another is the scale of the rebuild work; what doesn’t change is the need to start from a complete inventory and a reliable backup.

## What I inventory and back up

1. **Full list of installed modules** — Name, publisher and exact version number of every module, including disabled ones still present. This is the basis for later checking which ones have a compatible equivalent for the target version.
2. **Inventory of code overrides** — Everything in the override/ folder, plus custom hooks added outside standard modules. These customisations are the most fragile point during a major version change.
3. **Full database backup** — Structure and content of every table, not just product and order tables. Configuration, translation and module tables hold settings you don’t want to re-enter by hand.
4. **Full file backup** — Code, theme and catalogue images. A database without its associated image files is unusable as it stands.
5. **Target PHP version at the host** — I check which PHP version is available at the host, and whether it matches what the target PrestaShop version requires. This is often the constraint that decides which target version is actually possible.
6. **Scheduled tasks, API keys and translations** — Existing cron jobs (cart reminders, exports, synchronisations), payment and carrier API keys, and any language modules and custom translations installed.
7. **Available disk space** — I check there’s enough room to store the full backup and run a test copy alongside the live site.

## Always test on a copy, never directly on production

> A migration always runs first on a copy of the shop. That’s what lets me uncover blockers, fix them, and price the real work before committing to a deadline, without ever risking the live site.

## Related pages

- **Incompatible modules after a migration** — Why a module that worked perfectly breaks after an update, and how to check its compatibility before migrating. ([/prestashop/migration/modules-incompatibles](/prestashop/migration/modules-incompatibles))
- **Migrating without interrupting sales** — The method for preparing a migration alongside the live site, and switching over without taking the shop offline. ([/prestashop/migration/migrer-sans-interruption-de-vente](/prestashop/migration/migrer-sans-interruption-de-vente))
- **Moving PrestaShop to PHP 8** — What it means when a host drops PHP 7 and the target PrestaShop version requires PHP 8. ([/prestashop/migration/passer-a-php-8](/prestashop/migration/passer-a-php-8))

## FAQ

### How long before the migration should I do this inventory?

I do it right at the start of the project, before estimating timeline and scope. This inventory is what shows how many modules will need replacing or overrides rewriting.

### Isn’t a database backup enough?

No, you also need the files, especially catalogue images which aren’t stored in the database. A database without its associated files can’t be used to restore the shop.

### What if I no longer have the licence or access for a paid module?

That’s exactly the point of doing the inventory upfront: spotting it before the migration rather than during, so there’s time to contact the publisher or look for an alternative.

### Why check the host’s PHP version before choosing the target PrestaShop version?

Because each PrestaShop version requires a specific PHP version range. If the host doesn’t yet offer the version needed, either the host changes or the target version is adjusted.

### Should scheduled tasks (cron jobs) be backed up too?

Yes, they’re often forgotten even though they drive important features like cart reminders or automated exports. They need to be listed so they can be recreated after the migration.