How to Migrate to PrestaShop 9: Complete Upgrade Guide

Why Upgrade to PrestaShop 9

PrestaShop 9 is the biggest architectural shift since the jump from 1.6 to 1.7. It's not just a version bump — it's a fundamental modernization of the platform. If you're running PrestaShop 1.7 or 8.x, the question isn't whether you should upgrade, but when and how to do it right.

Here's what PrestaShop 9 brings to the table:

Symfony 6.4 LTS Under the Hood

PrestaShop 9 upgrades from Symfony 4.4 (PS 8.x) to Symfony 6.4 LTS. This is a long-term support release, meaning you get security patches and bug fixes through November 2027. The Symfony upgrade brings modern dependency injection, improved routing, better error handling, and a significantly faster request lifecycle.

For store owners, this means a more stable and secure foundation. For developers, it means access to modern Symfony components and patterns that the PHP ecosystem has standardized around.

PHP 8.2+ Required

PrestaShop 9 requires PHP 8.2 at minimum, with full support for PHP 8.3. This isn't arbitrary — PHP 8.2+ brings readonly classes, fibers, improved type system, and meaningful performance improvements. Benchmarks show 5-15% faster execution compared to PHP 7.4, with lower memory usage across the board.

If you're still on PHP 7.4 or 8.0, the upgrade to PHP 8.2+ alone will make your store noticeably faster — even before you touch PrestaShop.

Twig Everywhere in Admin

The back office has completed its migration from Smarty to Twig. Every admin page now runs on Twig templates, which means faster rendering, better security (automatic output escaping), and a template engine that's actually maintained and well-documented. Legacy admin controllers still work through a compatibility layer, but the direction is clear: Twig is the present and the future.

Hummingbird as Default Theme

The Classic theme is replaced by Hummingbird as the default front office theme. Hummingbird is built on Bootstrap 5.3, uses modern CSS custom properties, and is significantly lighter than Classic. It's designed for performance first — smaller CSS bundles, less JavaScript, and better Core Web Vitals scores out of the box.

Security Improvements

Symfony 6.4 brings an entirely revamped security component. Password hashing uses modern algorithms (bcrypt/argon2), CSRF protection is more robust, and the authentication system is based on Symfony's security bundle rather than PrestaShop's legacy cookie-based approach. SQL injection and XSS vulnerabilities in legacy code paths have been systematically eliminated.

PrestaShop 9 is not a cosmetic update. It changes how the platform works at its core. That's exactly why you need to approach the upgrade methodically — the reward is a faster, more secure, more maintainable store, but only if you do the migration correctly.

Before You Start: Prerequisites Checklist

Don't touch your live store until you've verified every item on this list. Skipping prerequisites is the number one cause of failed upgrades.

Server Requirements

• PHP 8.2 or 8.3 — check with php -v on your server. PHP 8.1 will NOT work.
• MySQL 8.0+ or MariaDB 10.4+ — check with mysql --version. MySQL 5.7 is no longer supported.
• Required PHP extensions: intl, gd, curl, zip, mbstring, openssl, pdo_mysql, fileinfo, dom, json
• Composer 2.x — needed for dependency management during upgrade
• At least 256MB PHP memory_limit — the upgrade process is memory-intensive
• max_execution_time of at least 600 seconds — large stores need time for database migrations

To check your PHP setup quickly:

# Check PHP version
php -v

# Check loaded extensions
php -m | grep -E "(intl|gd|curl|zip|mbstring|openssl|pdo_mysql)"

# Check memory limit and execution time
php -i | grep -E "(memory_limit|max_execution_time)"

# Check MySQL version
mysql --version

PrestaShop Version Requirements

• You must be on PrestaShop 8.1 or 8.2 first. Direct upgrades from 1.7.x or 1.6.x to 9.x are not supported.
• If you're on PS 1.7.x, upgrade to 8.2 first, stabilize, then upgrade to 9.x.
• If you're on PS 1.6.x — stop. You need a complete rebuild, not an upgrade. See the "Clean Install" section below.

Module Compatibility Audit

This is where most upgrades fail. Before you upgrade, you need to know which of your modules are PS9-compatible and which aren't.

