PrestaShop migration without losing sales or search rankings

If you’re reading this, you need to migrate PrestaShop and you want to do it without your phone ringing on Monday with every ecommerce manager’s favorite sentence: "the store won’t load". I’ll walk you through a PrestaShop migration the way we do it on real projects, with the details that rarely make it into YouTube tutorials.

Whether you’re switching hosting providers, merging two stores, upgrading to PrestaShop 8 or just moving the domain, the process has several layers: files, database, configuration, payment modules, carriers and, most delicate of all, SEO. Skip just one and you get lost orders, 500 errors and, if you’re lucky, nothing worse than an earful from the marketing manager.

This guide is written for stores selling in Spain with real volumes, from the SME handling 200 orders a month to B2B projects with 30,000-SKU catalogs. You’ll see what order to follow, which tools to use and where the traps are that hardly anyone tells you about.

Before you migrate PrestaShop: what you need to decide

Before touching anything, take ten minutes to pin down the scope. Moving PrestaShop to another server while keeping the same version and domain is not the same as using the move to upgrade from 1.7.8 to PrestaShop 8.x. Each combination carries its own level of risk.

Four questions that save you headaches

• Are you changing versions? Jumping from 1.7 to 8 isn’t a migration, it’s a project. It means reviewing modules one by one and, almost certainly, reworking the theme.
• Are you changing domains? If so, set up the 301 redirects before you touch DNS.
• Does the new hosting support your stack? PHP 8.1+, MySQL 5.7 or MariaDB 10.3+, and the GD, intl, zip and soap extensions, among others.
• Do you have a real maintenance window? In B2C, the early hours of Tuesday to Thursday usually see the fewest orders. Be careful with Sundays: some niches see sales spike.

One thing you learn over the years is that deciding what gets migrated and what stays behind matters as much as the how. Use the move to clean out discontinued products, orphaned categories and the 47 modules you installed “just to try” that nobody has opened since. The less clutter you carry over, the faster the new store will run.

If your catalog is huge or you have ERP integrations, it’s worth bringing in a PrestaShop specialist agency for the cutover and rollback plan. Improvising with a 30-SKU store is one thing; doing it with 30,000 SKUs is another.

Full backup: the life insurance of the whole process

This is non-negotiable. Before you move PrestaShop anywhere, you need two full copies stored in different places: one on your computer and another in external storage (Drive, Dropbox Business, S3, whatever you use). If something goes wrong, this is what lets you roll back without tears.

What the backup must include

1. All files from the root: /admin, /modules, /themes, /img, /upload, /download and the configuration files (app/config/parameters.php or the older config/settings.inc.php, depending on your version).
2. A compressed SQL dump of the database. If it’s large, use mysqldump over SSH instead of phpMyAdmin, which hangs on big catalogs.
3. A list of active modules and their versions. A screenshot of the back office will do.
4. Server configuration: PHP version, limits (memory_limit, max_execution_time, upload_max_filesize), cron jobs and custom .htaccess rules.

A backup you haven’t tested by restoring it isn’t a backup. It’s just a big file taking up space.

I recommend restoring the copy to a staging environment before going any further. If the store starts up in staging with the backup data, you know the copy is good. If it doesn’t, better to find out now than at three in the morning on migration day.

Prepare the new server and move the files

With the backup in hand, it’s time to prepare the destination. If you’re changing PrestaShop hosting, make sure the new provider gives you SSH access and cron jobs, and that its control panel doesn’t block PHP functions PrestaShop needs (exec, and in some cases shell_exec for maintenance tasks).

Upload files efficiently

Forget uploading 12 GB over FTP file by file. Compress everything into a single .tar.gz over SSH on the source server, transfer it with rsync or scp to the new server and extract it there. It takes minutes instead of hours and spares you the usual files corrupted by timeouts.

Permissions and ownership

Once extracted, set the permissions. The usual rule: 755 for folders, 644 for files, with the web server user as owner (usually www-data or the cPanel user). Skip this step and you’ll be seeing “cannot write to /var/cache” errors for days.

Database

Create the new empty database, import the SQL and update the credentials in app/config/parameters.php (PrestaShop 1.7+) or config/settings.inc.php (1.6). If you’re changing domains, update the URLs in the ps_shop_url and ps_configuration tables (keys PS_SHOP_DOMAIN and PS_SHOP_DOMAIN_SSL). A careless UPDATE here locks you out of the store, so watch that WHERE clause.

My recommendation: work on a temporary subdomain such as new.yourstore.com until everything works, and only then point the real domain to it.

Modules, payment gateways and the problems nobody warns you about

This is where most migrations start to creak. Modules are both PrestaShop’s greatest strength and its biggest headache. An average store has 40 to 80 of them installed, and at least 20% are incompatible, abandoned or running on an expired license.

The order that works

1. Clear the entire cache from the back office of the new environment (Advanced Parameters > Performance).
2. Go through the module list and disable the ones you don’t use. Every active module is a potential point of failure.
3. Reinstall critical modules one at a time: payment gateway (Redsys, Stripe, Bizum), carriers (SEUR, MRW, GLS, Correos Express) and connectors to your ERP or e-invoicing system.
4. Check licenses. Some premium modules are tied to a domain or IP address, and they stop working after the move until you ask the developer to reactivate them.

