Migrating away from PrestaShop to a custom Solidus store

What PrestaShop is, and who outgrows it

PrestaShop is an open source shop platform written in PHP. You download it, install it on your own server, and it runs on a MySQL or MariaDB database that belongs to you.¹ The core is published under the OSL 3.0 licence, and the native modules and the Classic theme under AFL 3.0, so nobody can switch your shop off or take a share of your sales.² It has been popular across Europe for years, especially in France, Spain, Italy and here in the UK, and for a lean shop with a conventional catalogue it is a sensible, capable platform. If that describes you, this is not an article telling you to leave.

The shop that outgrows PrestaShop usually does not leave because the software cannot sell. It leaves because of the weight it has accumulated. A real PrestaShop store tends to run a tower of modules, several of them paid, each needing to stay compatible with the others and with the core. Major version changes have been hard: the jump from 1.6 to 1.7 rebuilt the theme architecture and began moving the back office onto Symfony, and a 1.6 theme was not compatible with 1.7.³ The jump from PrestaShop 8 to PrestaShop 9, released on 10 June 2025, moved the framework from Symfony 4.4 to Symfony 6.4, dropped older PHP, removed the legacy product page and changed how product URLs are built, and the project itself warns that modules and themes may need updating to work.⁴ None of that is a scandal. It is the honest cost of owning a mature PHP application that a chain of third parties also has to keep up with.

So the mover here is not unhappy with ecommerce. They are tired of the upkeep: the module licences that must all agree, the upgrade project that arrives every couple of years, the hosting and security attention, and the shrinking pool of developers who still want to work on an aging install. What they want instead is one owned, tested application they control, which is the case I make for a custom Solidus store.

This article is the honest shape of that move. I have written the deep, platform independent detail in a set of companion pieces, starting with what moves and what does not, and I link to them rather than repeat them. Here I stay specific to PrestaShop: what it hands over cleanly, what it holds back, how its export and its API actually work, and the traps that are particular to it.

What you own, and what stays behind

PrestaShop's great strength as a platform to leave is the same as WooCommerce's: because you host it, you already have the data. The database is yours, the files are yours, and nothing sits behind a vendor's export tool that can be throttled or withdrawn. That makes the raw access to your records very good. The difficulty is never getting the data out. It is that some of it is bound up in modules, overrides and formats that do not travel, and a few things cannot move at all for reasons no platform can change.

Here is the honest split for a typical PrestaShop shop.

What moves cleanly	What needs work or is locked	How I handle it
Products, combinations, categories, prices, images, stock	Theme and template logic, which is PrestaShop specific	Rebuilt as a Solidus storefront, see the products spoke
Customers, addresses, order and invoice history	Passwords, which are hashed and never reversible	Carried as data, customers set a new password once. See the customers spoke
SEO friendly URLs, for a redirect map	Payment configuration and saved tokens, held per module and per gateway	Mapped to 301 redirects. Tokens handled per gateway. See the payment tokens spoke
Everything readable in MySQL	Business logic buried in custom modules and overrides	Reimplemented as tested Rails code
Subscription records, as data	Live subscription billing tied to a payment module	Rebuilt and, where needed, migrated with the gateway's help. See the subscriptions spoke

The pattern is the one every honest migration follows. The nouns move well. The verbs, the behaviour that lived in modules and the theme, get rebuilt. I cover who legally owns each of these records, and why that matters at handover, in who actually owns your business data.

The export and the API, in detail

PrestaShop gives you three honest ways to get data out, and a real migration uses all three.

The CSV import and export tools. Under Advanced Parameters there is a built in import tool that reads CSV files for a fixed set of entities: Categories, Products, Combinations, Customers, Addresses, Brands, Suppliers, Aliases, Store contacts, and supply orders when advanced stock management is on.⁵ It is a genuinely useful tool, and it tells you a lot about the data model by the shape it expects. It also has quirks worth knowing before you lean on it. The field separator is a semicolon, so any semicolon inside your text fights the parser. Every row must have the same number of columns. Categories must exist before the products that reference them, so you import categories first by ID. Each import covers a single language, so multilingual data has to be split into one file per language. Image URLs must be absolute and reachable. And there is a "delete all before import" option that does exactly what it says.⁵ For getting data out, the product list in the catalogue exports to CSV, and for anything the screens do not cover you drop to the database.

