Migrate to PrestaShop or move an existing shop to a new server

What we would do

We would choose the route around the shop you already run: its setup, data quality, modules or source apps, theme, integrations, markets and the team responsible for daily operations. A platform change replaces business workflows; an unchanged-version server move should preserve them. Agree which job you are buying before choosing a tool or accepting a quote.

For a platform migration, we would build a clean, protected PrestaShop staging shop and prove the mappings with representative data before the full import. For a server move, we would rehearse a consistent copy of the existing installation on the target host, keeping the application version unchanged where practical. In either case, plan the final switch, identify the system allowed to accept writes and agree a recovery route that preserves orders taken after launch.

If the hosting decision needs specialist review, the PrestaShop Hosting & Infrastructure Audit assesses whether to move or improve the current host; migration execution and configuration changes are outside its scope.

Decide what moving should achieve

List the actual constraint you want to solve: catalogue structure, checkout customisation, multilingual content, ownership of hosting or integrations. Compare the total operating cost of staying with the cost of moving over two to three years, using your actual contracts and workload. Include hosting, maintenance, backups, security, developer support, extensions, subscriptions, payment fees, migration work and staff training.

Self-hosted PrestaShop gives you control over its code and infrastructure, and responsibility for operating them. It does not guarantee a lower bill or flat costs as usage grows. Module licences can include recurring support or update charges. Check each contract.

Shopify standard plans already provide branding and some checkout/account customisation. Its checkout feature table distinguishes those capabilities from Plus-only app extensions on the information, shipping and payment pages. Define the missing capability precisely before treating migration as the answer.

Staying can be sensible when your current catalogue, POS, checkout and support arrangements meet your needs and you have no resource to operate another platform. Avoid replacing every old app with a new module by habit. Map the business requirement first.

Inventory data, features and acceptance checks

• Catalogue: categories/collections, parent products, variants, SKUs, supplier references, GTINs, features, descriptions, images, prices, tax rules, stock, weight and dimensions.
• People: customers, guests, addresses, groups, business fields, consent records and account-activation requirements.
• Transactions: order lines, historical addresses, tax and discount totals, currencies, payment references, invoices, credit slips, shipments and refunds.
• Content: CMS and blog pages, menus, translations, metadata, canonicals, language links and old URLs.
• Behaviour: payment methods, carriers, tax display, discounts, subscriptions, bundles, loyalty, B2B, marketplace, ERP and accounting integrations.

Decide what migrates, what is rebuilt and what remains available in a protected legacy archive. Keep source IDs and a target ID map for every related entity, even if you deliberately preserve some IDs. Document exclusions so the support team knows where to find old information.

Set measurable acceptance checks: entity counts, representative combinations, totals by currency, stock by location/scope and working customer-service operations. Check relationships and operational workflows as well as product counts.

Choose the target version and rehearse safely

Build a protected staging installation. Choose a maintained PrestaShop 9 release supported by your theme, modules and integrations. Use the PHP and database versions required by that exact release. The current official compatibility chart distinguishes 9.0, which recommends PHP 8.4, from 9.1, which recommends PHP 8.5. Do not carry a generic PHP 8.1 package-install recipe into a new deployment.

Match required extensions and inspect PHP settings, storage, permissions and server limits. Do not choose arbitrary universal memory or timeout values. Verify the actual web and CLI runtimes.

Block staging indexing and restrict access. Isolate outbound mail, payments, cron jobs, marketplace exports and ERP writes so a rehearsal does not notify customers or change live systems. Keep backups and test restoration before the final run.

Estimate time from a representative trial and a list of rebuilds. Include data cleanup, integration rebuilds and acceptance testing in the estimate. Record export, transformation, import and validation time separately: the full project and the final write-freeze window are different estimates. Choose a launch window when your support, payment and integration contacts can respond.

Export and map Shopify data

Export products, customer profiles and available order data using the appropriate Shopify tools or APIs. Inventory metafields, app-owned records, media, collections and content separately. A product CSV is not a complete shop export. Plan Shopify blog articles and their blog features separately: PrestaShop's core CMS pages do not reproduce a full blog.

Map Shopify variants to PrestaShop combinations and decide how collections become your category hierarchy. Preserve product references and record source-to-target IDs. Rebuild app behaviour explicitly. A product can belong to several collections, so decide its category memberships and default category separately. Document any automated collection rule that must continue to maintain those memberships after launch.

Normal customer exports do not provide transferable working login credentials. Import profiles and addresses, then provide a tested activation or password-reset flow. Do not explain this as though you have exported Shopify hashes and merely need to convert their format.

PrestaShop supports multilingual core entities, but a module’s fields are only multilingual when that implementation supports them. Test translations, currency selection, taxes and each storefront rather than assuming native language support covers every app replacement.