Payment gateways: the most delicate part

If you use Redsys (the card payment gateway behind most Spanish banks), the virtual POS is usually tied to the response URL. When you change server or domain, you have to ask the bank to update the notification URL. Otherwise payment confirmations never arrive and orders sit in “awaiting payment” forever. Stripe and PayPal are more flexible, but you should still review your webhooks.

One more detail: now that Veri*Factu, Spain’s new invoicing compliance system, is fully in force, make sure your invoicing module is still compatible after the migration. Some legacy modules generate invoices that no longer meet the new requirements of the Spanish Tax Agency (AEAT), and that’s a problem for any freelancer or company selling online in Spain.

PrestaShop migration without losing SEO: redirects, sitemap and Search Console

SEO is the part that costs you the most sales if you neglect it. I’ve seen stores lose 40% of their organic traffic in two weeks because the redirects weren’t prepared. And getting it back takes months.

If you keep the domain and URL structure

Congratulations, this part is almost a formality. Check that friendly URLs are enabled (Shop Parameters > Traffic & SEO), regenerate the .htaccess and make sure a handful of random URLs from the old site return 200 on the new one.

If you change the domain or URL structure

This takes careful work. You need an old → new 301 redirect map. Export the full list of URLs from Search Console and Screaming Frog, build the mapping in a spreadsheet and generate the RewriteRule rules in .htaccess or, better still, use a dedicated module such as "301 Redirects" so you don’t have to edit the htaccess by hand.

Post-migration SEO checklist

• XML sitemap regenerated and submitted to Search Console.
• Robots.txt reviewed (make sure the staging Disallow: / hasn’t been left behind).
• Canonicals pointing to the correct domain.
• Structured data (Product, Breadcrumb) validated with the Rich Results Test.
• Page speed measured with PageSpeed Insights before and after.
• Domain verified in Search Console and Bing Webmaster Tools.

A migration without a redirect plan is like moving house without telling the post office: the mail carrier (Google) keeps knocking on the old door for months.

If the project goes beyond a hosting change and you’re thinking of rebuilding the store, read how we approach a full ecommerce migration, with a prior SEO audit and a content plan. Moving files is not the same as rebuilding the architecture.

Final checks, go-live and monitoring

At this point the store is running on the new server on a temporary subdomain or IP address. Before pointing the final domain to it, spend a couple of hours testing the whole flow as if you were a real customer.

Tests you can’t skip

1. A complete purchase with every active payment method, using small real amounts (€1, €2). Test mode doesn’t count unless it’s configured exactly like production.
2. Shipping cost calculation to several regions, including the Canary Islands, the Balearic Islands, Ceuta and Melilla, which have their own tax rules in Spain.
3. Invoice generation, checking that invoices meet current requirements (Veri*Factu where applicable).
4. Transactional emails: order confirmation, status changes, password recovery.
5. Back office: employee login, order management, report exports.

Switching DNS

Once everything works, lower the DNS TTL to 300 seconds about 24–48 hours before the switch. That way propagation is almost instant. Put the old store into maintenance mode, export one last batch of orders placed during the window, import them into the new store and point the DNS.

For the first 72 hours, monitor closely: PHP error logs, 404 errors in Search Console, conversion rate in Google Analytics 4 and, above all, orders per hour compared with the previous week. If anything drops suddenly, that’s your clue that a module or redirect isn’t working.

For stores that have outgrown PrestaShop, this is also a good moment to rethink the platform. We cover this in depth in our ecommerce section, where we compare PrestaShop with other options by business model.

Common mistakes and how to avoid them

To wrap up, here’s my mental summary of the slip-ups we see most often. Some may seem obvious, but I can assure you I’ve seen them more than once, even with solid technical teams.

• Migrating without updating the PHP version when it’s due. PrestaShop 8 doesn’t run on PHP 7.4, but some old modules crash on PHP 8.2. Check the compatibility matrix first.
• Forgetting the /img folder. It’s large and sometimes gets left out by mistake. The result: a catalog with no photos.
• Not regenerating thumbnails after the move. Images come out pixelated or don’t show up in categories.
• Leaving the staging domain in a configuration field or email template. Your customers receive links to new.yourstore.com, which doesn’t exist.
• Not telling Redsys or your payment gateway about the new notification URL.
• Forgetting the cron jobs on the new server: indexing, abandoned cart cleanup, ERP sync.
• Ignoring GDPR: if you change hosting provider, update your record of processing activities and, where relevant, your legal notice and privacy policy.

In my experience, PrestaShop migrations go wrong because of overconfidence more than lack of knowledge. It’s a long, heavy and largely boring process, and your brain tends to skip steps after six hours at the laptop. That’s why a physical checklist, printed out and ticked off with a pen, is still the most effective tool I know.

A well-executed PrestaShop migration is invisible: customers don’t notice, orders keep coming in and SEO holds steady. Done badly, it means a weekend of overtime, calls to the bank and apologies to customers who can’t pay. The difference rarely lies in technical skill. It lies in planning ahead and following the steps in order.

If your store turns over enough that a day of downtime really hurts, plan the migration calmly, with a clear maintenance window and a written plan B. And if the scope starts getting away from you (versions to skip, ERP integrations, a huge catalog), bring in people who’ve done this dozens of times. It costs less than rebuilding what breaks.