1. Make a complete list of every installed module (Back Office → Modules → Module Manager)
2. For each third-party module, contact the vendor and ask: "Is version X.Y compatible with PrestaShop 9?"
3. For any module that isn't confirmed compatible, you need a plan: upgrade it, replace it, or remove it
4. Pay special attention to payment modules — an incompatible payment gateway means zero revenue

Do not assume a module is compatible because it "worked on PS 8." PrestaShop 9 removes APIs and changes core behavior. A module that ran fine on 8.2 can crash on 9.0 because it calls a function that no longer exists.

Theme Compatibility

• If you're using the default Classic theme, you'll need to switch to Hummingbird or a PS9-compatible third-party theme
• If you're using a purchased theme, verify PS9 compatibility with the theme developer
• Custom themes built on Classic will need significant rework — the template structure has changed
• Hummingbird child themes are the recommended path forward

Business Timing

• Never upgrade during peak sales periods (Black Friday, Christmas, major promotions)
• Schedule the upgrade during your lowest traffic period — typically midweek, early morning
• Allow at least 48 hours of monitoring time after the upgrade before your next peak
• Have a rollback plan ready (covered below)

Backup Everything First

This is not optional. This is not "recommended." This is the single most important step. If your upgrade fails and you don't have a backup, you lose your store. Period.

Database Backup

The database contains everything that matters — products, customers, orders, configurations, module settings. Back it up with mysqldump:

# Standard mysqldump — works on any server
mysqldump -u root -p --single-transaction --quick --lock-tables=false prestashop > ~/backup_pre_ps9_$(date +%Y%m%d_%H%M%S).sql

# If your database is large (>1GB), add compression
mysqldump -u root -p --single-transaction --quick --lock-tables=false prestashop | gzip > ~/backup_pre_ps9_$(date +%Y%m%d_%H%M%S).sql.gz

If your PrestaShop runs in Docker:

# Replace 'my-shop-db' with your actual database container name
docker exec my-shop-db mysqldump -u root -p'YOUR_PASSWORD' --single-transaction --quick prestashop > ~/backup_pre_ps9_$(date +%Y%m%d_%H%M%S).sql

Explanation of the flags:

• --single-transaction — takes a consistent snapshot without locking tables (critical for InnoDB)
• --quick — retrieves rows one at a time instead of buffering them in memory (essential for large tables)
• --lock-tables=false — avoids locking tables during the dump so your store stays online

Verify your backup works by importing it into a test database:

# Create a test database and import the backup
mysql -u root -p -e "CREATE DATABASE prestashop_backup_test;"
mysql -u root -p prestashop_backup_test < ~/backup_pre_ps9_XXXXXXXX_XXXXXX.sql

# Check that it imported correctly
mysql -u root -p prestashop_backup_test -e "SELECT COUNT(*) FROM ps_product; SELECT COUNT(*) FROM ps_orders;"

# Clean up
mysql -u root -p -e "DROP DATABASE prestashop_backup_test;"

File Backup

Back up the entire PrestaShop directory — all PHP files, themes, modules, uploaded images, everything:

# Full file backup with tar
tar -czf ~/prestashop_files_pre_ps9_$(date +%Y%m%d_%H%M%S).tar.gz /var/www/html/

# If you want to exclude cache and logs (they're regenerated anyway)
tar -czf ~/prestashop_files_pre_ps9_$(date +%Y%m%d_%H%M%S).tar.gz \
  --exclude='var/cache' \
  --exclude='var/logs' \
  /var/www/html/

For Docker-based stores, backup the mounted volume:

tar -czf ~/prestashop_files_pre_ps9_$(date +%Y%m%d_%H%M%S).tar.gz /path/to/docker/html/

Store your backups in at least two locations — the server itself AND an offsite location (your local machine, a cloud storage bucket, or a different server). A backup that only exists on the same disk as your store isn't a real backup.

Configuration Notes

