How to Upgrade from PrestaShop 8 to PrestaShop 9 Safely

Upgrading from PrestaShop 8 to PrestaShop 9 is not just a routine maintenance task. It is a major-version transition that changes the technical foundation of the store, including the Symfony generation, PHP compatibility, front-office behavior, module expectations, and several internal APIs.

The good news is that PrestaShop now provides a much more capable Update Assistant than the old one-click upgrade workflow. It supports both Back Office and command-line operation, performs requirement checks, provides more detailed logs, and includes backup and restore functionality.

The important part is still your process.

A production ecommerce store should never be upgraded by clicking a button first and investigating compatibility later. The safest workflow is:

inventory → backup → staging → compatibility audit → rehearsal → regression testing → production cutover → monitoring

This guide explains that process in detail.

Version note: This article was verified on September 22, 2026. PrestaShop 9.1.5 is the latest stable 9.1 release and the final planned 9.1.x release before PrestaShop 9.2. PrestaShop 9.2 is still in Release Candidate testing at the time of writing, so it should not yet be treated as the stable production target.

Should You Update or Migrate?

Before choosing a tool, decide which project you are actually doing.

PrestaShop documentation distinguishes between an update and a migration.

An update keeps the existing store and applies the new core version while preserving existing store data, modules, and theme as far as the update process allows.

A migration means creating a fresh installation of the target PrestaShop version and transferring the required business data into it.

For relatively clean PrestaShop 8 stores, an Update Assistant-based upgrade can be an efficient route.

A migration may be the better option when the current store contains years of technical debt, for example:

• direct modifications to core files;
• abandoned modules;
• a heavily customized legacy theme;
• many overrides;
• database schema changes that are not documented;
• outdated third-party libraries;
• old integrations nobody fully understands;
• large amounts of obsolete configuration or data;
• recurring errors already present before the upgrade.

PrestaShop's current documentation explicitly notes that migration can be preferable when switching major versions because major releases can introduce significant core changes and incompatibilities.

The important point is not to force every store through the same process.

1. Choose the Exact PrestaShop 9 Target

Do not create a project called simply “upgrade to PrestaShop 9.”

Choose the exact target version.

As of September 22, 2026, PrestaShop 9.1.5 is the latest stable 9.1 release. PrestaShop has announced it as the final planned release of the 9.1.x line before 9.2.

That makes the target clearer.

You should also decide the target PHP version at the same time.

According to the official PrestaShop 9 requirements:

If you intend to run PrestaShop 9.1 on PHP 8.5, your staging environment should test that exact combination.

Do not upgrade PrestaShop with one PHP version, switch PHP later, and assume the second change is harmless.

2. Inventory the Current PrestaShop 8 Store

Before changing anything, document the store you already have.

Record:

• exact PrestaShop version;
• exact PHP version;
• MySQL or MariaDB version;
• active theme;
• all installed modules;
• disabled modules that still exist on disk;
• overrides;
• custom controllers;
• custom Symfony services;
• custom database tables;
• direct core modifications;
• cron jobs;
• CLI commands;
• web cron URLs;
• supplier imports;
• ERP connections;
• PIM connections;
• CRM connections;
• marketplace integrations;
• shipping integrations;
• payment gateways;
• custom APIs;
• webhooks;
• CDN configuration;
• Redis or other cache services;
• external search engines;
• filesystem or object-storage dependencies.

Then classify each component.

A useful classification is:

Critical — checkout, payments, stock, orders, accounting, ERP, shipping.

Important — product import, search, feeds, SEO, analytics, email automation.

Optional — decorative widgets, unused integrations, experiments, old tools.

This gives you a migration priority list.

3. Identify Direct Core Changes

Direct changes to PrestaShop core files are especially dangerous during a major upgrade.

If a developer changed files inside directories such as:

/classes/
/controllers/
/src/
/admin/
/themes/

without packaging those changes as a module, override, theme customization, or documented patch, the upgrade can replace them.

Use version control or compare the installation against the exact official PrestaShop release.

Every difference should be classified as:

• expected configuration;
• generated/cache content;
• module or theme file;
• intentional custom patch;
• unknown modification.

Unknown modifications should be investigated before the upgrade.