Historical orders require a chosen importer or archive workflow. The native PrestaShop CSV importer has no Orders entity. Confirm whether the migration solution creates editable operational orders, reference records or both.

Export WooCommerce products, customers and HPOS orders

For products, use Products > All Products > Export. Enable custom-meta export where needed and inspect the resulting meta: columns. This capability is documented in the WooCommerce product CSV guide.

Inventory plugin-specific behaviour such as subscriptions, bundles, product add-ons and pricing rules. Exported metadata does not itself rebuild the behaviour. Preserve SEO metadata from the installed SEO plugin, including fields such as _yoast_wpseo_title and _yoast_wpseo_metadesc when present.

The product exporter is not a general customer/order exporter. Use an explicitly chosen exporter or the WooCommerce APIs for those entities. With HPOS, order data can reside in dedicated tables; do not rely on a posts-only database query.

Convert variations to combinations. Strip or replace WordPress shortcodes and builder markup in descriptions. Rebuild menus, blog functionality and theme layouts. A WordPress theme is not a PrestaShop theme.

Image columns in a WooCommerce product export contain URLs rather than the image files. Either keep the source images reachable during import or download the originals and provide a controlled transfer route. Confirm that the target has its own usable copies, including combination associations, before retiring the source media hosting.

Work through a variable product before the full import

Take a shirt sold in several sizes and colours. The source variation for Size M and Colour Blue has its own reference, stock and image. Import the parent shirt first, then attach that variation as a combination to the mapped parent. For the native combinations import, calculate the tax-exclusive price impact as the variation's regular net price minus the parent product's net base price; do not import the full variation price as the impact. Check that selecting M and Blue shows the correct reference, image, availability and final price, and that the intended combination is selected by default.

A product count can pass while this test fails: importing each variation as a standalone product loses the selector, while attaching it to the wrong parent produces a plausible but incorrect catalogue. Keep the source parent and variation identifiers in your mapping so you can trace either failure to the affected row.

Keep regular, sale and tax values distinct

Check whether source prices include tax. Map net and gross fields deliberately. For example, EUR 120 inclusive of a single 20% tax corresponds to EUR 100 before tax; importing EUR 120 as net makes the resulting gross EUR 144 at that rate. Real tax rules can be more complex, so test destination carts. Record Prices entered with tax under WooCommerce > Settings > Tax before transforming the export. Map a sale price to the intended specific-price discount, with its dates and applicable customer or currency conditions, rather than accidentally replacing the regular price. Check both the displayed offer and the cart total.

Map Magento or Adobe Commerce concepts explicitly

Identify the source edition and extensions. Adobe Commerce B2B company accounts, quotes and requisition-list features must not be attributed wholesale to Magento Open Source core. Inventory customer-specific pricing, search and content staging and decide how each is implemented in the target.

PrestaShop’s B2B mode exposes business-account fields. Group pricing, customer-specific pricing and tax-exclusive display need their own configuration. Enabling the mode does not set all of them.

Rebuild integrations against the resources and operations actually available. The legacy Webservice, PrestaShop 9 Admin API and module endpoints have different coverage and authentication. Do not assume a source REST or GraphQL integration transfers unchanged.

Routine Magento product-price edits are admin operations. Code-deployment complexity is not a factual reason to claim that every price change requires Composer or a deployment pipeline.

For example, an apparel product's selectable Size belongs in the combination model, while a fixed Fabric description can become a feature. Compare a mapped configurable product with its source child SKUs, then place a test order as a business customer. Correct variant stock does not prove that the customer's negotiated price or business-account permissions survived.

Choose how the data will move

Select a method from a written mapping and a sample export. A connector demonstration with simple products does not establish support for your subscriptions, custom business fields or order history. Require evidence from your own representative records.

If you need help with a missing feature, the PrestaShop Module Selection & Fit Assessment evaluates routes to that requirement, while the PrestaShop Custom Module Development Service scopes and quotes bespoke module or integration work separately.

Import in dependency order and verify relationships

1. Create shop structure, languages, currencies, tax rules, customer groups and category hierarchy.
2. Import parent products with stable keys and mapped categories. Validate prices before adding images.
3. Import combinations using the parent Product ID, or Product Reference with reference matching enabled. Set the intended default combination in this pass.
4. Transfer images and verify their associations and generated sizes.
5. Import customers and addresses, preserving relationships and consent information.
6. Import historical orders only through the selected supported mechanism. Disable unintended email, stock or integration side effects.
7. Rebuild applicable indexes, compare counts and totals, and inspect records in both front and back offices.

Native import identifiers vary by entity. Do not assume you can choose any column as a universal matching key. See the product import guide for CSV and partial-failure handling.

Test currencies, historical tax values and refunds explicitly. Recomputing old orders using today’s catalogue or tax configuration can change the record you meant to preserve.

