E-commerce migration
Migrate to PrestaShopfor cost-effective, flexible eCommerce
A move to PrestaShop 9 is a server change and a catalogue change at once. Combinations, multistore settings and old modules take most of the time, so they get checked first.
Target PrestaShop 9, and check its requirements first
PrestaShop 9.0 moved to Symfony 6.4 and raised the minimum to PHP 8.1. PrestaShop 9.1 supports PHP 8.1 through 8.5. The database needs MySQL 5.7 or MariaDB 10.2 at minimum, though PrestaShop recommends a more recent version. For a store on 1.6 or 1.7, the hosting usually changes along with the application, so the plan starts with the server.
PrestaShop's own note gives Symfony 6.4 security fixes until November 2027. That doesn't make your store unsafe at that date, but it is worth knowing when you decide how long this version needs to last.
How the catalogue maps
PrestaShop models a product's variations as combinations: each combination pairs attribute values such as size and colour with its own reference, price impact and stock. Sources that store a variant as a full product need flattening, and sources with free-text options need turning into attribute groups first, or filters and layered navigation won't work well after launch.
Multistore is a feature that changes the import. Data can be shared across shops or differ per shop, and the shop context in force at import decides where a value ends up. Stores with several countries or brands need a written decision per field before any data moves.
Ways to bring the data in
- The Webservice API is PrestaShop's CRUD API for third-party tools. It suits repeatable rehearsals, because the same script runs against every test import.
- The new API in version 9 is built on API Platform. We check coverage for the resources you need before relying on it for an import.
- CSV import in the back office works for smaller catalogues and simple product structures. We wouldn't rely on it for order history.
What usually goes wrong
- Modules and themes written for older versions, especially those overriding core classes. Each one needs checking against version 9, and an override may need a rewrite.
- Friendly URLs. PrestaShop's URL patterns are configurable, so matching the old ones saves redirects, but only if IDs and slugs carry across as planned.
- Customer passwords. Their hashes depend on the source platform, so we test logins early and plan a reset message if they can't be carried across.
- Tax rules and carriers by zone, which are configured rather than imported and need testing with real addresses.
What we can show you
We have no published PrestaShop migration. Our published commerce work is on WooCommerce, with order and customer sync into Microsoft Dynamics. Both are PHP platforms with similar operational problems, but they aren't the same system. We would rather you hear this now than find out later.
PrestaShop migration questions
Can we upgrade an old PrestaShop in place?
Sometimes. It depends on your version, modules and how many core overrides the store has. For a heavily customised 1.6 store, a fresh version 9 install with imported data is often cleaner than stepping through upgrades. We decide after reading the code.
Which PHP version should the new server run?
One that your PrestaShop version and modules support. PrestaShop 9.2 still accepts PHP 8.1, but PHP 8.1 is no longer on php.net's supported list, so we would pick a supported branch and test your modules against it.
What are you moving from, and which modules can't you lose?
Tell us your current platform and version and the modules your store depends on. We will come back with what fits version 9 and what doesn't.
We reply within one business day (IST).