I migrated a 4 years old PrestaShop store. Here's how it went.

While looking for new clients for Webround, I reached out to a contact referred to me by word of mouth from a client I had already built a site for.

The situation was interesting: an e-commerce store with 4 years of order history, more than 4,000 product variants, and a solid organic SEO ranking backed by active advertising.

On paper, the store wasn't in bad shape because the site was running and sales were coming in. The problem was everything it couldn't do.

Over those 4 years of selling online, the client had gone through three marketing agencies, each with their own ideas and customizations. The developer who had originally built the store had long since left the project, and nobody inside the company could touch anything. Between plugins that couldn't be updated, a site that was starting to show its age and looking a bit rough around the edges, they were essentially stuck with a 2010-era interface and very little room to extend anything easily.

And the hosting didn't help: a server costing 250 euros a year doing everything at once. Between the site, the database, email, static assets with no CDN, and 20 GB of storage, they were running into unexpected errors and running out of space every three months.

The client didn't know what to do

His request was focused on the site itself, not the system behind it. He knew PrestaShop wasn't the best solution, but a basic interface refresh would have been enough for him.

The problem is that the real issues kept surfacing as we talked. Marketplace sync had broken because of abandoned plugins, changing any business logic was always complicated, analytics were a mess with no clear or organized metrics. In short, it was obvious the problem wasn't just cosmetic.

Customization on PrestaShop is one of those things that takes three times as long as it would on a normal system. Not only were things pretty limited in version 1.7, but the newer versions haven't made great strides either. Updates are tedious, between the unusual templating languages and plugins that inject themselves directly into the platform core, introducing bugs, vulnerabilities, and enormous technical debt.

PrestaShop 1.7 had also accumulated a backlog of missing security patches over time and, with the traffic the site was handling, including solid organic rankings and active Google Ads campaigns, it was impossible to ignore that the infrastructure wasn't holding up its end.

At that point, the reasoning was straightforward: either I upgrade everything, you buy a new theme, rebuy the plugins you already had, and we make some visual adjustments, or you migrate to Webround.

Worth noting: we're now on PrestaShop 9. Version 1.7 dates back to 2021 and isn't directly compatible with a one-click upgrade path. In practice, the migration was going to happen one way or another and, at that point, it made sense to do it on something better.

The server problem

This isn't a minor detail, because the machine running the site was responsible for the database, company email, all the store's images, and every plugin installation.

It sounds extreme, but it's not unusual: most PrestaShop installations are untouchable monoliths. One thing breaks and you risk taking everything down with it. A classic Single Point of Failure.

Webround is serverless for most of its operation. Its infrastructure is built so that no merchant ever has to manage a single machine to operate the core of the platform. On top of having a native CDN, the site itself runs on Cloudflare's edge network, so there's no loading latency for anyone visiting the site from anywhere.

With the current subscription, the client pays 32.50 € per month, but can you put a price on never having to update your e-commerce engine version again with the risk of losing data, losing access to company email, and losing all your site data? With full freedom to manage the site's appearance and functionality through React code and fully-documented APIs?

When the client found out that a complex feature was just an NPM package and a few hundred lines of code away, his eyes went wide.

That's when we decided to migrate to Webround.

The export problem

The first technical obstacle came before I even understood the full picture: I had no SSH access, and no way to enable it from the cPanel I had been given. For a bulk export, direct database access is a huge advantage but it wasn't an option here. So I had to improvise.

The solution was a PHP script uploaded via File Manager, executed once from the browser, and deleted immediately after. The script queries the PrestaShop database directly, collects all relevant tables into a single JSON file, and writes it outside public_html,so it's never publicly accessible. The file is then downloaded via FTP or the file manager interface and converted to a local SQLite database with a Node script.

The actual migration