Keep an import log linking failed rows to source IDs and the reason for failure. Rehearse a corrected retry rather than assuming that a timed-out batch imported nothing. For images, distinguish an unreachable source URL or failed resize from a failed product row before changing max_execution_time or restarting the whole job.

Preserve account access and usable order history

For Shopify, WooCommerce and Magento migrations, plan a reset or activation flow unless you have tested a compatible login bridge. In PrestaShop 1.7.8 and 9.1, the native customer CSV format requires a Password field and hashes its value. Supplying an existing source hash as that value does not preserve the original login password. Use a migration tool with an explicit credential policy; for new password-based accounts, use an unguessable initial secret and a tested reset or activation flow without emailing that secret.

A separately engineered bridge can verify a supported old hash and rehash the password on a successful login. It requires access to the source credentials, a defined security model and testing. Do not promise it for a platform whose exports do not supply that material.

Test the reset link, language, delivery and account matching before inviting customers. Avoid emailing temporary passwords. Explain the change clearly and keep an account-recovery route available.

For historical orders, check the chosen importer’s actual capabilities: can staff view lines, issue documents, update shipment information or process returns? A processor refund requires suitable original transaction references, account access and integration support. Keep the old provider workflow or protected legacy back office where necessary.

Preserve URLs, metadata and discoverability

1. Combine a source-site crawl, sitemaps, platform URL exports, analytics, backlinks and available server logs. Search Console performance exports are useful but are not a complete URL inventory.
2. Map old product, category, CMS, blog, language and image URLs to relevant destinations. Keep redirects direct and permanent, normally HTTP 301 for a permanent move.
3. Preserve useful titles, descriptions and content initially. Remove obsolete content deliberately and avoid sending every removed page to the homepage.
4. Check canonical URLs, language links, internal links, robots directives and staging access controls.
5. Generate the new sitemap and submit it after launch. Use Search Console’s Page indexing report and URL Inspection; use Settings > Crawl stats for crawl/server diagnostics.

Typical source paths such as /products/blue-widget or /product/blue-widget/ can become a configured PrestaShop product URL. Generate the actual destination first; do not assume every shop uses the same IDs, language prefixes or .html suffix.

Implement bulk mappings in tested server rules, a suitable redirect manager or a migration script. PrestaShop’s individual product redirects are not a complete bulk migration tool. For ongoing address and redirect control, Smart SEO Friendly URL Manager manages page patterns and old addresses; validate the required migration mappings on staging before relying on the module for them. Rankings can also change because of content, availability, speed, canonicals and reindexing; a redirect map cannot guarantee unchanged traffic.

For a mapped product, test an old link from a campaign or search result using the intended hostname and language. Record the redirect response and follow it to the final page: a redirect to a missing product, another redirect or the wrong language is still a failure. Check the final canonical and that the product can be bought, then repeat the check after the public switch. The URLs and redirects guide covers the surrounding URL controls.

Move an existing PrestaShop installation to another server

A server move of the same shop normally transfers files and a consistent database rather than rebuilding customers and products through CSV. Separate a major version upgrade from the host move where practical so each can be tested.

1. Inventory domains, multistore URLs, CDN origins, cron jobs, workers, mail settings, custom files, web-server rules and external callbacks.
2. Prepare the target runtime and database. Preserve the database charset/collation and required schema behaviour. Give the application appropriate database credentials.
3. Copy the installation, including images, uploads, themes, modules and necessary hidden/configuration files. Keep archives outside the public document root.
4. Export and restore a consistent database. For transactional InnoDB tables, a single-transaction dump can help; account for nontransactional tables and avoid schema changes during the dump.
5. Update the target’s connection credentials in app/config/parameters.php for modern PrestaShop. Preserve application cryptographic secrets. Legacy 1.6 uses different configuration files.
6. Apply ownership and permissions appropriate to the host. Do not blindly make every file writable by the web process or copy universal permission commands.

# Illustrative file transfer; replace paths and remote account.
rsync -avz --progress -e ssh /srv/shop/ deploy@new-host:/srv/shop/

# Example database export for an appropriate InnoDB installation.
mysqldump -u ps_backup -p --single-transaction --routines --triggers shop > shop.sql

# Restore into the prepared target database.
mysql -u ps_restore -p shop < shop.sql

These examples require account permissions and an installation-specific backup plan. Protect the dump and remove temporary copies after a successful restoration test. Do not restore a dump over the wrong live database.

If the public domain and path stay the same, keep those shop URLs. If they change, update the actual shop URL records, including domain, SSL domain and physical/virtual URI, in the correct shop context. Modern multistore URLs are represented by shop_url; changing two generic configuration names is not a complete multistore move.

Work through an unchanged-domain server move

Suppose the shop keeps its public domain and PrestaShop version but moves to another host. A successful homepage on the new server is only an initial check. Place a provider-supported test order through the controlled target route and verify the order, uploaded files, generated images, outgoing mail and background processing. Check file paths and host-specific configuration as well as the copied database.