Do not wait until after deployment to discover that a business-critical customization disappeared.

4. Review All Overrides

Overrides deserve their own audit.

A PrestaShop override can replace behavior from a core class or controller. This makes it powerful, but also tightly couples the customization to the core implementation.

For each override:

1. identify why it exists;
2. find who owns the customization;
3. compare it with the PrestaShop 9 version of the class;
4. check whether the original problem has already been solved in core;
5. remove obsolete overrides;
6. reimplement required behavior using hooks or services when a safer extension point now exists.

An override created years ago for PrestaShop 1.7 may still be copied from release to release even though nobody remembers why it exists.

A major upgrade is the right time to stop carrying unnecessary code.

5. Audit Module Compatibility

Modules are one of the biggest sources of major-version risk.

For every critical module, verify whether the vendor explicitly supports your exact PrestaShop 9 target.

Do not rely on statements such as:

Compatible with PrestaShop 1.7+

That tells you almost nothing about Symfony 6.4, newer PHP versions, new Back Office pages, or changed data structures.

For each module, test:

• installation;
• upgrade from your currently installed module version;
• configuration page;
• Back Office routes;
• front-office hooks;
• product hooks;
• order hooks;
• Ajax endpoints;
• cron endpoints;
• CLI commands;
• database migrations;
• multistore behavior;
• uninstall behavior.

Payment modules need deeper testing

For payment modules, test more than a successful card payment.

Test:

• successful payment;
• declined payment;
• cancelled payment;
• delayed callback;
• duplicate callback;
• refund;
• partial refund;
• payment status synchronization;
• order creation;
• currency handling;
• guest checkout;
• registered customer checkout.

A payment module can load correctly in the Back Office and still fail during asynchronous callbacks.

6. Remove Modules You No Longer Need

A major upgrade is easier when you reduce unnecessary dependencies first.

If a module is disabled and has not been used for two years, ask whether it should still exist on the production server.

Old modules can create:

• PHP compatibility problems;
• security exposure;
• autoloading conflicts;
• database clutter;
• confusing hooks;
• unnecessary upgrade warnings.

Remove abandoned components only after confirming that no scheduled task, data export, order process, or historical reporting requirement depends on them.

7. Audit the Theme

The theme is another major compatibility surface.

PrestaShop 9 introduced substantial front-office changes, and PrestaShop 9.1 made Hummingbird 2 the default theme for new installations.

That does not mean an existing store must immediately replace its theme.

It means the current theme must be tested.

Check:

• homepage;
• category pages;
• product pages;
• search results;
• manufacturer pages;
• supplier pages;
• cart;
• checkout;
• customer login;
• registration;
• account pages;
• order history;
• contact pages;
• CMS pages;
• structured data;
• canonical URLs;
• pagination;
• responsive behavior;
• JavaScript components;
• image types.

Pay particular attention to custom templates that depend on presenter arrays or internal data structures.

A theme can appear visually correct while silently outputting broken structured data or incorrect prices.

8. Create a Complete Backup

Before the first upgrade attempt, create a complete backup.

At minimum, back up:

Database

Create a full database dump.

Verify that the dump contains:

• structure;
• data;
• triggers if you use them;
• correct character encoding.

Files

Back up:

• PrestaShop core;
• modules;
• themes;
• images;
• upload/download directories;
• translations;
• custom scripts;
• configuration;
• .htaccess;
• environment-specific files.

Infrastructure configuration

Document:

• PHP configuration;
• PHP-FPM pools;
• Apache or Nginx configuration;
• cron definitions;
• supervisor/systemd jobs;
• Redis configuration;
• CDN configuration;
• environment variables.

A database and ZIP file are not a complete disaster-recovery plan if nobody knows how the server was configured.

9. Test the Backup by Restoring It

This step is often skipped.

Do not only create a backup.

Restore it.

A successful restore proves that:

• the archive is not corrupt;
• all files are present;
• the database dump imports correctly;
• credentials are available;
• paths are documented;
• the application can boot;
• required external services are known.

The worst possible time to discover a broken backup is during a production rollback.

10. Build a Realistic Staging Environment

Create a staging copy that resembles production.

The environment should use:

• the target PHP version;
• similar server configuration;
• a recent production database copy;
• representative product images;
• the same theme;
• the same critical modules;
• the same cron commands.

Then isolate it.

Prevent staging from:

• sending real customer emails;
• charging real payment methods;
• sending orders to the live ERP;
• modifying supplier systems;
• appearing in Google;
• sending real marketing events.

A staging environment should be realistic without becoming another production system.

11. Check PrestaShop 9 System Requirements

Before the upgrade, verify that the server meets the current PrestaShop requirements.

The official PrestaShop 9 requirements currently include:

• Apache 2.4 or newer, or a compatible Nginx configuration;
• MySQL 5.7 minimum or MariaDB 10.2 minimum;
• a recommended PHP memory limit of at least 512 MB per script;
• the PHP extensions required by the platform.

Do not interpret “minimum” as “recommended for a large store.”

Large catalogs, image generation, bulk imports, and Back Office operations may require significantly more CPU, memory, and I/O performance.

12. Install or Update the Update Assistant

The modern Update Assistant replaced the older “1-Click Upgrade” positioning.

Update Assistant 7 introduced a redesigned update workflow with:

• Back Office interface;
• command-line interface;
• requirement checks;
• backup and restore features;
• improved logging;
• better error reporting;
• improved reliability for large stores.

PrestaShop 9 can be updated through the Back Office interface or using the Update Assistant CLI.

Back Office route

The Back Office interface is convenient for ordinary stores and guided updates.

CLI route

The CLI is especially useful for:

• large stores;
• developers;
• automation;
• CI/CD;
• environments affected by web execution time limits;
• updates where detailed terminal logs are useful.

The official documentation notes that CLI operation can avoid common PHP-FPM or web-server limitations such as request execution time.

13. Run Requirement Checks Before Starting

Do not ignore warnings.

Use the Update Assistant checks to confirm:

• target version availability;
• server requirements;
• PHP compatibility;
• filesystem permissions;
• module compatibility;
• disk space.

A warning that looks harmless before the update can become the reason the shop fails halfway through.

Resolve known issues first.

14. Stop Data-Changing Background Jobs

Before the real production cutover, pause jobs that can change important data.

Examples:

• supplier product imports;
• stock synchronization;
• price synchronization;
• order exports;
• ERP updates;
• marketplace imports;
• image generation;
• feed creation;
• automatic category synchronization.

Otherwise the upgrade may modify database structures while another process writes data using assumptions from the old version.

For high-volume stores, define a short controlled freeze window.

15. Perform the First Upgrade Only in Staging

The first complete upgrade should never be production.

Run it in staging and preserve all logs.

Record:

• start time;
• end time;
• PHP version;
• Update Assistant version;
• target PrestaShop version;
• warnings;
• SQL errors;
• module errors;
• filesystem errors;
• post-upgrade fixes.

Do not consider the rehearsal successful merely because the final screen says the update completed.

The upgrade is only successful after business regression testing.

16. Clear and Rebuild Caches Carefully

After a major upgrade, multiple cache layers can contain stale content.

Depending on your infrastructure, review:

• PrestaShop cache;
• Symfony cache;
• OPcache;
• Redis;
• reverse proxy cache;
• CDN cache;
• browser/versioned assets.

Do not randomly purge everything repeatedly while debugging.

Know which cache layer owns which content.

A page can appear “broken after upgrade” simply because old CSS or JavaScript is still served from a CDN.

17. Run a Full Regression Test

Create a written regression checklist.

Front Office

Test:

• homepage;
• menu;
• categories;
• filters;
• search;
• product pages;
• combinations;
• product images;
• prices;
• discounts;
• stock status;
• cart;
• checkout.

Customers

Test:

• registration;
• login;
• password reset;
• addresses;
• order history;
• guest orders.

Orders

Test:

• new order;
• payment;
• invoice;
• delivery slip;
• order status change;
• refund;
• partial refund;
• email notifications.

Catalog

Test:

• create product;
• edit product;
• create combinations;
• update stock;
• change categories;
• upload images;
• regenerate image types;
• bulk actions.

Automation

Run:

• cron jobs;
• CLI commands;
• supplier imports;
• exports;
• ERP synchronization;
• marketplace synchronization;
• feeds.