I had already migrated some WooCommerce and PrestaShop sites before, so the pattern wasn't new to me. Classic ETL flow. But I used this as an opportunity to build something reliable and repeatable for all future PrestaShop migrations. Unfortunately, every PrestaShop installation is unique: different database names, custom table prefixes, and countless small differences that make a one-size-fits-all tool impractical to use directly. For the core data, though, there's always a standard way to extract what you need.

I built a series of scripts whose order is not arbitrary, designed to extract data from PrestaShop and import it into Webround via the APIs, in exactly the order and format that Webround requires.

The full sequence:

Tags and options: PrestaShop attribute groups become tags and options on Webround. Options reuse tags to define how products branch into variants, which PrestaShop calls combinations.
Collections: Categories are migrated level by level in a hierarchical fashion, preserving the structure and the filters that identify which products belong to each collection.
Products: Created in batch with specs, SEO details, shipping dimensions, and category and brand tag assignments.
Variants: Each Webround variant maps to a PrestaShop combination, with a unique slug and SKU, price, and stock level. Worth noting: in PrestaShop, combinations carry a price expressed as a delta from the base product price. In Webround, products don't have a price, only variants do.
Download images: Downloaded from the original server and saved in the environment running the scripts.
Upload images: Images shared across all variants of a product go on the product, while images specific to a single combination go on the variant.
PDFs: Attachments follow the same pattern as variants.
Upload PDFs: Exactly like images.
Tax zones: Each product is linked to the correct Webround tax zone based on its PrestaShop tax rules group.
Shipping: Shipping zones and methods applied to all products.
Customers: Deduplicated by email and imported as standard Webround customers. Login credentials are not transferred.
Promotions: PrestaShop cart rules become Webround promotions with discount type, usage limits, and expiry dates.
Orders: Full order history with line items, status mapping, and promotion usage tracking to prevent customers who have already used single-use promotions from reusing them after the migration.

Every script is idempotent: if a run is interrupted, the next one picks up from the saved state without duplicating anything. The one rule: don't delete the state files.

The 301 redirects

The site still ranks first on several relevant Google search queries today, thanks to a well-maintained, extensive catalog fully synced with Google Merchant Center, which also feeds the Google Shopping campaigns.

The migration scripts automatically generate a redirects.json file mapping every legacy PrestaShop URL to its Webround equivalent: this lets Webround serve the correct response on all previously indexed URLs without losing search ranking.

Important: this is not an optional step when the site has a meaningful Google history, otherwise rankings drop and Google is forced to re-crawl and re-index the entire site from scratch. To protect the SEO of your PrestaShop store after a migration, make sure all products remain reachable at their previous URLs. Returning a permanent 301 redirect to Google ensures a clean migration with no ranking loss.

Customers and passwords

Password migration is always tricky: every system has its own hashing mechanism and authentication strategy. With Webround, authentication is clearly possible, but the process is designed for customers, with an email verification and JWT authentication flow that isn't practical to replicate inside a migration script. The client and I agreed that the cleanest approach was to reset all credentials and add a notice on the login page. It's also a good opportunity to re-engage customers who haven't logged in for a while with the news of the new site, driving reliable traffic from day one.

Orders

Order history and line items are handled directly by the orders migration script. Thanks to Webround's authentication model, if a customer registers after having placed orders as a guest using the same email address, all previously associated orders are linked to the newly authenticated account. This guarantees that a returning customer, after registering, finds their full order history already there when they access their personal area.

The result

The client is entirely satisfied. His words show that the effort put into building a headless, React-based, API-first system pays off: "You're much faster than anyone who has ever touched this site." That might sound like a small thing, but it isn't.

At the same skill level, on PrestaShop, the same work would have taken three times as long, if not more. The project went on to require several additional integrations and business logic customizations, but the speed and freedom of working with Webround quickly turned into new requests for integrations and business flows, adding customer retention mechanisms, promotional advantages, and front-end personalizations that would have taken far longer to build on a legacy on-premise system that would have carried all the usual fragility that comes with it.