PrestaShop to Shopify migration

The usual trigger is operational load. PrestaShop is self-hosted open source, so your team owns hosting, PHP compatibility, security patching, core upgrades and the module stack. Shopify takes hosting, platform security and checkout PCI scope off your plate, and most of what modules did is replaced by apps.

It is not the right move for every PrestaShop store. If you depend on deep checkout customisation, pricing logic in overrides, or very different multistore shops, Shopify can still work, but cost moves into apps, custom apps or Shopify Plus. Sometimes a PrestaShop upgrade or clean-up is the better decision.

PrestaShop builds variants from attribute groups (size, colour, material) into combinations, each with its own reference, EAN, price impact, weight impact and stock. Shopify has products and variants with up to three option dimensions. Most combinations map directly: attribute groups become option names, combination references become variant SKUs, and price impacts are resolved into absolute variant prices. Products that use four or more attribute groups, or that use an attribute group for something that is not a real purchase choice, need a decision: split the product, merge option values, or move the dimension into metafields.

PrestaShop features (the specification table: fabric, capacity, country of origin) are not variants. We map them to Shopify metafields, usually typed product metafields or metaobjects when values are shared across many products, so they can drive filters in Shopify Search & Discovery and render in the theme. Inconsistent feature values are normalised before import.

Packs become bundles, virtual products need a digital-delivery app, and customization fields become line-item properties handled by the theme or an app. Specific prices and customer-group prices do not have a single Shopify equivalent; depending on your plan they become compare-at prices, automatic discounts or B2B catalogs, and we mark them as items to assess.

PrestaShop products sit in a nested category tree and can belong to several categories, with one default category that often appears in the product URL and breadcrumbs. Shopify has no category tree. It uses collections, manual or automated by rules, plus menus that you build to express hierarchy.

We rebuild the tree as collections deliberately: top-level and important sub-categories become collections with their own handles, descriptions and SEO fields, thin categories are merged with a redirect, and automated collections replace manual assignment where rules are clean. The default category is kept as a product metafield when it is needed for breadcrumbs or feeds, because Shopify product URLs do not carry a category.

Customer accounts, addresses, newsletter consent and customer-group membership move to Shopify, with groups usually becoming customer tags or segments. Guest checkouts in PrestaShop are handled separately so they do not become duplicate accounts. Customer passwords cannot be imported into Shopify, whatever hashing your PrestaShop version uses. Customers set a new password through Shopify's account invitation or activation flow, and we plan the timing and wording of that message with you.

Order history is imported as historical orders linked to customers, with line items, totals, taxes, shipping and status mapped from PrestaShop order states. Imported orders are records for customer accounts and reporting; they do not re-trigger fulfilment, payments or emails. Credit slips and invoice numbering stay authoritative in your accounting system.

PrestaShop friendly URLs are configured under SEO & URLs, and by default they usually contain numeric IDs, for example a product route like /{category}/{id}-{rewrite}.html or a category route like /{id}-{rewrite}, with a language prefix such as /en/ or /de/ when several languages are active. Combination links may add a #/ fragment for the selected attributes; fragments never reach the server, so they redirect with their parent product URL.

Shopify uses fixed paths: /products/{handle}, /collections/{handle}, /pages/{handle} and /blogs/{blog}/{handle}. None of the ID-based patterns survive, so every relevant URL needs a mapped target. We crawl the live PrestaShop store, combine it with the sitemap, Search Console and analytics landing pages, and map each URL to its Shopify equivalent, including language versions, CMS pages, manufacturer pages and blog posts. Redirects are loaded as Shopify URL redirects, which only apply when the old path no longer resolves to a page, so they are tested against the migrated store before DNS changes. After launch we recrawl and watch Search Console for 404s. Redirects protect URL continuity; they do not guarantee rankings.

Every active module gets a decision during the audit: replaced by a Shopify native feature, replaced by an app, rebuilt as a custom app or theme code, or retired. Typical candidates: payment and carrier modules, product comments, layered navigation, loyalty, feed exporters, invoicing and ERP connectors. Module data such as reviews, loyalty balances or wishlists lives in the module's own tables, so it is extracted separately and imported into the chosen app where the app supports it.

The theme is rebuilt, not converted: PrestaShop Smarty templates have no path into Shopify Liquid themes. Checkout customisation on Shopify is limited, and on Plus it uses Checkout Extensibility and Shopify Functions. Taxes and shipping are reconfigured, and ERP, PIM and feed integrations are re-pointed to Shopify and tested before launch.

PrestaShop multistore lets one install run several shops, grouped so they may or may not share customers, orders and stock, with per-shop prices, content and themes. Multilingual shops keep translations per language for products, categories and CMS pages. Shopify has no multistore mode inside one store.

The options are Shopify Markets, which serves several countries, currencies and languages from one store with translated content and localized URLs, or separate Shopify stores, which suit genuinely separate brands, assortments or legal entities. We decide this from how your shops actually differ: shared catalog with regional prices points to Markets; different catalogs, teams or checkouts point to separate stores. Translations import per language, and hreflang is checked after launch.

Audit: we review your PrestaShop database, modules, overrides, languages, shops and URL generations, and list open decisions. Mapping: combinations, features, categories, customer groups, order states and URLs are mapped in a document you sign off. Trial migration: a full data run into a development Shopify store, followed by checks on counts, prices, variants, translations and redirects, with a list of differences for you to review.

After sign-off we agree a content freeze, run the final migration, then a delta migration for orders, customers and stock changes made since the trial. Launch covers DNS, redirects, app configuration and payment tests. Post-launch QA runs through key templates, search, checkout, emails, feeds and Search Console. Scripts and automated comparisons help check the data; a person approves every production decision.

Customer passwords do not move. Some products will be restructured to fit three option dimensions. Customer-group pricing, complex cart rules and some module behaviour depend on apps or your Shopify plan. Invoice numbering, credit slips and payment tokens stay with PrestaShop, your accounting system or your payment provider. Search engines re-evaluate a site after a replatform, so we check what we can and do not promise traffic or positions.