Migrating PrestaShop 1.7 to 8 with zero downtime

PrestaShop 8 is worth the pain

If you are running PrestaShop 1.7 in 2026 you are on a maintenance runway that ends soon. PrestaShop 8 is faster, more modular, and — critically — supported. The catch is that the migration is not a button. Custom modules break, overrides break, themes break, payment integrations sometimes break.

Below is the playbook I use for zero-downtime migrations on stores with tens of thousands of SKUs and real customer traffic.

The blue-green setup

• Blue — the current 1.7 store, serving customers.
• Green — a new PrestaShop 8 instance running against a copy of the database.
• A one-way sync from blue to green, running continuously.

You cut over when green is verified. If anything goes wrong you flip DNS back to blue. Nobody sees a maintenance page.

Schema delta strategy

The naive approach is a full mysqldump and restore. On a 40 GB store that is hours of downtime and hours of catching up on missed orders.

The approach that works:

• Take a full snapshot into green at T0.
• Replay every write since T0 as a delta.
• At cutover, stop writes to blue for 30 to 90 seconds, drain the queue, flip DNS, resume.

Tools I actually use:

• mysqldump --single-transaction for the initial snapshot.
• A change-data-capture stream from binlogs (mysqlbinlog piped to a small consumer) for the delta.
• A hand-written diff pass on the last 60 seconds to guarantee nothing was missed.

Modules and overrides

This is where most migrations die. Rules I stick to:

• Never migrate an override. Rewrite it as a module hook.
• Custom modules get compatibility-tested first. Half of PrestaShop 1.7 modules die on PrestaShop 8 because of Smarty template changes and PHP 8.2 strict types.
• Payment modules are the highest risk. Test in sandbox with real 3DS2 flows before cutover.

Budget a full week per non-trivial module for the compatibility pass. Do not skip this and hope.

Cache warm-up

PrestaShop 8 with Symfony cache and Redis is fast — but the first request to a cold cache is slow. Warm before cutover:

• Crawl every category and product page.
• Prime the Symfony container cache.
• Prime OPcache with a preload script.

The cutover checklist

• Freeze deploys 24 hours before.
• Announce the cutover window to the merchant.
• Stop cron on both stores.
• Drain the order queue.
• Flip DNS with a low TTL set 24 hours earlier.
• Watch error logs and payment success rate for 60 minutes.
• Only then, re-enable cron on green and archive blue.

What I have learned

The best migrations feel boring on the day. All the drama happens in the two weeks before, when you find every module override the previous team forgot to document. Give yourself that time and the cutover itself takes an hour.