A payment provider can still be calling the old host while your browser uses the new one. Match a notification reference to the target logs and order record. If the callback reaches the old installation, correct the routing and write controls before enabling sales on the target.

Prepare certificates and control the final cutover

Install certificates for the actual production hostnames before launch. A certificate issued for a temporary hostname does not cover the production domain. DNS-based validation can be useful before that domain points to the new host.

Test the target under its real hostname using a local hosts-file override or an equivalent controlled route. This tests your browser, not the route used by payment providers or other remote callers. Keep callback testing and provider access in the cutover plan.

# Example entry on your test workstation only.
203.0.113.50 example.com www.example.com

1. Lower relevant DNS TTLs early enough for the previous TTL to expire. Review A, AAAA, www, CDN and proxy/origin records.
2. At cutover, stop new orders and other writes on the old system. Maintenance mode alone may not stop callbacks, API clients, cron jobs or admin writes.
3. Complete the final database/file transfer, or a tested final delta for a platform migration. Reconcile customers, orders, stock, prices and uploads created since rehearsal.
4. Route traffic to the new system and confirm remote callbacks reach the correct installation. Avoid two independent writable databases.
5. Enable the new store after acceptance checks. Keep stale traffic on a controlled route or read-only old system until the transition is complete.

Keep a cutover worksheet with the last accepted source order, the final export boundary, reconciliation results and the person who authorises reopening. A platform delta must account for changed stock, amended orders, cancellations and refunds as well as newly created records. Record payments still pending at the final export and define how later notifications update the authoritative order without duplicating payment or fulfilment actions. Re-running a full export without tested matching can overwrite a corrected mapping or duplicate an earlier import.

A maintenance cutover has a maintenance interval. DNS caching prevents a fixed “five-minute” or “zero-downtime” guarantee. Continuous availability requires a designed routing, replication and write-coordination approach.

Use the back-office maintenance controls in the correct shop scope. In core configuration, PS_SHOP_ENABLE = 1 enables the store; it does not put the store into maintenance.

Spot a cutover that has not finished safely

Run the launch and recovery checks

• Test registration, login, password reset, browsing, search, filters, combinations and stock.
• Check cart additions, quantity changes, discounts, delivery, tax and currency totals as guest and registered users.
• Test every payment method with provider-supported sandbox credentials and test values, including authentication, callbacks, cancellations and refunds. Follow provider rules for any separate production validation.
• Confirm order and status emails, contact messages, invoices and support workflows. After any sending-host change, check the target mail transport, SPF and DKIM on a delivered message.
• Check important redirects, images, language links, canonicals, mobile layouts and analytics.
• Clear the appropriate target caches and rebuild required indexes. Regenerate Apache rewrite rules where relevant; Nginx configuration needs its own review.
• Recreate cron/worker schedules with the right timezone, paths and credentials. Enable integrations once and monitor errors and reconciliation.

Keep the old installation and backups available for a retention period based on your recovery needs. A rollback after the new shop accepts orders must preserve those new writes. Simply pointing DNS back to a stale database can lose orders or cause duplicate fulfilment.

Record who can stop writes, where new orders are reconciled and which backup or delta restores the chosen system. Monitor payment references, application/server errors, email events and indexing after launch.

What to ask your developer or agency

• Which source entities and custom fields are included, rebuilt or excluded, and where is the source-to-target mapping?
• Which representative records and customer journeys passed on the agreed theme, modules, markets and runtime, and where can we inspect the evidence?
• What exactly does the final delta detect, how are failed rows retried and what stops every source of writes during the switch?
• Who owns the launch decision and the response to a failed payment, missing order, broken redirect or integration error?
• When does rollback require reconciling new target orders, and who has rehearsed that recovery procedure?
• Which recurring licences, archive access, provider accounts and support responsibilities remain after handover?

Questions owners ask

Do we have to redesign the shop at the same time?

You need a compatible target theme when changing platforms, but you can keep familiar navigation, wording and branding. Defer unrelated design experiments so the migration tests have a stable target and customers can recognise the store.

Can we keep the same payment provider?

Possibly, but keeping the merchant account does not transfer the integration. Confirm the target module's account, country and currency support with the provider, then test its credentials, notification route and refund workflow before switching.

Will subscriptions and saved payment methods keep working?

Treat them as a separate workstream. A customer or order export does not establish that a saved token, mandate or renewal schedule is transferable. Obtain the provider's supported procedure and decide which system owns future renewals before disabling the old subscription jobs.

What happens to gift cards and loyalty balances?

Inventory outstanding balances and redemption rules separately from discount codes. Agree how the target records and honours them, test a redemption and reconcile the balances at cutover so customers cannot spend the same entitlement on both systems.