Multistore

If you use multistore, repeat critical checks in every shop context.

This is essential because configuration and associations can behave differently between shops.

18. Check Database Integrity and Logs

After the upgrade, inspect:

• PHP error logs;
• PrestaShop logs;
• web-server logs;
• Update Assistant logs;
• database errors;
• slow queries;
• cron logs.

Look for problems that users may not immediately notice.

Examples include:

• deprecation warnings flooding logs;
• repeated failed jobs;
• missing database columns expected by a module;
• SQL queries scanning millions of rows;
• integration callbacks returning HTTP 500.

19. Compare Performance Before and After

Take baseline measurements before upgrading.

Useful metrics include:

• homepage TTFB;
• category TTFB;
• product TTFB;
• checkout response time;
• Back Office product page load time;
• slow SQL queries;
• PHP memory usage;
• import duration;
• image generation duration.

Repeat the same tests after the upgrade.

PrestaShop 9 contains architectural and performance improvements, but your final performance also depends on modules, the theme, database queries, and hosting configuration.

Without a baseline, “it feels slower” is difficult to diagnose.

20. Crawl the Store for SEO Problems

A major upgrade can affect technical SEO even when the store looks correct.

Run a crawler before and after deployment.

Check:

• HTTP status codes;
• product URLs;
• category URLs;
• redirects;
• canonical tags;
• hreflang;
• title tags;
• meta descriptions;
• robots directives;
• sitemap;
• pagination;
• structured data.

PrestaShop 9 contains URL and SEO improvements, but changing existing indexed URLs without a redirect strategy can still damage organic traffic.

21. Define the Rollback Trigger Before Production

Do not decide whether to rollback while customers are already unable to pay.

Set objective rollback conditions.

Examples:

• checkout remains unavailable after a defined period;
• payment callbacks fail;
• ERP synchronization corrupts stock;
• critical orders are not created;
• database migration errors cannot be resolved safely;
• storefront error rate exceeds the agreed threshold.

Then document the rollback procedure.

A rollback normally requires restoring both files and database from the same point in time.

Restoring old application files against a partially upgraded database can make the situation worse.

22. Plan the Production Cutover

Once staging passes, write a production checklist.

A typical sequence is:

1. announce maintenance window;
2. verify latest backup;
3. stop data-changing cron jobs;
4. put the store in maintenance mode if required;
5. create a final database dump;
6. record deployment timestamp;
7. run the upgrade;
8. clear required caches;
9. run smoke tests;
10. test checkout;
11. test payment callback;
12. test Back Office;
13. restart integrations;
14. monitor logs and metrics;
15. reopen the store.

Assign responsibility for each step.

During a major upgrade, ambiguity costs time.

23. Monitor the Store Closely After Launch

The first successful order is not the end of the project.

Monitor the store for at least the next several business cycles.

Watch:

• HTTP 500 errors;
• failed payments;
• callback failures;
• stuck queues;
• cron failures;
• stock synchronization;
• abandoned carts;
• unusual checkout drop-off;
• PHP memory errors;
• slow queries;
• disk growth;
• customer support reports.

Some bugs only appear on rare products, uncommon combinations, unusual currencies, or specific customer groups.

24. Keep the Old Environment Temporarily

Do not immediately destroy the old environment after migration.

Keep a secured copy for a reasonable short period.

It can help you compare:

• configuration values;
• product data;
• module behavior;
• URL behavior;
• order processing;
• generated files.

Do not leave an old unpatched copy publicly accessible.

Common PrestaShop 8 to 9 Upgrade Mistakes

Upgrading production first

This turns compatibility testing into a live incident.

Changing PrestaShop, PHP, server and theme at once

Too many variables make failures difficult to isolate.

Trusting “compatible” without testing

A module can be technically installable while one important workflow is broken.

Ignoring cron jobs

Scheduled tasks may use a different PHP binary or load code differently from web requests.

Forgetting callbacks

Payment and marketplace callbacks can fail even when manual browser tests pass.

Not testing multistore

Shop context problems often appear only outside the default shop.

No rollback plan

A backup without a documented restore procedure is not enough.

Upgrade vs Fresh Migration: A Practical Rule

Consider an in-place Update Assistant upgrade when:

