A PrestaShop migration may change the version, hosting, theme or catalogue structure. Each change carries different risks. The aim is to preserve the ability to sell, the data and the signals that help search engines understand the pages. No plan guarantees an absence of organic fluctuations; a documented process helps detect issues and respond with context.
This guide helps you prepare the decision and assess a proposal. Before scheduling the move, there should be concrete answers to three questions: what will change, how it will be tested and how operations will be restored if a critical test fails. Technical upgrading and SEO preservation belong to the same project.
1. Distinguish an upgrade, migration and rebuild
An upgrade updates the software; a migration may move data or infrastructure; a rebuild may replace the theme, modules and user journeys. Confirming the distinction prevents a proposal that covers installation alone when the business also needs integrations adapted. Where possible, separate independent changes so you can identify the source of an issue.
- Record the current and target versions, PHP environment, database, theme, modules and customisations.
- Identify payments, carriers, invoicing, stock synchronisation and automated tasks that cannot stop without coordination.
- Check compatibility with suppliers and the target version’s official requirements, including licences and alternatives.
- Define what is outside the project, such as a redesign, a complete content rewrite or an ERP replacement.
2. Inventory your SEO assets before changing URLs
Export categories, products, brands, information pages, languages and relevant images. Include sitemap URLs, pages receiving organic traffic, campaign destinations and known external links. The result should be a usable comparison list, rather than just a product count. Also save titles, descriptions, canonicals and indexing rules for a representative sample.
If an address must change, map the old URL to an equivalent destination. Google’s site migration documentation recommends permanent server-side redirects, relevant destinations and short chains. Do not redirect removed products indiscriminately to the homepage. A deleted page without an equivalent replacement may need a 404 or 410 response rather than simulated continuity.
3. Create a genuinely isolated test environment
Staging is a separate copy for rehearsing the change. Its configuration and test data should approximate production, with restricted access and protection of personal data. Disable or substitute email sending, real payments, shipments and integrations that could trigger external actions. Duplicating a store without isolating those connections can create unintended orders or notifications.
The copy must not become a second public, indexable store. Use authentication and control indexing; robots.txt does not protect access. Identify staging-specific restrictions so they are not carried into the public store at launch. The team should always know which environment it is working in.
4. Test the backup and rollback plan
The PrestaShop Update Assistant offers update, backup and restore functions, but does not replace project preparation. Check what the backup contains: database, files, images and relevant configuration. Store it outside the public area and rehearse restoration in a copy. The existence of a file alone does not prove that you can recover the store.
Define who decides on rollback and which signals justify it: inability to buy, payment errors, major stock discrepancies or data loss, for example. Recovery should restore a coherent set of files and database. Restoring an old database after receiving new orders can erase them; reconciling those transactions must be planned.
5. Validate SEO and purchasing with a test matrix
Compare the old store and migrated copy using the same cases. Choose simple products and products with combinations, relevant categories, pages in different languages and out-of-stock scenarios. Record expected results, observed results and evidence. A known, classified failure is more useful than a vague approval that the website appears to work.
- SEO: URLs and redirects, HTTP codes, canonicals, languages, sitemap, internal links, images and indexing rules.
- Catalogue: references, combinations, prices, taxes, discounts, availability and internal search.
- Purchasing: guests and registered customers, cart, coupons, addresses, carriers and every contracted payment method.
- After purchase: confirmation, payment status, stock, invoicing, emails and communication with external systems.
An approved redirect should end on the correct page without loops, and that page should load the intended content. An approved payment should produce a consistent order and the correct status after provider confirmation. Use test modes where available and plan any real validation with authorisation, without sharing sensitive data in screenshots or reports.
6. Plan synchronisation and the switchover
Between making the copy and launching, new customers, orders, payments, returns and catalogue changes may arise. Define how those changes reach the final store. A maintenance window reduces concurrent changes but carries a commercial cost. Incremental synchronisation can shorten that window, although it requires more complex rules and validation. Do not simply replace the current database with the test copy.
Prepare a sequence with named responsibilities: pause agreed operations, create the final backup, reconcile data, carry out the move, validate and reopen. If hosting changes, also consider DNS propagation and tasks still running on the old server. Avoid two systems independently processing the same order or publishing contradictory stock.
7. Monitor beyond the first purchase after launch
After the move, repeat critical tests and observe errors, orders and integrations. Confirm that only the intended staging restrictions have been removed from the public store. Update the sitemap, campaign links and product sources where necessary. Compare page and query trends in Search Console; an isolated fluctuation does not automatically identify a cause or justify reversing the whole migration.
Hypothetical example: a rebuild with new URL settings
Imagine a rebuild changes URL configuration and removes numeric identifiers. The design is approved, but old campaign destinations return 404. The mappings below are illustrative; they do not represent a RedeShop client or real client addresses.
Equivalent product: /12-casaco-azul.html should return 301 or 308 to /casaco-azul, which returns 200 and presents the equivalent offer. The test confirms the code, final destination and content.
Removed product with no equivalent: /44-artigo-retirado.html returns 404 or 410. Do not invent a mapping merely to remove an error from a report.
Reorganised category: /7-casacos permanently redirects to /casacos, with a 200 response and a relevant selection. Sending all these URLs to the homepage does not meet the expected result; that generic rule is rejected during validation.
What to send for a migration assessment
Share the store address, current version, reason for the move, essential integrations and any business deadline. Do not send passwords through the form. RedeShop can assess an upgrade or migration, distinguish diagnosis from implementation and prepare a scope with defined tests, responsibilities and recovery conditions.