Shopware migration services: Shopware 5, Shopware 6 and beyond

Shopware is PHP ecommerce software with its strongest base in Germany, Austria and Switzerland. We see three kinds of projects. Shopware 5 stores have to move because Shopware 5 has reached end of life and no longer receives regular security updates from Shopware; the options are Shopware 6 or another platform. Shopware 6 stores sometimes move to a hosted platform such as Shopify to reduce hosting, update and plugin maintenance. And merchants move onto Shopware 6 for its rule builder, B2B features and sales channels.

For a Shopware 5 store, the honest question is not "how do we upgrade" but "which platform do we rebuild on". Both Shopware 6 and a hosted platform mean a new theme, new plugins and a data migration. We compare them on your catalog, integrations and team, not on preference.

When not to move: a Shopware 6 store whose problem is one plugin or slow hosting usually needs a fix, not a replatform.

Both versions are usually self-hosted, so we can read the database, and Shopware 6 also exposes an Admin API. Shopware 5 stores articles, article details (variants), configurator groups and options, properties, and translations in its own tables, with custom data often in attribute tables added by plugins. Shopware 6 uses a different, entity-based model: products with parent and child variants, property groups, custom fields, and per-sales-channel visibility, SEO URLs and prices.

The pitfalls: plugin data outside the core tables, advanced prices by customer group and quantity, price rules tied to the rule builder, several sales channels or subshops with different catalogs and domains, and translations that are incomplete in one language. Order history is readable in both versions, but payment and shipping methods and order states are store-specific, so orders are mapped rather than copied.

For Shopware 5 to 6, Shopware provides the Migration Assistant plugin, which connects the two shops and moves core data such as products, manufacturers, categories, customers and orders, with a data check that flags records it cannot assign. We use it where it fits, but it does not move themes, and plugin data only moves when the plugin supports it, so the audit decides what goes through the assistant and what needs a custom import.

From other platforms we import through the Admin API or scripted imports. Shopware 6 expects property groups and options to exist before variants are generated, sales channels to be set up before visibility and prices are assigned, and custom fields to be defined in custom field sets. Rule-based prices and B2B structures are configured on the target and tested rather than imported blind.

Shopware 5 to 6: configurator sets become variant properties, article attributes become custom fields, subshops and language shops become sales channels and domains, and shopping worlds (the Shopware 5 page builder) are rebuilt as Shopping Experiences layouts, because the layout structure differs.

Shopware to another platform: parent and child variants become the target's variant model, which may allow fewer option dimensions, so we check the number of properties per product first. Custom fields become metafields or custom attributes. Categories that act as landing pages with layouts become collections plus pages. Advanced prices and rule-based prices become customer-group pricing, price lists or discounts, and some rules have no equivalent. Each sales channel has to be mapped to a store, a market or a language.

Shopware stores depend on plugins from the Shopware Store for payments, shipping, ERP connectors, B2B features, filters and marketing. Shopware 5 plugins do not run on Shopware 6, so each one needs a Shopware 6 version, a replacement or custom work. Leaving Shopware, each plugin's data is checked and either exported, replaced by an app on the target or retired with your agreement.

Themes are rebuilt in every direction: Shopware 5 Smarty themes and Shopware 6 Twig themes are not compatible with each other or with other platforms. Payment providers, shipping rules and tax settings are configured again and tested with real test orders. ERP and warehouse integrations, which are common in DACH stores, are reconnected and checked with live data before launch.

Shopware generates SEO URLs from templates. In Shopware 6 they are configured under Settings > SEO, per route and per sales channel, and the product template typically combines the product name and product number. Old URLs are kept in the SEO URL table, so a Shopware store often already has several historical URLs per product. Shopware 5 used its own router templates, so a 5 to 6 move changes URLs even when the domain stays the same.

We export the SEO URL tables, crawl the live store and pull top landing pages from Search Console, then map every indexed product, category and CMS URL to its new address, per domain and language. Moving onto Shopware 6, we set the templates before import so URLs are stable at launch. After launch we re-crawl for 404s and redirect chains. We do not promise rankings; we make sure old URLs land on the right page.

Customer passwords: within Shopware, legacy Shopware 5 hashes can be handled on Shopware 6, which we confirm in the trial; a move to a hosted platform means customers set a new password. Saved payment methods stay with the provider. Rule-builder logic, B2B hierarchies and quotes may have no equivalent on a simpler target.

Shopping worlds and Shopping Experiences are layout data and are rebuilt, not converted. Stores with many sales channels and different catalogs per channel may need several target stores. Shopware 5 stores on old PHP versions sometimes cannot run the Migration Assistant without server work, which the audit flags early.

We start with an audit: Shopware version and edition, plugins, sales channels or subshops, catalog and variants, prices and rules, SEO URLs and integrations. From that we write the data mapping and decide which parts go through the Migration Assistant and which through custom imports. A trial migration loads the data into a staging store, and you review products, customers, orders and URLs there.

After sign-off we agree a short catalog freeze, run the final migration plus a delta of new orders and customers, switch domains, activate redirects and run post-launch QA: test orders, redirect checks, Search Console monitoring and integration checks. One named lead owns the whole project.