PrestaShop Development

Migrating from PrestaShop 1.6 to 8 or 9: what you need to know before you start

David Miller Published: Apr 25, 2026 Updated: PrestaShop Development

183 views 7 min read

Reviewed June 2026 for PrestaShop 8.x and 9.x as migration targets. PrestaShop 9 runs on Symfony 6.4 and PHP 8.1+; PrestaShop 1.6 has been end-of-life since October 2023. Plan against a supported target, not 1.7.

Let us be direct: there is no "upgrade button" that takes a PrestaShop 1.6 store to version 8 or 9. The architectural differences are too large. This is a migration, rebuilding your store on a modern foundation while preserving your data, SEO equity, and customer relationships.

Why It Is Not a Simple Upgrade

Between 1.6 and modern PrestaShop, almost everything changed:

Framework, 1.6 uses a custom MVC framework. Modern versions use Symfony.
Themes. 1.6 Themes are completely incompatible with 1.7+ themes. Your theme must be replaced.
Modules. Many 1.6 modules need replacement or significant rewriting. Hook names changed, admin controllers changed, the entire module API evolved.
Database, Schema changes, new tables, modified relationships. Data migration is possible but requires transformation.
PHP version. 1.6 Runs on PHP 5.x/7.0. Modern versions require PHP 8.1+. Your hosting must support this.

The Migration Process

Phase 1: Audit (1-2 Weeks)

Start with a hard inventory, not memory:

SELECT m.name, m.version, m.active
FROM ps_module m
ORDER BY m.active DESC, m.name ASC;

find override themes -type f \
  \( -name '*.php' -o -name '*.tpl' -o -name '*.js' -o -name '*.css' \) \
  | sort

Module inventory, List every installed module and its function. For each, determine: is there a compatible version for the target PrestaShop? Is there an alternative? Can we do without it?
Customization inventory, Document every override, custom module, theme modification, and workaround. These need to be reimplemented.
Data assessment, Products, categories, customers, orders, CMS pages, SEO metadata. What must migrate? What can be left behind?
URL mapping, Export every indexed URL from Google Search Console. Every URL that drives traffic and changes needs a redirect to its new equivalent; unchanged URLs should remain accessible.

Phase 2: Build (2-4 Weeks)

Set up a fresh installation of the target PrestaShop version on a staging domain
Install and configure your chosen theme (Hummingbird or a child theme)
Install modules, prioritize essential modules first
Configure the store: tax rules, shipping carriers, payment methods, languages, currencies

Phase 3: Data Migration (1-2 Weeks)

Categories, Migrate category tree structure, descriptions, images, and SEO metadata
Products, Products, combinations, images, descriptions, prices, stock levels, features, and attributes
Customers, Customer accounts and addresses (password migration depends on the migration method; resets may be required)
Orders, Historical orders for reference. Not always necessary but useful for customer service.
CMS pages, Static content pages, terms and conditions, etc.

Use PrestaShop's import tool for structured data or dedicated migration tools (Cart2Cart, MigrationPro) for automated transfers. Always verify data after import. Automated tools can miss edge cases.

Phase 4: SEO Preservation (1 Week)

Native PrestaShop does not ship a built-in XML sitemap generator. Use gsitemap or a dedicated sitemap module, then verify the generated URLs after migration.

Friendly URL redirect history for migrated PrestaShop URLs

URL history is where you confirm old catalogue URLs still resolve after the migration.

Advanced SEO Sitemap Builder URL list where every row shows a Skipped status, HTTP 200 and a redirect reason

Each listed URL shows its type, a Skipped status and a redirect reason, so 301-ing URLs stay out of the sitemap.

This is the most critical phase. Bad URL handling during migration can destroy years of search rankings.

Configure Friendly URL patterns to match your old URL structure where possible
Create 301 redirects for every URL that changed using SEO Revolution
Verify all redirects work with a crawl tool
Submit the new sitemap to Google Search Console
Monitor search rankings closely for the first 4-6 weeks

