PrestaShop Migration Services — 1.6 & 1.7 to 8.x/9.x [2026]

PrestaShop migration services move a running store from an old version (1.6 or 1.7) to 8.x or 9.x — or from a legacy PHP stack to a supported one — without losing orders, customers, content or Google positions. The migration itself is not the hard part: keeping SEO, integrations and daily sales alive during the switch is. This guide shows the full process, what gets migrated, how URLs are preserved, what it costs and how the risks are handled.

Key takeaway: A PrestaShop migration covers products, customers, orders, categories, content and module configuration, preserves URLs with 301 redirects and runs on a staging copy with comparative tests before traffic is switched. Typical cost: 2,000–8,000 PLN net, timeline 2–6 weeks. The old store keeps selling until the new one is fully verified.

When a migration makes sense — and when it doesn't

A migration is the right move when at least one of these is true

• Your store runs on PrestaShop 1.6 or 1.7, which no longer receive security updates.
• Your PHP version is end-of-life and your hosting provider is pushing an upgrade.
• Modules stop working after updates because they are incompatible with newer cores.
• You need features available only in 8.x/9.x (new back office, Symfony-based architecture, better performance tooling).

A migration may not be worth it when the store is small, stable, and the only problem is a single module — a targeted fix or module replacement is cheaper. I review the store first: version, module health, custom code volume, database size and integrations. If the store can be fixed in place, I say so.

Migration paths

For every path the sequence is the same: audit, staging build, data migration, module and theme work, comparative testing, switch with 301 redirects, post-launch monitoring.

What gets migrated

A complete migration covers the full store, not just the product list

• Catalogue — products, combinations, attributes, features, categories, manufacturers, images (with regenerated thumbnails).
• Customers — accounts, addresses, groups (B2B price groups included), passwords (hashed, transferred as-is so nobody has to reset).
• Orders — order history, statuses, invoices, credit notes and carts, so customer service can see the full history after the switch.
• Content — CMS pages, blog content, SEO metadata (titles, descriptions, canonical settings).
• Configuration — taxes, currencies, shipping zones and carriers, payment modules, discount rules, warehouse settings.
• Integrations — marketplace, ERP, warehouse and payment connections are reconnected and tested against the new core.

Anything that cannot be transferred automatically is listed for you before the migration starts — no surprises on go-live day.

SEO during a PrestaShop migration

Losing positions after a migration almost always comes down to three things: changed URLs, lost metadata or redirects done wrong. The checklist I follow:

• URL preservation first — keep the same URL structure (/category/product, not /product-123-new). If a URL must change, it gets a 301 redirect to the new address.
• Redirect map built from data — I export all indexed URLs (products, categories, CMS pages) and map each one to its new address. Redirects are tested with automated crawls, not spot checks.
• Metadata audit — titles, meta descriptions, H1s, canonical tags and hreflang are compared between old and new store before the switch.
• Facet and pagination rules — filters that were blocked from indexing stay blocked; pages that ranked keep ranking.
• Sitemap and Search Console — new sitemap submitted on go-live, URL inspection requests for key pages, monitoring of coverage and position data for the first weeks.
• No parallel indexing — the staging store stays noindex until the switch, so Google never sees two copies.

The result is a migration where the organic traffic curve dips for days, not months — and recovers as Google re-crawls the redirected URLs.

The process, step by step

1. Audit and plan — version, modules, custom code, database, integrations, URL inventory. You get a scope with a fixed price per stage.
2. Staging build — a full copy of the store on a target version, behind noindex.
3. Data migration — catalogue, customers, orders, content and configuration with mapping reports.
4. Module and theme work — compatible versions, replacements where needed, theme adaptation in a child theme.
5. Comparative tests — checkout path, payments in sandbox, shipping, emails, B2B pricing, integrations, performance (Core Web Vitals), SEO metadata and redirects.
6. Go-live — DNS/traffic switch in a low-traffic window, redirects live, sitemap submitted.
7. Post-launch care — daily monitoring of orders, errors and Search Console for the first weeks; fixes included.

You see a demo at the end of every stage and approve before the next one starts. The old store keeps running until the new one passes acceptance.

Risks and how they are handled

The rollback plan is the safety net: the old store stays intact and can be re-enabled if the new one fails acceptance — which is why the switch is the last step, not the first.

Cost and timeline

A standard 1.7 → 8.x migration with a catalogue up to a few thousand products runs 2,000–5,000 PLN net in 2–4 weeks. A 1.6 → 8.x/9.x migration with custom modules and integrations: 5,000–8,000 PLN net, 4–6 weeks. Stores with heavy customisation, B2B pricing or multi-store setups are quoted individually after the audit. PHP-only upgrades start around 1,500–3,000 PLN net.

The quote is fixed per stage and includes the audit, staging work, data migration, redirect map, testing and the go-live — not just the technical import. See the full scope of my PrestaShop development services for how migrations fit into the wider offer, or check what happens after launch if you want to pair the migration with ongoing care.

Frequently asked questions

How much does a PrestaShop migration cost?

A standard 1.7 → 8.x migration: 2,000–5,000 PLN net. A 1.6 → 8.x/9.x migration with custom modules and integrations: 5,000–8,000 PLN net. Stores with extensive customisation, B2B pricing or multi-store setups are quoted individually. The price includes the audit, staging environment, data migration, 301 redirect map, tests and go-live support.

Will I lose Google positions after migrating PrestaShop?

Not if URLs are preserved and redirects are done properly. I keep the existing URL structure where possible, build a 301 redirect map for every changed address, audit metadata before the switch and monitor Search Console after go-live. Traffic typically dips only for a few days while Google re-crawls, then recovers.

How long does a PrestaShop migration take?

A 1.7 → 8.x migration takes 2–4 weeks; 1.6 → 8.x/9.x with custom modules takes 4–6 weeks. The timeline depends on the number of modules to review, the size of the catalogue and the integrations to reconnect. The old store keeps selling during the whole process.

Can the store keep running during the migration?

Yes. The migration runs on a staging copy of the store, so the live store stays untouched until the switch. The switch itself happens in a low-traffic window and takes minutes — orders are not lost because the database is the same one that goes live.

What happens to my orders and customers during migration?

All orders, customers, addresses, B2B groups and order history are migrated, so your customer service sees the complete history after the switch. Passwords are transferred as hashes — customers keep logging in with the same credentials and nobody has to reset anything.

Do you migrate custom modules and integrations?

Yes. Custom modules are reviewed for compatibility with the target version and either updated, replaced or rewritten. Integrations (Allegro, Baselinker, ERP, carriers, payments) are reconnected and tested end-to-end in sandbox mode before go-live, then verified again on production.

Sources

• PrestaShop developer documentation — migration guides
• PrestaShop — supported versions and releases
• Google Search Central — site moves with URL changes
• PHP — supported versions