PrestaShop to Shopify migration: method, risks and checklist
Contents
Migrating a catalogue of 440 PrestaShop categories to Shopify without losing years of accumulated organic traffic is the kind of project where a structural mistake gets expensive fast. Here is how it went on a furniture and home decor e-commerce site, and what the method looks like when applied to any deep CMS catalogue.
The starting point
The site had been running on PrestaShop for a long time, with a catalogue that ran deep: 440 categories organised across several levels of hierarchy, dozens of suppliers, and order flows specific to each partner. Maintenance was becoming time-consuming, the CMS demanded constant security vigilance, and the hosting was showing its limits against the size of the catalogue.
The goal: move to Shopify for admin and checkout, with a custom Hydrogen storefront to preserve the depth of the furniture catalogue, without losing any of the existing search rankings.
What actually has to be migrated
“Migrating from PrestaShop” sounds like exporting a CSV and importing it. In practice the data splits into four groups, and only the first one is straightforward:
Products and variants. The mechanical part. Attributes and combinations map reasonably well onto Shopify options and variants, as long as you check the 100-variant-per-product limit and how declinations were modelled in PrestaShop.
Category structure. The hard part, covered below. PrestaShop trees and Shopify collections are not the same object.
Customers and order history. Customers migrate without passwords, which means a reset flow at launch. Order history is often better kept read-only rather than fully reimported, depending on what customer service actually needs.
Content and business logic. CMS pages, blog posts, specific price rules, supplier modules. This is where PrestaShop stores things Shopify has no native slot for, and where the scope of the project is really decided.
The main constraint: category hierarchy
PrestaShop and Shopify don’t model categories the same way. PrestaShop handles a deep native tree structure. Shopify works through collections, which are flatter by default. Faithfully reproducing 440 categories with their parent/child relationships required an extra layer.
The solution: a metafield system with a collection_reference type, allowing each Shopify collection to reconstruct its parent position in the original tree. Every collection knows its exact place in the original hierarchy, which makes it possible to reproduce breadcrumbs and navigation identically, two elements that are critical for the SEO of a deep catalogue.
The architecture put in place
The project wasn’t limited to the storefront. A custom ERP was built to handle what Shopify doesn’t cover natively in a multi-supplier context:
A Supabase database structured around several key tables: suppliers, product variants, supplier catalogue imports, Shopify sync queue, orders.
Event-driven sync rather than cron-based. Instead of a scheduled job running every X minutes, the architecture relies on a sync queue triggered by events through Next.js Server Actions. A change on the supplier side immediately triggers an update on the Shopify side, without waiting for the next cron run.
About twenty suppliers integrated with their own order templates and flow specifics, each with its own formatting rules and import frequency.
n8n automation to orchestrate recurring tasks across the different systems (catalogue import, stock alerts, supplier follow-ups).
The general lesson applies well beyond this project: on PrestaShop, supplier and pricing logic often lives inside modules bought years ago and adapted since. Shopify won’t host that logic, so a replatform has to decide early where it goes, whether that’s an external service, an ERP, or automation tooling.
The SEO migration, item by item
With 440 categories, the smallest approximation in the redirect plan can wipe out a whole segment of organic traffic. The method followed:
- Full export of the PrestaShop tree with all associated metadata (title, description, URL, position in the tree).
- Systematic mapping of every PrestaShop category to its matching Shopify collection, keeping the URL slug wherever possible.
- A 301 redirect plan for URLs that couldn’t be kept identical.
- Rebuilding hierarchy metafields so that navigation and breadcrumbs reflect the old structure exactly.
- Manual verification of high-traffic categories before the switchover, as a priority.
Two PrestaShop specifics are worth flagging because they catch people out. Shopify forces /collections/ and /products/ prefixes into URLs, so a PrestaShop URL structure can rarely be reproduced character for character, which makes the redirect map mandatory rather than optional. And PrestaShop faceted navigation often generated a large number of indexed filter URLs, which need an explicit decision at migration time: redirect the ones that earn traffic, and let the rest go rather than dragging them into the new site.
The risks worth naming
Losing rankings on deep pages. Homepage and top-level collections usually recover quickly. Level-three and level-four categories, which often carry the long-tail traffic on a big catalogue, are the ones that disappear quietly if the mapping was done by pattern rather than page by page.
Breaking supplier flows on launch day. The storefront gets all the attention, but a broken stock sync is the failure that costs money the same week.
Underestimating content. CMS pages, buying guides and blog archives are frequently discovered late, after the catalogue plan is already agreed.
Losing customer accounts. A password reset at launch is expected, but it needs to be communicated, not sprung on people at their next order.
Liquid or Hydrogen for the new storefront?
A PrestaShop replatform poses this question at the worst possible moment, because you’re rebuilding everything anyway. Two things settle it in practice.
A Liquid theme is the faster, cheaper landing point and it’s the right call when the catalogue, once flattened, actually fits standard Shopify merchandising. Most PrestaShop stores fall here.
Hydrogen earns its place when the thing you’re migrating is precisely what Shopify handles flatly: a deep tree that needs faithful breadcrumbs and navigation, specific filtering, or a storefront that has to query an external system in real time. That was the case here, and the Liquid versus Hydrogen comparison goes through the trade-off in more detail.
Either way the migration work described above is identical. The storefront choice changes the build, not the data modelling or the redirect plan.
How long it takes
A CMS to Shopify replatform sits at the higher end of migration timelines, typically 8 to 12 weeks, and occasionally more when an ERP is involved. The split is fairly predictable: two weeks of audit and data modelling, most of the middle in build and integrations, one to two weeks on SEO mapping and QA, and a short switchover window.
What stretches it is almost never the product count. It’s the number of supplier flows to rebuild and the depth of the category tree.
What was preserved
In the end, the collection hierarchy and metafields were fully preserved for a particularly rich furniture catalogue, with ERP sync running in real time rather than in batches.
The takeaway
A PrestaShop to Shopify replatform is never a simple export/import. The real complexity lies in modelling the catalogue hierarchy and rebuilding supplier flows that, on PrestaShop, were often handled manually or through specific modules with no Shopify equivalent. That modelling work is what determines whether SEO survives the migration or not.
If your catalogue is in this situation, the CMS to Shopify migration path details how the structure audit and hierarchy rebuild are handled before any switchover. And if the new storefront needs to go headless, the Shopify to Hydrogen migration path covers that side of the project.