For a changed URL, a 200 on the old path is not redirect success; an unchanged URL should continue returning 200. After you map an old URL to its new equivalent, the only thing that protects your ranking is the old URL answering with a 301 (permanent) to the new one. A 302 (temporary) tells Google to keep the old URL, exactly backwards, and a 200 on the old path means you accidentally kept two live copies. Verify status codes in bulk before you submit anything to Search Console:

# old-urls.txt = changed indexed URLs only, one per line; verify unchanged URLs separately for 200 responses.
while read url; do
  code=$(curl -s -o /dev/null -w '%{http_code}' -A 'Mozilla/5.0' "$url")
  dest=$(curl -s -o /dev/null -w '%{redirect_url}' -A 'Mozilla/5.0' "$url")
  echo -e "$code\t$url\t-> $dest"
done < old-urls.txt | grep -vE '^301'   # anything that is NOT a 301 needs attention

For the changed URLs in this list, any remaining line needs review; also follow each redirect to confirm its intended destination returns 200. Fix those before the new store goes live, not after Google has re-crawled and dropped the page.

Phase 5: Testing (1 Week)

Test every customer-facing flow on the staging site before going live. Product browsing, search, filtering, cart, checkout (with every payment method), account management, and mobile experience.

Phase 6: Go Live

Switch during a low-traffic period. Keep the old store accessible (read-only) for 48 hours in case of critical issues requiring rollback. Monitor everything: uptime, page speed, conversion rate, and search rankings.

Realistic Expectations

Timeline, 6-12 weeks for a store with 500+ products and significant customization. Do not rush it.
Cost, If hiring a developer: €2,000-10,000+ depending on store complexity. DIY is cheaper but takes longer.
SEO impact, Expect a temporary 10-30% drop in organic traffic during the first 2-4 weeks, recovering fully within 2-3 months if redirects are properly configured.
Customer communication, Warn customers about any required password reset and any visual changes.

FAQ

Should I migrate to PrestaShop 8 or straight to 9?

If you're starting the project now, target 9 unless a module you depend on has a confirmed 8.x version but not a 9.x one yet. PrestaShop 9 moved to Symfony 6.4 and dropped some long-deprecated APIs, for example Tools::displayPrice() and AdminController::ajaxDie() are gone, so a few older modules need a compatibility update to run on it. Check your must-have modules' supported versions first; that compatibility list, not your preference, decides 8 versus 9.

Can I migrate directly from 1.6, or do I have to go through 1.7 first?

You rebuild on the target version directly. You do not chain upgrades through 1.7. Because 1.6 and 1.7+ are architecturally different platforms (custom framework versus Symfony, incompatible themes), there's no benefit to stopping at 1.7. Stand up a fresh 8 or 9 install on staging and migrate data into it. Going through 1.7 just means doing the hard migration twice.

Why can't customer passwords come across?

PrestaShop stores passwords as one-way hashes; whether existing logins remain usable depends on how the migration method handles those hashes. Email addresses, names, and addresses can migrate; check whether your migration method also preserves customer logins or requires password resets. If resets are required, plan a "reset your password" email for launch day and warn customers in advance so the reset prompt doesn't read like a phishing attempt.

How long should I keep the old 1.6 store running?

Keep it reachable and read-only for at least 48 hours so you can roll back if checkout or payment breaks in a way staging didn't catch. Keep a full database and file backup far longer, months, not days. The most common "we need to check the old store" reason after launch is customer-service lookups on historical orders you chose not to migrate.

Do I really lose rankings during a migration?

A short dip is normal as Google re-crawls and re-evaluates the new URLs; a permanent loss is not, and it's almost always caused by broken or missing 301s rather than the migration itself. The stores that recover fully in a couple of months are the ones that mapped every indexed URL, preserved unchanged URLs, returned proper 301s for changed URLs, and resubmitted a clean sitemap. The stores that don't recover skipped the URL audit. Phase 4 is where you win or lose this.

Migration is a significant project, but the payoff is real: better security, better performance, access to modern modules, and a platform that continues to receive updates and improvements. Plan thoroughly, execute methodically, and your store will be stronger on the other side.