Before you start, document these settings (you'll need them if you have to reconfigure):

• Your app/config/parameters.php (database credentials, mailer config, cookie key)
• Your .htaccess file (especially if you've added custom rewrite rules)
• SMTP/email configuration from the back office
• Payment gateway API keys and settings
• Cron job configurations
• Any custom server configurations (Nginx rules, PHP-FPM pool settings)

Take screenshots of critical back office settings pages. When something goes wrong during upgrade, having a visual reference of "what it looked like before" is invaluable.

Step-by-Step Upgrade Process

There are two legitimate paths to PrestaShop 9: the in-place upgrade using the official module, or a clean install with data migration. Each has its place.

Approach 1: Auto-Upgrade Module (1-Click Upgrade)

The official upgrade path uses the autoupgrade module (also called "1-Click Upgrade"). This module handles the file replacement, database migration, and post-upgrade cleanup automatically.

Preparation

1. Install or update the 1-Click Upgrade module to its latest version from the PrestaShop Marketplace
2. Go to Back Office → Modules → 1-Click Upgrade
3. The module will show your current version and available upgrade targets
4. Run the Pre-upgrade checklist — the module will check your server compatibility and flag potential issues

Enable Maintenance Mode

# Or do it from the back office: Shop Parameters → General → Maintenance → Enable
# Make sure to whitelist your own IP address

This is essential. You don't want customers placing orders while the database is being migrated.

Run the Upgrade

1. In the 1-Click Upgrade module, select your target version (PrestaShop 9.x)
2. Choose "Major upgrade" as the upgrade channel
3. Review the upgrade options:
   • Back up files and database — enable this (belt and suspenders, even if you already backed up manually)
   • Deactivate non-native modules — enable this to prevent module conflicts during upgrade
   • Regenerate email templates — enable if you haven't customized them
4. Click "Upgrade PrestaShop now"
5. Do NOT close the browser tab, do NOT navigate away — wait for the process to complete

The upgrade can take anywhere from 5 minutes (small store) to 30+ minutes (large catalog, many modules). You'll see a progress log showing each step.

After the Upgrade Completes

# Clear all caches — this is not optional
rm -rf var/cache/*

# If using CLI (recommended):
php bin/console cache:clear --env=prod
php bin/console cache:warmup --env=prod

# Fix file permissions
chown -R www-data:www-data /var/www/html/var/
chown -R www-data:www-data /var/www/html/themes/
chmod -R 755 /var/www/html/var/

Re-enable Modules One by One

If you chose to deactivate non-native modules during upgrade, don't enable them all at once. Enable them one at a time:

1. Enable the module
2. Check the front office and back office for errors
3. If it works, move to the next module
4. If it breaks something, disable it and contact the module vendor

This methodical approach tells you exactly which module caused a problem, rather than staring at a broken store with 30 modules enabled and no idea which one is the culprit.

Approach 2: Clean Install + Data Migration

Sometimes the cleanest path forward is to start fresh. Install PrestaShop 9 from scratch and migrate your data into it. This approach is more work but gives you a pristine installation without any legacy baggage.

When to Choose Clean Install

• You're upgrading from PS 1.6.x (in-place upgrade is not supported for jumps this large)
• Your current store has years of accumulated overrides, hacks, and abandoned module tables
• You want to switch themes anyway
• Your database has grown bloated with abandoned carts, old logs, and orphaned data
• Previous upgrade attempts have failed

The Process

1. Install PrestaShop 9 fresh on a new directory or server
2. Set up your theme (Hummingbird or a PS9-compatible theme)
3. Install your modules (PS9-compatible versions only)
4. Migrate your data using either:
   • PrestaShop's CSV import for products, categories, and customers
   • Direct database migration using custom SQL scripts
   • Third-party migration tools
5. Reconfigure payment gateways, shipping, taxes, and email
6. Test everything on the new installation
7. Switch DNS or swap the document root when ready

Data Migration via CSV Import

PrestaShop's built-in import tool (Back Office → Advanced Parameters → Import) handles:

• Categories
• Products (with combinations, images, features, and stock)
• Customers
• Addresses
• Manufacturers and Suppliers

Export from your old store, clean up the CSV files, and import into the new one. This is tedious for large catalogs but gives you the cleanest result.

Data Migration via SQL

For experienced developers, direct SQL migration is faster for large datasets:

# Export specific tables from old database
mysqldump -u root -p old_prestashop \
  ps_product ps_product_lang ps_product_shop \
  ps_category ps_category_lang ps_category_shop \
  ps_customer ps_address \
  ps_image ps_image_lang ps_image_shop \
  ps_stock_available \
  > ~/migration_data.sql

# You'll need to review and adjust the SQL for schema changes between versions
# Column names, table structures, and foreign keys may differ

SQL migration requires deep knowledge of PrestaShop's database schema. If you're not comfortable writing and debugging complex SQL, use the CSV import method or hire a developer. A botched SQL migration can corrupt your data in ways that are extremely difficult to fix.

Which Approach Is Better?

For most store owners running PS 8.x with a reasonable number of well-maintained modules, the auto-upgrade is the right choice. Clean install makes sense when you're coming from a very old version or want to take the opportunity to clean house.

Module Compatibility: What Breaks in PrestaShop 9

This section is for developers and technically curious store owners. Understanding what changed helps you evaluate whether your modules will survive the upgrade.

Smarty Templates Removed from Admin

This is the biggest breaking change. In PS 8.x, legacy admin controllers could still use Smarty templates (.tpl files) for their back office pages. In PS 9, the admin is fully Twig-based. Legacy controllers are wrapped by a Symfony LegacyController that renders their output through Twig.

What this means in practice:

• Modules with custom admin pages using AdminController + Smarty still work, but they're rendered inside the new Twig layout via a compatibility layer
• Admin template overrides (files in override/controllers/admin/templates/) may not work as expected
• Smarty variables assigned in initContent() can be lost because LegacyController wraps the rendering differently — the Smarty content variable needs to be explicitly reassigned
• The display() method of AdminController is no longer called by PS 9 — LegacyController bypasses it entirely

Override System Changes

PrestaShop has been discouraging overrides since PS 1.7, and PS 9 tightens the restrictions further:

• Core class overrides still technically work but are increasingly fragile as more core code moves to Symfony services
• Controller overrides are unreliable — the Symfony routing layer may not load them as expected
• Template overrides in override/ directories are deprecated for admin pages
• The recommended approach is now hooks, Symfony decorators, and event subscribers

If you have modules that rely heavily on overrides, they're the most likely to break during the upgrade. Check the override/ directory in each module's folder.

Hook Changes

PrestaShop 9 adds new hooks and modifies some existing ones:

• Several legacy hooks in the admin area are removed or renamed
• New hooks are available for Symfony-based admin pages
• Front office hooks remain largely compatible (Hummingbird uses the same hook points as Classic)
• The hook execution order may change in some cases — if your module depends on being called before or after another hook, test this

Legacy Controller Deprecations

Several admin controller patterns that worked in PS 8.x behave differently in PS 9:

• $this->l() (the translation function) is removed from admin controllers — use $this->module->l('string', 'ControllerClassName') instead
• Tools::displayPrice() is removed — use Context::getContext()->getCurrentLocale()->formatPrice($amount, $currencyIsoCode)
• Admin controller $this->meta_title, $this->fields_list, and $this->bulk_actions must be assigned AFTER calling parent::__construct() because the module reference isn't available before that
• The admin directory is now backoffice/ by default (not admin-dev or a random string) — hardcoded admin paths will break

How to Check If Your Modules Are PS9-Ready

For each installed module:

1. Check the vendor's website — look for explicit PS 9 compatibility statements
2. Check for overrides — look inside modules/yourmodule/override/. Any files there are a yellow flag.
3. Check for deprecated function calls — search the module's PHP files for:
   • Tools::displayPrice(
   • $this->l( in admin controller files
   • AdminController classes with complex display() methods
   • Hardcoded admin directory paths
4. Check the module's config.xml or main PHP file for the ps_versions_compliancy setting — does it include 9.x?

# Quick command to find potential PS9 issues in a module
# Run this from inside the module directory

# Check for overrides
find override/ -type f 2>/dev/null && echo "WARNING: Module uses overrides"

# Check for removed functions
grep -rn "Tools::displayPrice" *.php controllers/ classes/ 2>/dev/null
grep -rn '$this->l(' controllers/admin/ 2>/dev/null

# Check version compatibility declaration
grep -A2 "ps_versions_compliancy" *.php

Theme Migration: Hummingbird Is Now Default

PrestaShop 9 ships with Hummingbird as the default theme, replacing Classic. If you're using Classic or a Classic-based theme, you need a migration plan.

What Changed in Hummingbird

• Bootstrap 5.3 replaces Bootstrap 4 — class names, grid system, and utility classes have changed
• CSS Custom Properties are used extensively for theming — colors, spacing, and typography are configured via CSS variables rather than SCSS variables
• Less JavaScript — Hummingbird relies more on native browser features and less on jQuery plugins
• Modern build system — Webpack-based asset compilation with proper tree shaking
• Responsive-first design — mobile layout is the base, desktop is the enhancement (unlike Classic which was desktop-first)

If You're Using the Classic Theme

Classic theme is not included in PS 9. Your options are:

1. Switch to Hummingbird — the simplest path. Create a child theme for your customizations.
2. Buy a PS9-compatible theme — many theme vendors have released PS9 versions.
3. Port your Classic customizations to a Hummingbird child theme — this requires frontend development work but gives you the best long-term result.

Creating a Hummingbird Child Theme

A child theme lets you customize Hummingbird without modifying core theme files (so your changes survive theme updates):

# Create child theme directory structure
mkdir -p themes/my-child-theme/assets/css
mkdir -p themes/my-child-theme/templates

Create themes/my-child-theme/config/theme.yml:

parent: hummingbird
name: my-child-theme
display_name: My Custom Theme
version: 1.0.0
author:
  name: Your Name

Add your custom styles in themes/my-child-theme/assets/css/custom.css. Hummingbird automatically loads custom.css from child themes at the lowest priority (loads last), so your styles will override the parent theme.

To override a specific template, copy it from themes/hummingbird/templates/ to the same relative path in your child theme. Only copy the files you need to change — everything else falls through to the parent theme automatically.

If You're Using a Purchased Theme

Contact your theme vendor and ask these specific questions:

• Is there a PS9-compatible version available?
• Is it based on Hummingbird or is it a standalone theme?
• Will my existing theme license cover the PS9 version?
• What's the migration path from the current version?

If the vendor doesn't have a PS9 version and can't give you a timeline, start planning your switch to Hummingbird now.

Post-Upgrade Checklist

You've completed the upgrade and your back office loads. Don't celebrate yet. Systematically verify every critical function of your store.

Front Office Testing

Back Office Testing

Payment Gateway Verification

This deserves its own section because it directly impacts revenue. For EACH payment method:

1. Place a real test order (or use sandbox mode if available)
2. Verify the payment is captured in the payment provider's dashboard
3. Verify the order status updates correctly in PrestaShop
4. Test refunds if your workflow requires them
5. Check webhook/IPN URLs — the upgrade may have changed URL structures

Shipping Verification

• Verify all shipping carriers display correct rates for different zones
• Test free shipping thresholds
• If you use real-time carrier rate calculation (API-based), verify the connection still works
• Check that tracking number entry and notification emails work

Cron Jobs

Check every automated task that runs on a schedule:

• Cart abandonment emails
• Stock synchronization
• Feed generation (Google Shopping, Facebook, etc.)
• Sitemap generation
• Currency rate updates
• Any custom cron scripts

Cron URLs often change between major versions. Update your crontab entries:

# Check your current cron jobs
crontab -l

# PS 9 cron URLs may have changed — verify each one loads correctly
curl -s -o /dev/null -w "%{http_code}" "https://yourshop.com/modules/yourmodule/cron.php?token=XXXXX"

SEO Verification

• Check that friendly URLs still work (category pages, product pages)
• Verify your sitemap generates correctly
• Check robots.txt is correct
• Test key landing pages that rank well — make sure they still exist at the same URLs
• If URLs changed, set up 301 redirects immediately

Common Upgrade Problems and Solutions

White Screen of Death

The most common post-upgrade issue. You see a blank white page with no error message.

Solution:

1. Enable debug mode by editing config/defines.inc.php:

   define('_PS_MODE_DEV_', true);

2. Reload the page — you should now see the actual PHP error
3. If you still see white screen, check PHP error logs:

   # Apache
   tail -50 /var/log/apache2/error.log
   
   # Nginx + PHP-FPM
   tail -50 /var/log/php-fpm/error.log
   
   # PrestaShop's own log
   tail -50 /var/www/html/var/logs/prod.log

4. Common causes:
   • PHP memory exhausted — increase memory_limit in php.ini to 512M
   • Missing PHP extension — install the required extension and restart PHP
   • File permission issue — run chown -R www-data:www-data /var/www/html/var/

500 Internal Server Error

Usually caused by .htaccess issues or PHP configuration problems after upgrade.

Solution:

# Check if .htaccess is the problem — temporarily rename it
mv /var/www/html/.htaccess /var/www/html/.htaccess.bak

# If the site loads without .htaccess, regenerate it from back office:
# Shop Parameters → Traffic & SEO → Generate .htaccess file

# Or manually restore the default PS 9 .htaccess

Also check:

• Apache mod_rewrite is enabled: a2enmod rewrite && systemctl restart apache2
• Your Apache virtual host allows .htaccess overrides: AllowOverride All
• PHP version is actually 8.2+ for the web process (not just CLI)

Module Conflicts After Upgrade

Symptoms: back office partially loads, errors in specific sections, JavaScript errors in the console.

Solution — the isolation method:

1. Disable ALL non-native modules:

   # Via database if back office is broken
   mysql -u root -p prestashop -e "UPDATE ps_module SET active = 0 WHERE name NOT IN ('ps_banner','ps_contactinfo','ps_emailsubscription','ps_featuredproducts','ps_imageslider','ps_linklist','ps_mainmenu','ps_searchbar','ps_sharebuttons','ps_socialfollow','ps_wirepayment','ps_checkpayment');"

2. Clear cache: rm -rf var/cache/*
3. Verify the store works with only native modules
4. Enable modules one at a time, clearing cache between each
5. When you find the problematic module, either update it, replace it, or contact the vendor

Missing or Broken Translations

After upgrade, some translation strings may be missing or display as raw keys (like Modules.YourModule.SomeString).

Solution:

• Go to International → Translations and export/import your language pack
• For module translations, reset the module's translations: uninstall and reinstall the module (note: this may reset configuration — back it up first)
• PrestaShop 9 uses Symfony's translation system more heavily — old-style translation files (in modules/yourmodule/translations/) may need to be converted

Cache Issues

Stale cache is behind a surprising number of post-upgrade issues. When in doubt, clear everything:

# Nuclear cache clear
rm -rf var/cache/*

# Symfony cache rebuild
php bin/console cache:clear --env=prod --no-warmup
php bin/console cache:warmup --env=prod --no-optional-warmers

# Fix ownership after cache rebuild
chown -R www-data:www-data var/

# Also clear your browser cache — old cached JS/CSS can cause phantom issues

Images Not Displaying

Image paths or the image retrieval system may change between versions.

Solution:

• Regenerate thumbnails: Design → Image Settings → Regenerate thumbnails
• Check that the img/ directory permissions are correct
• If using a CDN, purge the CDN cache
• Verify the new image URL format matches what your theme expects

Admin Login Not Working

Password hashing algorithms changed in PS 9 (Symfony's MigratingPasswordHasher with bcrypt/argon2). In most cases, existing passwords will work because the hasher auto-migrates on first login. But if you're locked out:

# Reset admin password — PS 9 requires Symfony's password hasher
# Do NOT use raw MD5 or direct SQL UPDATE on the password field

# Instead, use PrestaShop's CLI (if available):
php bin/console prestashop:user:change-password --email=admin@yourshop.com

# Or create a temporary PHP script to reset the password properly
# (delete this file immediately after use!)

Never leave password reset scripts on your server. Create them, use them, delete them — all in one session. A forgotten reset script is a security vulnerability.

When to Hire a Developer vs. DIY

Be honest about your technical skills. A failed upgrade can cost you days of revenue and customer trust. Here's a realistic guide:

You Can Probably DIY If:

• You're upgrading from PS 8.2 to 9.x (one version jump)
• You have fewer than 10 third-party modules, all confirmed PS9-compatible
• You're using a standard theme (Classic → Hummingbird, or a purchased theme with PS9 support)
• You're comfortable with SSH, command line, and database operations
• You have a working staging environment to test on first
• Your store has no custom overrides or core modifications

You Should Hire a Developer If:

• You're upgrading from PS 1.6.x or early 1.7.x (major version gap)
• You have 20+ modules, especially if some use overrides
• You have a custom theme that needs porting to Hummingbird
• Your store has custom core modifications or override files
• You're not comfortable with the command line or database operations
• Your store generates significant daily revenue and downtime is expensive
• You've attempted the upgrade on staging and encountered issues you can't resolve

What to Look For in a Developer

• Specific PrestaShop experience — not just "PHP developer" or "e-commerce developer." PrestaShop's architecture is unique, and generic developers will spend billable hours learning things a PS specialist already knows.
• PS 9 experience specifically — ask if they've completed PS 9 upgrades before. The Symfony 6.4 migration has specific gotchas.
• A clear project plan — they should propose: audit → staging upgrade → testing → production upgrade → monitoring.
• Post-upgrade support — issues often surface 1-2 weeks after upgrade when edge cases are triggered. Make sure support is included.

Typical Cost Ranges

These are rough estimates based on market rates in 2025-2026:

• Simple upgrade (PS 8.x → 9.x, few modules, standard theme): 500-1500 EUR
• Medium upgrade (PS 1.7.x → 9.x, custom theme port, moderate modules): 2000-5000 EUR
• Complex upgrade (PS 1.6.x → 9.x, full rebuild, many custom modules): 5000-15000+ EUR

These prices reflect the reality that a major version upgrade is not a click-and-done operation. If someone quotes you 200 EUR for a PS 1.6 → PS 9 upgrade, they either don't understand the scope or they're going to cut corners that will cost you more later.

Rollback Plan: If Things Go Wrong

You made backups (you did, right?). Here's how to use them if the upgrade fails catastrophically.

Rollback from Auto-Upgrade

If you used the 1-Click Upgrade module and it created its own backup:

1. Navigate to Back Office → Modules → 1-Click Upgrade
2. Click "Rollback" and select the pre-upgrade backup
3. The module will restore both files and database

If the back office is completely inaccessible, you'll need to restore manually:

Manual Rollback — Database

# Drop the current (broken) database and recreate it
mysql -u root -p -e "DROP DATABASE prestashop; CREATE DATABASE prestashop;"

# Import your backup
mysql -u root -p prestashop < ~/backup_pre_ps9_XXXXXXXX_XXXXXX.sql

# For Docker:
docker exec -i my-shop-db mysql -u root -p'PASSWORD' -e "DROP DATABASE prestashop; CREATE DATABASE prestashop;"
docker exec -i my-shop-db mysql -u root -p'PASSWORD' prestashop < ~/backup_pre_ps9_XXXXXXXX_XXXXXX.sql

Manual Rollback — Files

# Remove the upgraded files
rm -rf /var/www/html/*

# Restore from your backup
tar -xzf ~/prestashop_files_pre_ps9_XXXXXXXX_XXXXXX.tar.gz -C /

# Fix permissions
chown -R www-data:www-data /var/www/html/

# Clear cache
rm -rf /var/www/html/var/cache/*

Verify Rollback Worked

1. Access the front office — does your store load?
2. Access the back office — can you log in?
3. Check a few orders — is the data intact?
4. Place a test order — does checkout work?
5. Disable maintenance mode once everything is confirmed working

After a rollback, do NOT immediately attempt the upgrade again. Analyze what went wrong first. Check the upgrade logs, identify the failing step, research the specific error, and fix the root cause on your staging environment before touching production again.

The "No Backup" Emergency

If you didn't make backups (it happens — let's not pretend it doesn't), your options are limited but not zero:

• Hosting provider backups: Many hosts keep daily backups for 7-30 days. Check your hosting panel or contact support immediately.
• Database binary logs: If MySQL binary logging is enabled, point-in-time recovery may be possible. This requires expertise.
• The autoupgrade module's backup: If you checked "create backup" during upgrade, look in /admin/autoupgrade/backup/ for the module's own backup files.
• Accept and move forward: If recovery isn't possible, focus on fixing the upgraded store rather than trying to go back. Sometimes forward is the only way.

Summary: The Upgrade Path at a Glance

1. Audit — check server requirements, module compatibility, theme compatibility
2. Backup — database (mysqldump), files (tar), configuration notes
3. Stage — test the entire upgrade on a staging environment first
4. Schedule — pick a low-traffic window with buffer time for issues
5. Upgrade — maintenance mode on, run the upgrade, clear caches
6. Test — front office, back office, checkout, payments, shipping, emails
7. Monitor — watch error logs for 48 hours after going live
8. Clean up — disable debug mode, remove temporary files, update documentation

PrestaShop 9 is a significant improvement over its predecessors. The Symfony 6.4 foundation, PHP 8.2+ requirement, and Twig-based admin create a more stable, faster, and more maintainable platform. The upgrade requires careful planning, but the result is worth the effort — a modern e-commerce engine that will serve you well for years to come.

Take your time, test thoroughly, and don't skip the backups. Your future self will thank you.