PrestaShop 8 to 9 migration: 2026 compatibility checklist

PrestaShop 9 has been in stable release since early 2026 (9.1.3 as of late May, per the GitHub releases feed our compatibility watcher polls). For shops that have been sitting on PS 8.x for 2+ years, the migration is finally tractable — most of the major modules have caught up, and the 9.0 → 9.1 minor releases have ironed out the worst migration-flow bugs.

This is the 14-point checklist we use when helping a PS 8 shop plan the move. Not exhaustive — but it's the order that has worked, and it flags what the official 1-click upgrade module misses.

Before you touch anything

1. Inventory every active module

Back office → Modules → Module Manager → filter "Installed". Copy the list to a spreadsheet with three columns: module name, vendor, PS 9 compatible?. Fill the third column by searching each module on PrestaShop Addons (the listing shows max PS version under "Compatibility").

Any module without a PS 9 build is either a) a hard blocker (you need a replacement before migrating), or b) something you can drop because you don't actually use it.

2. Inventory custom modules + overrides

Look in /modules, /themes/<your-theme>/modules, and especially /override. Any custom override files need manual review against PS 9 core changes (most break).

3. Database engine + PHP version baseline

PS 9 minimums: PHP 8.1, MySQL 5.7 / MariaDB 10.5. Many PS 8 shops are still on PHP 7.4 — that's an OS-level upgrade you do before touching PrestaShop. Doing both at the same time is the most common cause of failed migrations.

Pre-flight (do not skip these)

4. Full backup

Database dump + /img + /modules + /themes + /override. Verify the backup actually restores on a staging server. Untested backups are not backups.

5. Clone to staging

Spin up a staging instance on a sub-domain. Use a recent DB dump. Run the migration there first — never on production.

6. Run the official 1-click upgrade module on staging

Back office → Modules → search "1-click upgrade" (officially called "AutoUpgrade"). Configure: target PS 9.1.x stable, backup before upgrade = yes. Run.

Expected runtime: 10–45 minutes depending on database size. The module will list everything that needs manual intervention at the end — read it carefully.

The points the AutoUpgrade module misses

7. Theme compatibility

AutoUpgrade does not touch your theme. If you're on a custom or third-party theme, it likely has Smarty 4 syntax issues (PS 9 ships Smarty 4.x; PS 8 was on Smarty 3.x). Audit your theme's .tpl files for deprecated tags.

8. Override files — line-by-line

Every file under /override needs a line-by-line review against PS 9 core. The fastest way to discover what's broken is to run the staging shop with each override file restored one at a time and watch the error log.

9. Custom hooks

Several hooks were renamed or removed in PS 9. The cheat sheet:

• actionProductAdd still works but actionObjectProductAddBefore is recommended.
• displayHeader behaviour changed — content sometimes renders earlier than before.
• actionDispatcher deprecated → use actionDispatcherBefore.

10. Database collation

PS 9 prefers utf8mb4_unicode_ci across the board. Many PS 8 shops have a mix of utf8 and utf8mb4 from over the years. Run the collation-fix SQL after the upgrade — there's a Prestashop community script for this. Don't run it before.

Post-upgrade verification

11. Storefront smoke test

Walk through: homepage → category → product detail → add to cart → guest checkout → registered checkout. Hit every theme template.

12. Back office smoke test

Walk through: catalog, orders, customers, modules, statistics, SEO. Especially check the "module manager" itself — it's the most-edited BO surface in PS 9.

13. Search module verification

Search modules are the single most common breakage in PS 8 → 9 migrations. The plugin needs a PS-9-specific build that hooks the new search controller signature. Verify:

• Storefront search overlay still renders
• Autocomplete returns results
• Searchandising rules still apply
• Indexer can reindex without errors

For NP Search: our PS 9 build is published and our compatibility watcher tests every new 9.x release within 24h of upstream tag. If you're a customer, you've already gotten the PS 9 build via the in-module updater.

14. Re-enable compatibility watcher subscriptions

Most modules ship a "check for updates" cron. After upgrade, confirm those are still pointing at the right vendor URLs (PS 9 sometimes resets cron tasks).

Cutover plan for production

Once staging looks good for 3–5 days of synthetic + real traffic (point staff at it, place real test orders), plan production cutover for low-traffic window:

1. Maintenance mode on production. Back office → Preferences → Maintenance.
2. Final DB dump.
3. Run AutoUpgrade module on production (now that staging gave you the timing + warning list).
4. Re-apply theme + override fixes from the staging run.
5. Maintenance mode off. Watch error logs for 60 minutes.
6. Run search reindex, sitemap regeneration.
7. Submit updated sitemap to Search Console.

Realistic total downtime: 15–45 minutes for a small to medium shop, assuming no fires.

What to do if it goes wrong

Restore the DB dump. Restore /modules + theme. Stage again, identify what differed between staging and prod, fix, retry. Don't try to debug a broken production cutover — roll back first.

Bottom line

PS 8 → 9 in 2026 is tractable if you do the inventory + staging homework. The actual upgrade module is reliable; what breaks is the long tail of custom code that nobody documented.

For our part: every plugin we sell on neuroplugin.com has both PS 8 and PS 9 builds, retested automatically against each new upstream release via our compatibility watcher. The whole reason that watcher exists is so customers don't have to follow this checklist for the modules they bought from us.