The Webservice API. PrestaShop ships a REST style Webservice, switched off by default. You turn it on under Advanced Parameters, in the Webservice page, and create a key there, and the same key can be set to read only or given rights method by method and resource by resource, so you can expose customers and orders for reading without granting write access anywhere.⁶ Authentication is HTTP Basic with the key as the username and no password, which means the key is the whole secret and has to be looked after like one. The documentation recommends sending it in an Authorization header rather than in the URL.⁷ The endpoint lives at /api/ at the root of the install and needs URL rewriting enabled on the web server. Calling the root lists the resources your key can reach, among them customers, addresses, orders and order_histories.⁷ One detail matters for a migration script: the Webservice has historically spoken XML, and you switch the output to JSON with an output_format=JSON parameter or an Output-Format header, but as of PrestaShop 8.1 the Webservice only outputs JSON and still cannot read JSON on writes.⁷ PrestaShop 9 adds a separate, newer Admin API built on API Platform with OAuth2 tokens, which is the direction of travel but is still described by the project as a work in progress.⁸ There is no platform imposed rate limit in the way a hosted platform throttles you: the ceiling is your own server, which in practice means you pull large resources in pages and off peak.

Direct database access. Because the whole shop sits in MySQL that you own, the most complete and reliable export is simply to read the database. For a migration I treat the database as the source of truth and the Webservice as a convenience, because the database holds everything, including the module tables the API never exposes. This is the quiet advantage of a self hosted platform, and it is why PrestaShop hands over better than any hosted rival.

Passwords, and why they reset

This is one place where owning the database does not save you. PrestaShop hashes customer and employee passwords. It does not store them. Current versions hash with bcrypt, through PHP's password_hash and PASSWORD_BCRYPT, and still accept an older md5 scheme when verifying a legacy hash so old accounts keep working.⁹ Since PrestaShop 8.0 there is also a password strength policy based on the zxcvbn library.¹⁰ A bcrypt hash cannot be reversed into the original password, by design, so there is nothing to carry into a new shop that would let a customer log in with their existing password unchanged.

The honest consequence: on a custom Solidus store, customers set a new password once, through a one time secure link, on their first visit after cutover. Done as a prepared service message rather than a surprise on launch day, this is a non event. I set out exactly how in the customers spoke, including keeping the consent records and addresses intact so that only the password is new.

The traps that are specific to PrestaShop

Every platform has its own places where a migration loses time or money if you do not see them coming. These are PrestaShop's.

The module tower. The thing that makes a PrestaShop shop go is rarely the core alone. It is thirty or forty modules, several of them commercial, bought through the official PrestaShop Addons marketplace.¹¹ Each carries its own configuration, and some store real business logic: a pricing rule, a shipping calculation, a loyalty scheme. When you move, that logic does not export as data. It has to be read out of the modules, understood, and rebuilt. The good news is that rebuilding it as tested Rails code ends the dependency for good. The honest news is that finding all of it is the real discovery work, and a module nobody remembers buying is where surprises hide.

Overrides. PrestaShop lets developers change core behaviour by placing files in an override folder. It is a reasonable mechanism, and it is also where years of undocumented decisions accumulate. Before a move I search the overrides and the custom modules for logic that the business depends on and that exists nowhere else, because an override is invisible until it breaks.

Payment configuration and tokens. Payments in PrestaShop are modules, and each payment module stores its configuration and its saved card references in its own way. There is no single, portable "saved cards" export, because the card data never belonged to PrestaShop in the first place. It lives with the payment provider. The cleanest outcome is to keep the same gateway and reconnect the new shop to the same account, so stored tokens stay valid. Where the gateway changes, saved cards generally do not travel, and I flag that at the very start, not the end. The deep version of this is in the payment tokens spoke, and the risks of changing gateway at all are in the hidden dangers of switching payment gateways.

