PrestaShop runs on your own server, so you have access that rented platforms never give you: direct access to the database. For a migration that is an advantage – it just has to be used properly. And a few things here work unlike anywhere else.
A written answer within 24 hours · no commitment
A self-hosted platform migrates differently from a hosted one. These are the three points that decide how – and they get settled before anyone touches the first product.
I migrate straight from the database rather than through the API – on purpose. In the database the data is complete and predictable, with no limits and no pagination. The official API would work too, except that the new API in PrestaShop 9 cannot yet export orders in bulk or give a full customer export, and on a larger catalogue it is slow. A single product in the database spans a number of linked tables, so it is not one query’s work – but it is predictable work.
PrestaShop gives products addresses ending in .html, often with a numeric ID, and combinations of variants get addresses of their own. Shopify has none of that – fixed /products/ and /collections/ prefixes and no .html. So one hundred percent of the addresses change, and on a store that has gone through versions 1.6 to 9 the structure is rarely consistent. The redirect map is therefore the most laborious part of the migration; I build it from the complete list of addresses, not from an estimate.
PrestaShop has no limit on the number of product attributes; Shopify has a hard limit of three options. For a product with four or more attributes it is decided in advance what stays a variant and what gets handled another way – automated tools simply cut off the excess without telling you which three survived. So I go through a catalogue with rich variants during the audit, not at import.
On the data side PrestaShop is cleaner than rented platforms – one relational database with readable tables. The line runs elsewhere: between the numbers and the logic.
This is the distinction worth remembering: the numbers come out of PrestaShop cleanly, but the logic that drives them stays in the modules’ code. Pricing rules, loyalty programmes and configurators get rebuilt on Shopify – it is not a one-button job, and it is a separate line in the quote.
The table shows the usual English setup. On your store it may differ depending on the version and URL settings – which is exactly why I build it only after the audit.
| PrestaShop | Shopify |
|---|---|
| /12-product-name.html | /products/product-name |
| /34-category-name | /collections/category-name |
| /12-2-product-name.html | /products/product-name?variant=… |
| /brand/5-brand-name | /collections/brand-name |
| /content/3-about-us | /pages/about-us |
| /de/12-produktname.html | /de/products/produktname |
Scroll for the full table
The catch is in the numeric IDs and the .html endings: from the address alone you cannot tell whether 12 is a product or a category. And on a multilingual store every language has its own address and its own slug, so redirects are created separately for each language – Shopify has no single rule covering several addresses. That is why I build the map from the database, where type and language are unambiguous, not by guessing from the URL.
Decision made? Get a migration estimate →
Still weighing up whether to move? See the comparison →
With a rented platform, the old store closes by itself once the domain moves. Self-hosted PrestaShop keeps running until you switch it off – and that has a catch.
PrestaShop 1.7 has not received security patches since June 2025, and 1.6 not since 2019. Real attacks go after unpatched installations – through vulnerable modules or a spoofed payment form. This year Sansec counted more than two hundred live PrestaShop stores with a publicly reachable installer. An old store left running "just in case" is an open risk, not insurance.
For the first few weeks it makes sense to keep the old installation within reach, to look up orders and returns – but behind a login, not publicly. You do not need it to verify the redirects: I take the list of old addresses from the database before the migration. Blocking it through robots.txt alone is not enough; that does not remove pages from Google.
Tax documents have to be kept, readable and unaltered, for years – typically somewhere between five and ten depending on the country, so check the period that applies to you with your accountant. Simply switching the store off without a copy of those documents can put you in breach. Before the hosting is cancelled, I export the documents into a permanently readable format and hand them over – an offline copy with you or your accountant is enough, it does not have to stay online.
PrestaShop gives you what a rented platform by definition cannot – your own code, your own server, a free structure. These are the situations where I will talk you out of migrating myself.
And plainly: PrestaShop is a mature platform, but its ecosystem is shrinking globally – it remains strong in France, Spain, Italy and Poland – and on a heavily customised installation a great deal depends on how cleanly someone built it years ago. If staying still works out better for you, I will say so in my reply to your enquiry – pushing you into a move that does not pay for itself does me no good.
No URL disappears into nothing. Every old address gets a permanent (301) redirect to the matching new one, so external links and the SEO signals you have collected point at Shopify rather than at a 404.
Old address
/old-url
301 (permanent)
redirect
New on Shopify
/products/…
Both the visitor and Googlebot land on the right new page – not on a 404.
Real stores from my desk – some built from zero, some heavily rebuilt. Proof that Shopify holds up under demanding traffic.
Continental Lab
Minimalistick × Soulbabes
Because the database gives me the data complete and without the limits the API has. The official API would work too, but the new API in PrestaShop 9 cannot yet export orders in bulk or give a full customer export, and it is slow on a larger catalogue. On a self-hosted platform you do have direct database access – I need it, but you do not have to hand all of it over; we agree a safe way to do it.
Changing addresses does not by itself knock rankings down – Google states explicitly that permanent 301 redirects do not lose link equity. What causes a drop is an address somebody forgot. On PrestaShop that risk is higher because of the numeric IDs, the .html endings and, on multilingual stores, a separate address for every language. So I build the map from the database, where type and language are unambiguous, and after launch I check for error pages daily.
How I handle SEO in a migrationShopify caps a product at three options; PrestaShop has no cap at all. So in the audit I go through products with rich combinations and decide what stays a variant and what gets handled differently – split into several products, or moved into additional fields. I do not rely on an automated tool that silently trims the excess. For most stores this affects only part of the catalogue, but that is exactly the part that needs watching.
Reviews in PrestaShop are held by the rating module in its own tables – I get them out of the database and import them into the review app you choose on Shopify. The blog is another matter: PrestaShop has none in its core, so if you have one it is a third-party module. I move its posts, but categories flatten into tags on Shopify and post addresses change – they go through the same 301 map as everything else.
It can, carefully. PrestaShop keeps prices, stock and visibility per shop in separate tables, so a plain export would mix them together. On Shopify several storefronts are handled through Markets, which covers currencies, languages, domains and different catalogues from one account. Where the shops are genuinely different brands or run separate stock, a second store may be the right call – I go through it in the audit and tell you what makes sense.
On hosting, updates and security, yes – on Shopify all of that falls into the plan and the platform handles it. On self-hosted PrestaShop you pay for hosting, certificates, backups and the time of whoever watches the patches for the core and the modules. For most stores that upkeep is a larger item than the Shopify plan itself.
A link to the store, the PrestaShop version, the number of products and whether you run multistore or several languages is enough. Within 24 hours you get it in writing: what the migration involves, roughly what it costs and how long it takes (typically 2–8 weeks).
Would rather not fill anything in? Write straight to ahoj@hynekkraus.cz