Shopware to Shopify migration (Shopware 5 and 6)

Shopware 5 has reached end of life, and Shopware no longer ships regular security updates for it. Its official path forward is Shopware 6, which is a different system: a new Symfony-based data model, a new administration, and plugins that must be replaced rather than updated. Because a 5-to-6 move is effectively a replatforming project, many merchants use that moment to compare Shopware 6 with Shopify.

Shopware 6 merchants move for different reasons: hosting and update overhead on self-hosted setups, plugin compatibility work at every major release, and agency dependency for changes that are app installs on Shopify. Shopify removes server operations, platform patching and checkout PCI scope from your team.

When not to move: stores with heavy B2B logic (customer-specific prices, quotes, complex Rule Builder conditions), deep ERP-driven processes or highly customised product configurators may find Shopware 6 fits better, or that Shopify requires Plus features and custom apps to match. We make that comparison explicit in the assessment.

The two versions store data differently, so the extraction is different. Shopware 5 keeps articles, variants built from configurator groups and options, filter properties, free text fields (attributes), subshops and language shops in its own schema; we usually extract directly from the database or through the Shopware 5 REST API, and check for legacy plugins that stored data in their own tables.

Shopware 6 uses products and variants generated from property groups and options, custom field sets, sales channels with domains, languages and currencies, Shopping Experiences layouts for CMS, and the Rule Builder for pricing and shipping logic. Extraction runs through the Admin API or the database. Both versions can hold plugin data not visible in the admin, so the audit checks the actual tables.

In Shopware, variants are built from property options (size, colour, material), and further properties are attached for filtering and product information. Shopify products support up to three option dimensions. Products that use more variant-defining property groups have to be restructured: either one group moves to separate products, or the least important option becomes a metafield or a line-item property handled by an app.

Non-variant properties and custom fields (Shopware 6) or free text fields (Shopware 5) move into Shopify metafields with defined types, and filter properties are connected to Shopify's storefront filters. Variant-specific data such as EAN, manufacturer number, purchase unit and reference unit for base prices (important for German price labelling) is mapped explicitly, because Shopify has no built-in base-price field and needs metafields or an app to show unit prices in the required format.

The Shopware category tree becomes Shopify collections plus navigation menus. Dynamic product groups in Shopware 6 translate reasonably well to automated collections when the conditions can be expressed as tags, vendor, type or price.

One Shopware installation can serve several storefronts: Shopware 5 through subshops and language shops, Shopware 6 through sales channels, each with its own domains, languages, currencies and sometimes different catalogs or prices. Shopify splits this differently. Countries, currencies, languages and domains or subfolders within one brand are handled by Shopify Markets in a single store. Separate brands, genuinely separate catalogs or strict legal separation usually mean separate Shopify stores, which on Plus can be managed as expansion stores.

We map each Shopware sales channel or subshop by its purpose: a translated storefront becomes a market language, a Swiss storefront in CHF becomes a market with its own currency and pricing, a B2B channel may need Shopify's B2B features (a Plus capability) or a separate approach. Old language-shop URLs are redirected into the new structure.

Customers, addresses, customer groups (as tags or B2B companies), company data and VAT IDs, and newsletter status are imported. Double opt-in records are kept as documented consent.

Passwords cannot be moved. Shopify does not accept imported password hashes from another platform, so customers set a new password or sign in with Shopify's customer accounts after launch. We plan the activation email in German or the relevant market language.

Order history is imported as historical orders with line items, net and gross prices, tax rates, shipping, discounts, payment method and status, linked to customers, with Shopware order numbers kept as references. Notifications stay off during import. Invoices, delivery notes and credit notes generated by Shopware remain archived documents; Shopify does not recreate them.

Shopware builds URLs from SEO URL templates, and many stores have customised them over the years, sometimes per sales channel. Defaults typically include the category path and an ID in Shopware 5 and the product name with product number in Shopware 6, but we never rely on defaults: we crawl every domain and read the SEO URL table to get the real, current URL set, including older URLs Shopware still redirects.

Shopify uses fixed paths: /products/{handle}, /collections/{handle}, /pages/{handle} and /blogs/{blog}/{handle}, with market subfolders in front where used. Nearly every Shopware URL therefore changes. The redirect map covers products, variants with their own URLs, categories, manufacturer pages, Shopping Experiences landing pages, blog posts and language-shop URLs, using crawl data, Search Console, sitemaps and backlink data. Redirects are imported into Shopify's URL redirects and apply because the old paths no longer exist there.

After launch we crawl again, test the map, submit sitemaps per domain and monitor Search Console. Redirects protect URL continuity; they cannot guarantee rankings, and we do not promise them.

Each Shopware plugin or app is reviewed: replace with a Shopify app, rebuild as a custom app, or drop. Common cases are payment plugins (PayPal, Klarna, SEPA and purchase on account through a provider), shipping and label plugins for DHL or DPD, ERP and marketplace connectors, product configurators and custom pricing rules. Shopware's Rule Builder and Flow Builder logic becomes Shopify discounts, Shopify Functions (on Plus for checkout-level changes), Shopify Flow or app logic, depending on what each rule does.

Legal and tax set-up is redone, not copied: tax-inclusive or net display per market, base price labelling, legal texts and checkout confirmation wording, invoice generation through an app or the ERP, and VAT for cross-border EU sales. The Shopware theme and Shopping Experiences layouts are rebuilt as a Shopify theme with sections and templates.

Audit: database and API access, plugin inventory, sales channel and domain map, SEO URL crawl, integration list. Mapping: a signed-off data map for properties, variants, custom fields, categories, customers, orders, content, URLs and integrations, with decisions on products exceeding three options.

Trial migration: a full import into the Shopify store, with counts and totals compared against Shopware per sales channel and a hand check of edge cases such as products with many variants, base price products, B2B customers and orders with mixed tax rates. Automation assists the comparison; a person approves. Sign-off: you test storefront, checkout, emails, invoices and admin workflows per market.

Launch: a short freeze, delta migration of new orders, customers and stock, DNS switch per domain, redirect activation and live test orders. Post-launch QA: redirect crawl, Search Console per property, feed and ERP checks, and order monitoring.

Passwords do not transfer. Products with more than three variant dimensions must be restructured. Complex Rule Builder pricing and B2B logic may need Shopify Plus or custom apps. Plugin data without a Shopify equivalent may only be archived. German base price display and invoicing require apps or ERP support that we specify during the audit.