PrestaShop migration services: to or from PrestaShop

PrestaShop is self-hosted open-source ecommerce software built on PHP and MySQL, with a strong installed base in Spain, France, Poland and Czechia. We see two groups. Stores moving off PrestaShop are usually tired of running upgrades, hosting and module compatibility themselves, or want to consolidate on a hosted platform such as Shopify or, in Czechia and Slovakia, Shoptet. Stores moving onto PrestaShop usually want full ownership of code and data, multistore, or a platform local agencies know well.

There are also PrestaShop-to-PrestaShop projects: a 1.6 store that cannot be upgraded in place because of years of overrides and abandoned modules is effectively rebuilt on a current version. We treat that as a migration, with the same audit, mapping and trial run, not as a one-click upgrade.

When not to move: if the real problem is a slow theme, a single broken module or poor hosting, fixing that is cheaper than a replatform. The assessment should tell you which case you are in.

Because PrestaShop is self-hosted, we can normally read the MySQL database directly, which is more complete than the CSV export in the back office or the webservice API. That matters because the useful data is spread across many tables: product, product_attribute for combinations, feature_product for features, specific_price for customer-group and quantity pricing, per-language tables for translated text, and _shop tables when multistore is active.

The pitfalls we look for first are overrides and custom modules that write their own tables or add columns to core tables, combinations that exist in the database but are disabled or have no stock, images stored per combination, and specific prices that no longer apply. Order history is readable, but order states, carriers and payment modules are store-specific, so orders are mapped rather than copied. Customer password hashes depend on the PrestaShop version and the cookie key, and a hosted target will not accept them.

Going into PrestaShop we load data through the CSV import for simple catalogs or through scripted imports and the webservice API for anything with combinations, multiple languages or customer history. The target model expects attribute groups and values to exist before combinations are created, features to be defined as reusable feature values, and every product to have a default category in the category tree.

The design decision to make early is what becomes a combination and what becomes a feature. Size and colour that affect stock and price are combinations; material or care instructions are usually features. Getting that wrong produces combinations nobody can filter or features nobody can buy. If you run several shops, multistore settings decide which products, prices and translations are shared, and that has to be designed before import, not fixed afterwards.

Most PrestaShop migrations need the same transformations in one direction or the other. Combinations become variants on platforms with option-based models, and PrestaShop allows more attribute groups per product than some targets accept, so we check the maximum per product before promising a one-to-one mapping. Features become metafields, custom fields or filterable attributes, depending on the target.

The category tree is flattened into collections on Shopify, or rebuilt as a tree on platforms that have one. Specific prices and catalog price rules rarely have a direct equivalent and usually become customer-group pricing, price lists or discounts. Multi-language text is split per language and checked for missing translations. Text fields with inline HTML, module shortcodes or absolute image URLs are cleaned so they render on the new theme.

A working PrestaShop store depends on modules for payments, carriers, invoicing, feeds, reviews, loyalty, blogs and ERP connections. Module data does not move by itself. Leaving PrestaShop, we list every active module, check what it stores and decide per module whether its data is exported, replaced by a target app or dropped with your agreement. Moving onto PrestaShop, we pick modules from PrestaShop Addons or plan custom development and load their data after the core import.

Themes do not transfer between platforms, and PrestaShop 1.6 and 1.7+ themes are not compatible with each other either, so the storefront is rebuilt. Checkout, payment gateways, shipping and tax configuration are rebuilt on the target and tested with real test orders. Integrations with ERP, accounting and marketplaces are reconnected and checked against live data before launch.

PrestaShop friendly URLs are configured under Shop Parameters > Traffic & SEO > SEO & URLs, and the default routes include the numeric ID of the product, category or CMS page. Combinations can also produce their own URLs with attribute fragments. When you leave PrestaShop, those ID-based paths cannot be reproduced on most targets, so every indexed URL needs a 301 to its new equivalent. Stores that never enabled friendly URLs have index.php?id_product= style URLs, which need query-string-aware redirects.

We crawl the live store before migration, pull top landing pages from Search Console and analytics, build the redirect map per language, and crawl again after launch to catch 404s and redirect chains. Moving onto PrestaShop, we configure routes and language prefixes before import so the new URLs are stable. We do not promise rankings; we make sure no indexed URL is left without a destination.

Customer passwords rarely survive a move to a hosted platform; customers set a new password through an account activation or reset email. Saved payment methods stay with the payment provider and are not migrated silently. Module-specific data such as loyalty points, gift cards or wishlist items may have no import path on the target and is scoped case by case.

Old 1.6 stores often carry data inconsistencies: orphaned combinations, duplicate references, products in deleted categories. We report these during the audit and fix them in mapping, not after launch. Very large multistore installations with different catalogs per shop may need to be split into separate target stores, which changes the URL and SEO plan.

The project starts with an audit: PrestaShop version, modules and overrides, catalog shape, multistore and languages, URL settings, integrations. From that we write the data mapping and agree on it with you. We then run a trial migration into the target, and you review products, customers, orders and URLs on a staging store before anything goes live.

After sign-off we agree a short content freeze, run the final migration plus a delta migration of new orders and customers, switch DNS, activate redirects and run post-launch QA: test orders, redirect checks, Search Console monitoring and a check of integrations. One named lead owns the whole sequence and is the person you talk to.