Subscriptions. PrestaShop has no native recurring billing. Subscriptions come from a module, and that module is usually bound to one payment gateway that holds the mandate and runs the charges. Subscription records export as data easily enough, but the live billing relationship, the thing that actually takes money next month, is the hardest part of any migration and often needs the losing gateway's cooperation to move without interrupting customers. It is the first question I ask, not the last. The subscriptions spoke covers the options honestly.

URLs and SEO. PrestaShop builds SEO friendly URLs, and your rankings and backlinks are attached to them. PrestaShop 9 changed the default so product URLs no longer include the category,⁴ which is a reminder that URL structure is a platform decision you have been living inside. On a custom store you decide the structure, and every old URL that earned a visit or a link gets a permanent 301 redirect to its new home. That redirect map is tedious, owned work, and skipping it is the most common way a migration quietly loses traffic. The mechanics sit in the products spoke.

The honest move onto a custom Solidus store

A move off PrestaShop is not one project, it is five streams, and each maps to one of the companion pieces.

The catalogue is the easy stream: products, combinations, categories, prices and images read out of MySQL, mapped to Solidus products and variants, and checked. Customers and their addresses and order history come across as records, with passwords reset on first login. The redirect map turns every meaningful old URL into a 301. Payments are reconnected to the same gateway wherever possible so tokens survive. Subscriptions are planned first, because they are the one stream that can hold up a launch.

What gets rebuilt, rather than migrated, is the storefront and the business logic the modules carried. That is the part that costs money in year one, and it is also the part that stops costing you afterwards, because it becomes your own tested code with no licence and no vendor between you and it. I describe how every feature ends up with an executable test, so you can read what your own shop promises, and I put the full five year arithmetic of owning against renting in the total cost of ownership article and the platform by platform comparison in Solidus vs Shopify vs Shopware vs Magento vs WooCommerce. Because WooCommerce is the other common self hosted open source platform people weigh up at the same time, its honest exit is in migrating away from WooCommerce.

A worked example

Let me make it concrete with an invented business. Kirkstall Cycle Parts (kirkstallcycleparts.example) is a Leeds retailer selling bicycle components and consumables, with about 9,000 products and combinations, strong search rankings built over a decade, and a small but loyal subscription side: a monthly consumables club where members pay a fixed sum and get a box of chain lube, brake pads and tubes, charged through a subscription module tied to their saved card. The shop runs PrestaShop 1.7, carries forty two modules, eleven of them paid, and the owner has twice deferred the upgrade to PrestaShop 8 because the quote frightened her and two of the paid modules have no compatible version. Her developer has moved on, and the new agency wants a retainer just to keep the thing patched. She is not unhappy with selling online. She is unhappy with the upkeep.

On a first look I separate the streams by difficulty, hardest first. The subscription club is the hard one: I need to know which gateway holds the mandates and whether it will let the stored tokens move, because if it will not, members would have to enter their cards again, and that is a conversation to have before anything is built, not after. The saved cards for ordinary customers are the same question in a gentler form. Those two I flag on day one.

Everything else is reassuringly ordinary. The 9,000 products and their combinations come straight out of MySQL, far more reliably than through the Webservice, and map onto Solidus products and variants. Customers, addresses and a few years of order history come across as records. Passwords reset on first login with a prepared message. The decade of rankings is protected by a redirect map, every old PrestaShop URL pointed at its new equivalent, which at this size is a couple of thousand rows and two careful days. The eleven paid modules get read for the logic that matters, the club pricing and a wheel builder among them, and that logic is rebuilt as tested code she will own outright.

The result is a Solidus shop that looks like her brand, carries no module licences, has the consumables club as a real feature rather than a bought bolt on, and can be handed to any Rails developer tomorrow. The build costs more in her first year than another year of PrestaShop upkeep would. From the second year on it costs far less, and the upgrade dread is gone, because a tested Rails application is maintained, not periodically rebuilt.

When you should stay on PrestaShop

