In 2026, a significant share of PrestaShop stores still run under version 1.7 — released in 2016, declared end-of-official-support by PrestaShop SA in 2024, and now without security fixes since the end of 2025. These stores accumulate risks: incompatibilities with recent PHP, abandoned 1.7 modules, unpatched vulnerabilities, performance tanked by legacy hooks, and inability to use the modern PS8 catalogue (smart cross-sell, AI FAQ, AEO, clean multi-country).
Migrating to PrestaShop 8 is no longer optional in 2026 — it’s an eventual obligation. But it’s a project in itself, not a click in the back-office. This article details the complete 1.7 → 8 migration checklist: prior audit, modules to replace, data management, SEO and redirect criticality, and the opportunity to modernise the technical stack along the way.
Why migrate in 2026 (and why waiting becomes risky)
Three forces converge in 2026 to make the 1.7 → 8 migration unavoidable.
End of security support. PrestaShop SA no longer issues security fixes for the 1.7 branch since the end of 2025. Any vulnerability discovered after that date remains exploitable, and the quantity of 1.7 stores still online makes it a prime target for attackers. In recent audits, several 1.7 stores were compromised via vulnerable third-party modules no longer maintained — defaced admin, hijacked payment tunnel, exfiltrated customer data.
PHP incompatibility. PrestaShop 1.7 officially supports only PHP 7.4 and some PHP 8.0 versions. But PHP 7.4 has been EOL since November 2022, and most hosts have withdrawn or are withdrawing PHP 7.4 from their offerings. 1.7 stores forced to run on PHP 8.1 or 8.2 experience random bugs (warnings, deprecated, broken implicit casts) that degrade operation.
Inaccessible modern PS8 catalogue. All modern 2026 e-commerce modules (AI FAQ, AEO via llms.txt, weighted cross-sell with analytics, extended Schema.org markup, clean multi-country with automatic hreflang) are developed for PrestaShop 8. The 1.7 versions of these modules, when they exist, are degraded ports — limited features, lesser performance, support stopped.
The economic trade-off is simple: the cost of a serious 2026 migration (typically €5,000 to €25,000 depending on store size and complexity) is lower than the cumulative cost of staying on 1.7 — security flaws, loss of modern modules, performance degradation, customer loss due to PHP bugs.
The prior audit: what to know before migrating
Before any quote or migration planning, a complete audit of your current 1.7 store. Without this audit, you discover complications during the project and the budget explodes.
Installed modules inventory. List all modules activated on the store. For each: version, status (active / deactivated / orphan), author, last update date, and availability of a PrestaShop 8 version. On mature 1.7 stores, you typically find 30 to 80 modules of which 20 to 40% are actually abandoned or orphan — deactivated long ago, with no active use. Those disappear automatically at migration.
Custom modifications inventory. Class overrides in override/classes/, controller overrides, Smarty template modifications, direct mods in the core code (frequent anti-pattern practice on older 1.7 stores). All these modifications must be recorded and documented — they won’t survive the migration without manual intervention.
Theme audit. If you use a custom theme (and not a native classic-rocket or Hummingbird theme), check its PS8 compatibility. Many commercial 1.7 themes are never ported to PS8 — your choice is then between buying a new PS8 licence of the same theme (if available), choosing a new PS8 theme, or having the custom theme ported by a developer (expensive).
Data audit. Volumetrics of products, orders, customers, reviews. A migration of a store with 500 products and 5,000 orders takes a few days of work. A migration of a store with 50,000 products and 500,000 orders takes several weeks with logistical coordination (prod freeze, switchover window).
SEO audit. Top 100 pages with organic traffic, top 100 pages with backlinks, current URL structure. This data is critical for planning 301 redirects (subject of a dedicated section below).
The broken 1.7 modules to replace
On migrations we’ve supported, here are the module categories that systematically pose problems.
1.7 cross-sell modules. The related-product modules in version 1.7 (pscrosssellsproducts, enriched blockcategories, certain third-party modules) don’t work in PS8 and their PS8 equivalents are often rebranded. Take advantage of the migration to switch to modern cross-sell with analytics and weighted strategies — a topic covered in our article on 7 cross-sell strategies for 2026. Recommended module: DataFirefly Cross-Sell.
1.7 review modules. Native PS 1.7 review modules (productcomments) and old third-party modules don’t generate clean Schema.org AggregateRating + Review markup — so no stars in the SERP, no citation in Answer Engines (AEO topic covered in our dedicated article). To replace with a modern module like DataFirefly Verified Reviews which covers complete markup.
1.7 product FAQ modules. Most 1.7 FAQ modules are hardcoded Smarty without AI handling or clean Schema.org. The move to PS8 is the opportunity to switch to a FAQ module with mass AI generation like DataFirefly Product AI FAQ — massive time saving on writing and valid Schema.org markup.
1.7 wishlist modules. 1.7 wishlists are generally basic (add / remove / list) without anonymous email capture, without price alerts, without analytics. To replace with DataFirefly Advanced Wishlist — topic covered in our article on the wishlist as a conversion lever.
1.7 side cart / sidecart modules. Often absent in 1.7 (the cart was a dedicated page, without sidecart). To add in PS8 with DataFirefly SideCart which modernises the post-add-to-cart experience.
1.7 multi-country SEO modules. 1.7 hreflang modules are often partial and don’t handle reciprocity or ISO codes correctly. To replace with DataFirefly Hreflang module + Country Switcher.
1.7 payment modules. Old 1.7 payment modules are often incompatible with modern SCA / 3DS2 requirements, or non-PSD2 compliant. Most banks and processors (Stripe, Mollie, Adyen, BNP, Société Générale, Crédit Mutuel via Mercanet) have modern PS8 modules to activate as replacements. To test rigorously before switching to prod — a broken payment in prod is lost revenue.
1.7 analytics tracking modules. Legacy 1.7 GA Universal or GTM modules don’t support Consent Mode v2 (mandatory in 2026 for Google Ads / GA4). To replace with Google Tag Pro or similar that handles Consent Mode v2 natively, plus Cookie Manager Tarteaucitron for the CMP.
Data management: clean import / export
Data migration is technically the riskiest part. PrestaShop doesn’t provide a reliable native 1.7 → 8 migrator — the existing Module Migration Manager has known limitations on complex catalogues.
The proven approach:
Step 1 — Clean export from 1.7. CSV / XML export of products, categories, customers, orders, reviews, descriptors (features, attributes). Keep original IDs to be able to map SEO redirects afterwards.
Step 2 — Clean PS8 installation. On a dedicated environment (staging), install PS8 from scratch with a compatible theme and basic modules. Don’t reinstall 1.7 modules — install the modern PS8 equivalent versions.
Step 3 — Structured import. Import in order: categories → features → products → product images → customers → addresses → orders → reviews. Order matters because some tables reference others (a product references a category that must already exist).
Step 4 — Consistency check. Count the number of rows per table after import, compare to 1.7 source counts. Test a few product pages, categories, orders to verify everything is visually consistent.
Step 5 — Functional tests. Complete journey on staging: navigation, add to cart, checkout, payment (in test mode), confirmation. Also test admin features (order management, product management, customer management).
SEO and 301 redirects: the part most often missed
URLs change between PS 1.7 and PS 8, sometimes subtly (slug structure, parameter handling, multilingual addition). Without a systematic 301 redirect plan, you lose all your accumulated SEO authority.
URL types to map:
- Product URLs: old format
/category/123-product-slug.htmlvs new format/category/product-456(or inverse depending on your config). Map product by product. - Category URLs: may change if the hierarchy or slugs have been adjusted.
- CMS / static page URLs: to map individually.
- Suppliers / brands URLs: if you used them in 1.7.
- Parameterised URLs with filters: to map to the new PS8 faceted search URLs.
Practical implementation: a 301 redirects file in .htaccess or nginx config, or a PS8 redirect module (several exist in the marketplace) that manages them from the database. For very large catalogues (10,000+ products), automate the mapping via script that reads the old sitemap and generates redirects to the new URLs based on slugs or SKUs.
And critically: monitor Search Console for 4-8 weeks after the switch to detect 404 errors. Each 404 reveals an old URL that wasn’t redirected — to add to the redirects file as you go.
The migration checklist in 12 steps
- Complete audit of the current 1.7 store (modules, theme, custom code, data, SEO).
- PS8 theme choice (replica of the current theme or new choice).
- PS8 module choice for replacements, with audit of modules to abandon.
- PS8 environment provisioning (hosting, PHP 8.2+, MySQL 8 / MariaDB 11, SSL certificates).
- Clean PS8 installation and basic configuration (languages, currencies, multilingual, countries).
- Installation of selected PS8 modules and configuration.
- Data import from the 1.7 export (categories, products, customers, orders).
- 301 redirects production mapping old URL → new URL.
- Exhaustive functional tests on staging (navigation, checkout, admin).
- Production switch (DNS, certificates,
.htaccessor nginx config with redirects). - Post-switch monitoring Search Console, GA4, server logs, customer feedback.
- Corrective iteration on bugs detected in prod (count 2-4 weeks of post-switch polish).
On the migrations we’ve supported, the complete project lasts between 4 and 12 weeks depending on store size and customisation complexity.
The opportunity to modernise the stack along the way
A 1.7 → 8 migration isn’t just a technical upgrade, it’s also the opportunity to modernise the e-commerce stack accumulated over years without cleanup.
Admin security. Take advantage of the migration to enable admin 2FA via 2FA Google Authenticator for PrestaShop. It’s essential protection in 2026 that many 1.7 stores neglect.
AEO stack. Take advantage of the migration to align your store with 2026 AEO standards (topic covered in our AEO category). The combo LLMs.txt PrestaShop + AI FAQ + Verified Reviews positions your store for ChatGPT / Perplexity / Google AI Overviews traffic.
Recurring revenue via subscriptions. If your catalogue allows it (consumables, boxes, digital services), take advantage of PS8 to add the DataFirefly Subscriptions module with Stripe — topic covered in our subscription tunnel guide. Recurring on PrestaShop 1.7 was particularly hacky; on PS8 it’s mature.
Modern conversion stack. Beyond replacing broken modules, take advantage of the migration to add the levers you didn’t have in 1.7: free shipping bar with progress bar, sidecart, wishlist with alerts, product videos with clean CWV. A migration without modernisation is a technical refresh without business gain.
Frequent errors in 1.7 → 8 migration
Believing the migration takes 2 days. On low-cost quotes promising a 2-day migration, you systematically recover a broken store. The realistic minimum is 2-3 weeks for a simple store, more for complex ones.
Neglecting 301 redirects. Post-migration SEO traffic loss is typically 30-60% without a complete redirect plan. With a plan, you recover 90-100% in 4-8 weeks.
Keeping all 1.7 modules. Migration is the opportunity to prune. Stores that try to port everything identically find themselves with a PS8 weighed down by 50 modules half of which are legacy.
Doing the migration directly in prod. Without staging, without tests, without rollback plan. It’s the guarantee of drama. Any serious migration goes through staging with exhaustive validation.
Underestimating user training. The PS8 admin is different from PS 1.7 — changed workflows, reorganised screens, some functions moved. Operational teams (order management, customer support) must be trained before the switch, not discover the new admin on the go-live morning.
Conclusion: a structuring project that modernises your e-commerce business
The PrestaShop 1.7 → 8 migration isn’t a simple technical update — it’s a project that deserves direction sponsorship, a calibrated budget, and rigorous planning. Stores that take the topic seriously come out of the migration with a modern, secure, performant store aligned with 2026 e-commerce standards. Stores that botch it lose SEO traffic, revenue for weeks, and accumulate technical debt that will have to be paid later.
The typical investment for a serious migration is €5,000 to €25,000 depending on size (SME: €8-15K, mature e-commerce: €15-25K), plus the cost of new replacement modules (generally €500-2,000 depending on the chosen stack). ROI is measurable in 6-12 months post-migration via the modernisation of conversion levers and the release of SEO potential blocked by 1.7 limitations.
To dig deeper into related topics, browse our Performance & Core Web Vitals and PrestaShop Tutorials categories. And to assemble the modern PrestaShop 8 post-migration stack (cross-sell, verified reviews, AI FAQ, sidecart, wishlist, free shipping, multi-country, AEO), the entire DataFirefly catalogue is aligned with 2026 patterns — performance-first, clean code, French-speaking support, regular updates.