• the current PrestaShop 8 store is healthy;
• modules are actively maintained;
• the theme is compatible or can be adapted;
• customizations are documented;
• staging tests succeed.

Consider a fresh migration when:

• the existing installation has significant technical debt;
• many core files are modified;
• old overrides dominate the architecture;
• the theme needs a complete rebuild anyway;
• the module set is being replaced;
• the current database contains years of obsolete custom structures;
• reproducibility is poor.

The cleaner option is sometimes cheaper even if it initially looks like more work.

PrestaShop 8 to 9 Pre-Upgrade Checklist

• Exact source PrestaShop version documented
• Exact target PrestaShop 9 version selected
• Target PHP version selected
• Database version checked
• Theme compatibility tested
• Critical module compatibility tested
• Payment modules tested
• Shipping modules tested
• Overrides reviewed
• Core modifications identified
• Cron jobs documented
• External integrations documented
• Full files backup created
• Full database backup created
• Backup restoration tested
• Staging environment prepared
• Search indexing blocked on staging
• Real payment capture disabled on staging
• Update Assistant updated
• Requirements check passed
• Disk space verified
• Rollback procedure written

Post-Upgrade Checklist

• Front Office opens
• Back Office opens
• Product pages work
• Categories work
• Search works
• Combinations work
• Cart works
• Guest checkout works
• Registered checkout works
• Every payment method tested
• Payment callbacks tested
• Orders created correctly
• Invoices generated
• Refund tested
• Stock updates work
• Product creation works
• Product editing works
• Image upload works
• Cron jobs work
• CLI commands work
• ERP/PIM/CRM integrations work
• Multistore tested
• Error logs reviewed
• Slow queries reviewed
• SEO crawl completed
• Sitemap checked
• Performance compared with baseline

Frequently Asked Questions

Can I upgrade PrestaShop 8 directly to PrestaShop 9?

PrestaShop provides Update Assistant for supported update paths, including the major PrestaShop 9 transition. Always check the current Update Assistant requirements for your exact source version and target version before starting. For heavily customized stores, PrestaShop documentation also recommends considering a fresh migration when switching major versions.

Should I use the Back Office or CLI Update Assistant?

The Back Office interface is convenient for normal guided updates. CLI is especially useful for large stores, automation, CI/CD, and environments where web execution limits can interrupt long operations.

What PHP version should I use?

For PrestaShop 9.0, PHP 8.4 is currently recommended. For PrestaShop 9.1, PHP 8.5 is recommended. Test every critical module with the target PHP version before changing production.

Is PrestaShop 9.2 stable yet?

As of September 22, 2026, PrestaShop 9.2 is in Release Candidate testing. Use the current stable 9.x release for production unless you intentionally participate in pre-release testing.

How long does a PrestaShop 8 to 9 upgrade take?

The update command itself may be relatively fast, but a professional upgrade project includes inventory, compatibility fixes, staging, regression testing, performance testing and rollback planning. Complexity depends more on customization than product count alone.

Will my theme still work on PrestaShop 9?

Possibly, but it must be tested. Custom themes may depend on old template data, JavaScript behavior or front-office structures. Do not assume compatibility from appearance alone.

Will my modules continue to work?

Some will, some may require updates, and abandoned modules may need replacement. Test business-critical modules individually.

Do I need to change to Hummingbird 2?

No. Hummingbird 2 is the default theme for new PrestaShop 9.1 installations, but an existing shop can continue with another compatible theme.

Should I disable cron jobs during the upgrade?

Stop jobs that can modify products, stock, prices, orders or other data during the production cutover. Restart them only after the upgraded shop has passed smoke tests.

What is the most important upgrade safety measure?

A realistic staging rehearsal plus a tested rollback. Those two steps turn an uncertain upgrade into a controlled deployment.

Related PrestaShop 9 guides and resources

• check the PrestaShop 9 system requirements
• review the performance optimization guide
• Crash Snapshot Lite
• PrestaSuite documentation

Protect old URLs during the upgrade

If the upgrade or migration changes product, category or CMS URLs, prepare redirects before cutover. See the PrestaShop 301/302 migration redirect workflow and manage exact rules with URL Redirect Migration Helper Lite.