I would tell several shops to stay. If your PrestaShop is lean, if it runs a handful of modules you understand and keep patched, if a developer you trust keeps it current, and if the catalogue and checkout are conventional, then PrestaShop is doing its job and a custom build is money spent to solve a problem you do not have. The platform is genuinely good at being a self hosted, owned shop for a business that is comfortable maintaining one. The honest trigger for moving is not dislike of PrestaShop. It is the weight of modules and upgrades outgrowing the value they return, plus a real need for behaviour that a tower of modules only approximates.

If you are the shop that has outgrown it, the thing to hold on to is that your data access is already good. You are not trapped. You are weighed down, which is a far better position to move from.

How I would run your move

I build the custom Solidus store and run the migration, and you own the result, code and data alike, once it is paid for. I start with the two questions that can sink a timeline, the saved cards and the live subscriptions, and I get written answers from the gateways before a line of migration code is written. Then the ordinary streams: catalogue out of the database, customers and orders across, the redirect map built and tested, the module logic rebuilt with tests, and a rehearsed cutover with the old shop kept untouched for a month as the fallback.

If you are weighed down by a PrestaShop that has stopped being worth the upkeep, bring it to a free workshop and the first two weeks of work are on me. I will tell you honestly which streams are easy and which are hard for your specific shop, and if the honest answer is that a lean PrestaShop still serves you, I will tell you that too.

PrestaShop Developer Documentation, System requirements (MySQL 5.7 minimum or MariaDB 10.2 minimum), accessed 14 November 2026, https://devdocs.prestashop-project.org/9/basics/installation/system-requirements/ ↩
PrestaShop Project, Licence and licence compatibility (Core under OSL 3.0, native modules and the Classic theme under AFL 3.0), accessed 14 November 2026, https://www.prestashop-project.org/maintainers-guide/general-guidelines/license/ ↩
PrestaShop Project build blog, An update on the 1.7 architecture (the move to the Symfony framework and Twig, and the new theme not compatible with 1.6), accessed 14 November 2026, https://build.prestashop-project.org/news/2015/prestashop-1-7-and-symfony/ ↩
PrestaShop Project build blog, PrestaShop 9 is available (released 10 June 2025, Symfony 4.4 to 6.4, PHP 8.1 to 8.4, new Admin API, Update Assistant, legacy product page removed, product URLs no longer include the category by default), accessed 14 November 2026, https://build.prestashop-project.org/news/2025/prestashop-9-0-available/ ↩ ↩²
PrestaShop user guide, Advanced Parameters, the CSV Import tool (importable entities and format rules), accessed 14 November 2026, https://docs.prestashop-project.org/v.8-documentation/user-guide/configuring-shop/advanced-parameters/import ↩ ↩²
PrestaShop Developer Documentation, Creating access to the Webservice (enable under Advanced Parameters, create a key, set per resource and per method permissions), accessed 14 November 2026, https://devdocs.prestashop-project.org/9/webservice/tutorials/creating-access/ ↩
PrestaShop Developer Documentation, Webservice getting started (the /api/ endpoint, Basic authentication with the key as username, XML output with JSON via output_format, and JSON only output as of 8.1), accessed 14 November 2026, https://devdocs.prestashop-project.org/9/webservice/getting-started/ ↩ ↩² ↩³
PrestaShop Developer Documentation, Admin API (PrestaShop 9, OAuth2, built on API Platform), accessed 14 November 2026, https://devdocs.prestashop-project.org/9/admin-api/ ↩
PrestaShop source, src/Core/Crypto/Hashing.php (bcrypt via password_hash with PASSWORD_BCRYPT, with legacy md5 still accepted on verify), accessed 14 November 2026, https://github.com/PrestaShop/PrestaShop/blob/develop/src/Core/Crypto/Hashing.php ↩
PrestaShop Developer Documentation, New password policy introduced in 8.0.x (zxcvbn strength estimation for customer and employee passwords), accessed 14 November 2026, https://devdocs.prestashop-project.org/9/modules/core-updates/new-password-policy/ ↩
PrestaShop Addons, the official PrestaShop marketplace for commercial modules and themes, accessed 14 November 2026, https://addons.prestashop.com/en/ ↩