PrestaShop 8 to 9 migration checklist: modules, theme, checkout and rollback

The short answer

A PrestaShop 8 → 9 migration is ready only when the exact target release, hosting stack, modules, theme, checkout, tax, carriers, mail and rollback have all passed on a production-like clone. A marketplace compatibility label or a successful core update is not enough to clear the whole shop.

Use this page as a go/no-go worksheet. Record a source and a staging result for every dependency, stop on unknown compatibility, and rehearse the rollback before choosing a production window.

Current source boundary — checked 30 July 2026

• PrestaShop 9 became generally available on 10 June 2025. The official launch note describes it as a major version and warns that modules and themes may require updates.
• The official GitHub release list marked 9.1.3 as latest when this guide was reviewed. Confirm the release list again on the day you freeze the target.
• The current PrestaShop 9 system requirements list MySQL 5.7 or MariaDB 10.2 as minimums. PrestaShop 9.0 supports PHP 8.1–8.4; PrestaShop 9.1 supports PHP 8.1–8.5. The recommended PHP version differs by minor release.
• The official updater is now called Update Assistant. It can check prerequisites and modules, create backups, update and restore. Those controls reduce risk; they do not certify third-party code or a custom storefront.

This checklist does not establish that PrestaShop 9.1.x, a particular theme or a particular module is compatible with your shop. The target version and every dependency still need their own evidence.

Start with one evidence sheet

Copy this table into the migration ticket. “Vendor says compatible” is context, not a staging result. A row without an owner or rollback is not ready for production.

The 14-point migration gate

1. Freeze one exact target

Write down the full target release and do not silently move it during staging. Read the relevant 9.0 or 9.1 release notes and the matching requirements. A result on 9.0.3 does not prove 9.1.3.

2. Inventory every installed and custom dependency

Export the active module list, then add modules that are disabled but still own data, custom code, theme modules, overrides, cron jobs, webhooks and external services. Record the exact installed version and the source of any compatibility claim. Unknown means no-go until staging supplies evidence or a replacement is chosen.

3. Check the hosting baseline separately

Run the Update Assistant prerequisite check against the target. Record PHP, database engine, memory, required extensions, web server and available disk space. Change one layer at a time where practical so a failed core upgrade is not confused with a simultaneous operating-system or database migration.

4. Prove that the backup restores

Back up the database, application files, images, modules, theme, overrides and configuration secrets through the approved operator path. Restore them into an isolated clone and record the duration and checks. A downloadable archive that has never restored is not yet a rollback plan.

5. Build a production-like staging clone

Match PHP, database, web server, cache, locale, currency and relevant integrations. Disable real outbound email and live payment capture, and use provider-supported test modes. Mask customer data according to your own policy. The goal is representative behaviour without contacting customers or creating live charges.

6. Run Update Assistant checks before the update

Use the web interface or the documented Update Assistant CLI to check the new version, requirements and module compatibility. Save its logs in the migration ticket. An uncertain module remains a manual decision; do not convert “unknown” into “compatible”.

7. Update the clone and reconcile every module

After the core update, compare the installed module set with the inventory. Confirm which packages were updated, disabled, removed or left uncertain. For each commercial or custom module, run its install/upgrade path and the business workflow it owns—not only the configuration page.

8. Test the exact theme, not a generic “PrestaShop 9 theme”

PrestaShop 9.1+ uses Hummingbird as the default theme, with Bootstrap 5.3 and jQuery-free theme code. Existing shops may retain Classic, a fork or a third-party theme. Test the exact theme package, child theme, templates, JavaScript, hooks and module placements at desktop and mobile widths.

9. Review the documented core changes that touch your code

Do not rely on a generic hook cheat sheet. Compare custom modules and overrides with the official 9.0 core changes and, when applicable, the 9.1 changes. PrestaShop 9 moves more back-office surfaces to Symfony/Twig, strengthens types and removes or changes specific hooks, services and legacy behaviours. Record only the changes your code actually uses.

10. Exercise checkout as a matrix

Test guest and registered checkout, every supported payment method, carrier, promotion, voucher, address and tax scenario that matters to the shop. Include failure and return paths. Compare order totals, tax lines, status transitions and confirmation email with the current production behaviour. Legal and tax policy remains the merchant’s responsibility.

11. Verify catalogue and search behaviour

Rebuild indexes and test exact product names, references, combinations, typos, facets, zero-result states and add-to-cart from search. Confirm category, product and image URLs before and after the update. Search is one workstream in the migration—not a universal claim about what fails most often.

12. Verify mail, cron, webhooks and fulfilment

Run controlled staging events for order email, refunds, stock updates, scheduled jobs, licence or download fulfilment and external webhooks. Confirm retry and idempotency behaviour where it exists. Keep real recipients and live credentials outside the test.

13. Compare logs and performance before approval

Record browser errors, application warnings, failed jobs and representative response times before and after the staging update. A visually correct homepage does not clear background failures. Set an explicit tolerance and owner for every accepted warning.

14. Rehearse rollback and sign the go/no-go

Trigger the rollback on the clone, restore the known-good state and repeat a small smoke test. Then record who can stop production cutover, the signals that trigger rollback and the maximum acceptable recovery point. Do not schedule production while any critical row in the evidence sheet is unknown.

Minimum acceptance matrix

Production cutover without invented timing

1. Freeze the exact core, theme and module packages that passed staging.
2. Choose the maintenance window from measured staging and restore duration.
3. Pause or drain writes through the shop’s documented operating procedure.
4. Create the final approved backup and verify that the rollback owner can access it.
5. Run the same Update Assistant path and package sequence used on staging.
6. Execute the minimum acceptance matrix before reopening normal traffic.
7. Roll back immediately when a precommitted stop condition appears.
8. After reopening, watch logs, jobs, checkout and fulfilment for the agreed period.

Do not publish a generic downtime promise. The credible window comes from the shop’s own measured clone, database size, file volume, operator path and tested restore.

NP Search: exact evidence, not a PrestaShop 9.1 promise

If search appears in your dependency inventory, the current NP Search 2.14.2 product record and compatibility page jointly report upgrade, schema, rebuild and desktop/mobile storefront checks on PrestaShop 8.2.5 / PHP 8.1 and PrestaShop 9.0.3 / PHP 8.2. The compatibility record separates that exact release from retained predecessor evidence.

Those results do not certify PrestaShop 9.1.3, every theme, every checkout stack or your catalogue. Use the exact ZIP on a clone of your shop and keep the staging result in the same migration sheet. No automatic watcher, marketplace label or product page replaces that merchant-specific test.

Decision

Go only when every critical row has an owner, source, passing staging result and tested rollback. Otherwise, remain on the supported current version, close the missing evidence and repeat the clone. A delayed migration is cheaper than a production cutover whose unknowns were renamed “compatible”.