PrestaShop 1.7 to 8 migration: proven methodology

After migrating around thirty stores from version 1.7 to version 8 of PrestaShop, I've settled on a methodology that works reliably, regardless of catalog size or the complexity of past customizations. PrestaShop 1.7 is gradually reaching the end of its support cycle, and stores still running on it accumulate growing security risk on top of missing out on real performance gains. Here's how I proceed for my clients, phase by phase.

Phase 1 — Preparation and audit (1 to 2 weeks)

Nothing should be improvised. The first step is a complete audit of the existing store: an exhaustive list of installed modules, distinguishing native PrestaShop modules from third-party ones, an inventory of the theme (native, classic-theme child, or fully custom), and above all precise documentation of every specific customization (class overrides, custom hooks, direct SQL queries). This phase takes time, but it prevents 80% of nasty surprises during the migration itself. I then build a list of modules incompatible with version 8, contacting vendors directly when needed.

Phase 2 — Test environment

Never migrate straight to production. I always clone production into an identical staging environment (matching server config where possible). There, I first upgrade PHP to at least 8.1 (often 8.2), since PrestaShop 8 requires it. I then migrate to the latest stable PrestaShop 8.x.x release. Every error encountered is documented along with its fix — this knowledge base is what speeds up subsequent migrations.

Phase 3 — Theme adaptation

The classic theme has evolved considerably between 1.7 and 8: the Smarty templating engine moved to version 4, which breaks certain outdated syntax. I systematically check for deprecated hooks (several hooks used in 1.7 no longer exist or have changed behavior) and manually test every critical user journey: product page, add to cart, the full checkout tunnel, customer account, search. An old custom theme often requires 3 to 5 days of rework.

Phase 4 — Third-party modules

This is often the main blocking point. For each third-party module still in use, I contact the vendor to get a PrestaShop 8-compatible version; unfortunately, some vendors have abandoned their modules altogether, which forces you to either find an equivalent alternative or recode the feature in-house if it's specific to the client's business.

Phase 5 — Go-live

I always pick a low-traffic window (night, early morning, or a quiet day depending on the sector). The site goes into maintenance mode, the database is migrated, and then a battery of post-migration tests runs: an end-to-end test order, checking transactional emails, and reviewing SEO (URLs, redirects, sitemap). If hosting changes at the same time, the DNS cutover is planned with a lowered TTL beforehand to minimize downtime.

Concrete benefits observed

Across all the migrations I've carried out, I see on average +30% performance (load time and back-office responsiveness), native compatibility with PHP 8.2 and its future versions, a noticeably more ergonomic back office for teams managing the catalog day to day, and stronger security thanks to patches and version 8's modernized architecture.

How much it costs and how long it takes

For a store of average complexity (a simple custom theme, 10-20 third-party modules, a catalog of a few thousand products), plan for roughly 3 to 6 weeks of actual work spread across these 5 phases, with a budget that varies significantly depending on the original level of customization. Stores with a fully custom theme and many specific modules naturally need more time than those that stayed close to the native theme.