Available for projects & agency overflow · Quick reply, from the person who does the work

Send a message contact@allaux.fr
FR EN TR
allaux.
Emergency Discuss my project

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.

Describe my issue Send a message

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.

Related pages

Describe your need in one minute

A few targeted questions so I can reply with an estimate rather than another questionnaire.

version-depart
version-arrivee
catalogue
modules-tiers (facultatif)
conserver (facultatif)
Please provide an email or a phone number so I can get back to you.

Please provide an email or a phone number so I can get back to you.

Frequently asked questions

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.

Related pages