Migrating Shopware 5 to Shopware 6: What You're Really Getting Into

Anyone who treats a Shopware 5 to 6 migration as an update is underestimating the project. Shopware 6 is a complete rewrite — different framework, different template engine, different database structure, different plugin API. In practice, this means the old shop is replaced in parallel by a new one. Products, customers, and orders are migrated, but the theme, plugins, and integrations must be rebuilt from scratch.

This guide summarizes what a migration actually involves, which mistakes are avoidable, and what realistic planning looks like.

Why Migration Is No Longer Optional¶

Shopware 5 has been end of life since July 2024. No security updates, no bug fixes, no new features. This has three concrete consequences:

1. Payment providers are moving on. Stripe, PayPal, and others no longer update their integrations for Shopware 5. When a provider changes its API, payment processing may silently break.
2. PHP compatibility is ending. Modern servers run PHP 8.3+. Shopware 5 has limited compatibility with newer PHP versions. Hosting providers will eventually discontinue old PHP versions.
3. Security vulnerabilities remain unpatched. Known vulnerabilities in Shopware 5 and its plugins are documented in public databases and actively exploited. An unpatched shop system is an open target.

Every month of delay widens the technical gap and increases migration effort.

Technical Differences: Not an Update, a Rebuild¶

These differences mean: no Shopware 5 plugin runs in Shopware 6 without adaptation. No theme is directly transferable. This is the single biggest cost driver in any migration.

Phase 1: Inventory and Audit¶

Before a single line of code is written, a complete inventory must be taken. Without this step, reliable effort estimates are impossible.

Technical Audit¶

• Which Shopware 5 version and PHP version are running?
• Were core files modified directly? (common issue in older shops)
• How clean is the product data? Duplicate categories, missing required fields, inconsistent variants?
• Are there custom database tables not managed through plugins?

Plugin Inventory¶

The plugin question is the emotional and financial core of every migration. A typical mid-sized shop has 15–25 active plugins. Each one requires a decision:

The detailed approach:

1. Document all active Shopware 5 plugins — name, vendor, function, version
2. Check the Shopware 6 Store for a compatible version
3. For each missing plugin, decide: custom development, alternative vendor, or drop the feature
4. Include custom development costs in the project budget

Industry experience shows that 20 to 40 percent of active plugins have no Shopware 6 equivalent. For heavily customized B2B shops, this percentage can be higher.

Interfaces and Third-Party Systems¶

Which external systems are connected?

• ERP / inventory management (SAP, Microsoft Dynamics, Lexware, DATEV, JTL, Xentral)
• PIM system (Akeneo, Pimcore, custom solution)
• Marketplace integrations (Amazon, eBay, Otto via Magnalister etc.)
• Payment providers (PayPal, Stripe, Klarna, Mollie)
• Shipping carriers (DHL, DPD, GLS, Hermes)
• Marketing tools (newsletter systems, tracking, feeds)
• Accounting (DATEV export, invoicing tools)

Each of these interfaces must be reconfigured or rebuilt for Shopware 6. For middleware solutions connecting to SAP or Dynamics, consult the IT partner before starting.

Identify Stakeholders¶

A shop migration affects more than just IT. The following people need to be involved:

• Management — budget, timeline, go-live date
• Marketing / e-commerce manager — SEO, content, campaign planning
• Purchasing / product management — product data quality, category structure
• Logistics / fulfillment — shipping processes, warehouse integration
• Accounting — DATEV export, invoicing, payment reconciliation
• External ERP service provider — interface migration
• Agency / development team — implementation

Involving stakeholders too late means discovering missing requirements during the test phase — the most expensive point for changes.

Phase 2: Set Up Shopware 6 and Plan Architecture¶

Choose an Edition¶

Shopware 6 offers several editions. The choice affects costs and available features:

License costs come on top of migration costs. For many mid-sized shops, the Community Edition with targeted plugin additions is the most economical choice.

Prepare the Hosting Environment¶

Shopware 6 has different requirements than Shopware 5:

PHP 8.2+
MySQL 8.0 / MariaDB 10.11+
Composer 2
Node.js 20 LTS or newer (for storefront build, depending on Shopware version)
OpenSearch for Advanced Search; plan Elasticsearch/OpenSearch only when search and listing requirements justify it
Redis or Varnish (recommended for caching)

Full system requirements depend on the target version and are documented in the official Shopware documentation. Define the target version before the project starts, because Shopware 6.7 can have different runtime requirements than older 6.x installations.

The staging environment should mirror the production environment as closely as possible. Migration testing on a different setup leads to unpleasant surprises at go-live.

Phase 3: Data Migration¶

What the Migration Assistant Handles¶

Shopware provides the official Migration Assistant as a plugin. It transfers:

• Products (including variants, prices, images)
• Categories
• Customers and customer groups
• Order history
• Media
• Manufacturers
• Reviews

The assistant works incrementally — it can be run multiple times until the data is correct. This allows parallel development: the old shop keeps running while the new one is populated.

What the Migration Assistant Does Not Handle¶

• Shopping Worlds / Shopping Experiences — must be manually rebuilt in Shopware 6's Shopping Experiences
• Static CMS pages — content transferred manually
• Custom fields and custom database columns — require manual mapping
• Plugin data — plugin-specific tables are not migrated
• Cross-selling configurations — must be set up from scratch
• SEO URLs — are transferred, but the URL logic differs and often produces different paths

Clean Up Data Quality Before Migration¶

Product data from mature Shopware 5 installations is rarely clean. Typical problems:

• Orphaned categories with no assigned products
• Duplicate article numbers or inconsistent variant structures
• Missing or truncated description texts
• Images without alt texts
• Inactive products that haven't sold in years

Industry experience: shops with poor data quality spend 30 to 50 percent of migration time on data cleanup. It pays to plan for this effort upfront.

Phase 4: Theme and Design¶

Why a Complete Rebuild Is Necessary¶

Shopware 5 uses Smarty templates and a custom CSS framework. Shopware 6 uses Twig templates and Bootstrap 5. A direct theme transfer is technically impossible.

This is also an opportunity: most shops benefit from a design modernization. Mobile-first implementation, better Core Web Vitals, and a cleaner checkout are significantly easier to achieve with the new storefront.

Shopping Worlds Become Shopping Experiences¶

Shopware 5 uses "Shopping Worlds" (Einkaufswelten) for landing pages and custom layouts. Shopware 6 completely rebuilt this concept as "Shopping Experiences" (Erlebniswelten). The content is not technically transferable — every page must be rebuilt manually.

For shops with dozens of Shopping Worlds, this is substantial effort that is often underestimated. A pragmatic approach: rebuild the 10–15 most important pages (measured by traffic) for go-live, handle the rest post-launch.

Theme Development Is Rarely Just Design¶

Especially in B2B shops, the theme contains far more than corporate design. The frontend often simultaneously implements:

• Pricing logic for customer groups (net/gross, tiered pricing)
• Login areas and protected catalogs
• Custom order processes with approval workflows
• Quick-order functions with article number input

Phase 5: Reconnect ERP and Integrations¶

API-First Changes Everything¶

Shopware 5 ERP integrations were often based on direct database connections or proprietary APIs. Shopware 6 is API-first: all data flows through the documented Admin API or Store API.

This means every existing ERP integration must be migrated to the Shopware 6 API. Existing third-party connectors are often not directly available as SW6 versions or work differently.

Data flows that must be reimplemented:

Industry experience: plan at least four to eight weeks of development time for an ERP reconnection — even if the ERP system itself remains unchanged.

Payment Providers and Shipping¶

Payment providers like Mollie, Stripe, or Klarna offer Shopware 6 plugins. Nevertheless, all payment methods must be reconfigured and tested — in particular:

• Test orders with every payment method on staging
• Refunds and cancellations
• Webhook configurations
• PCI-DSS compliance for credit card payments

The same applies to shipping carriers: DHL, DPD, GLS, and Hermes have their own Shopware 6 plugins that must be set up fresh. Shops using shipping rules with weight or value thresholds must reconfigure them completely.

Phase 6: SEO Safeguarding¶

SEO mistakes during migration lead to ranking losses that take months to recover. This phase is most frequently underestimated.

URL Mapping and 301 Redirects¶

Shopware 6 generates URLs using different rules than Shopware 5. Category-based paths, product detail pages, and filter URLs can change completely.

Every URL that is indexed in Google and generates traffic needs a correct 301 redirect:

1. Export all indexed URLs from Google Search Console
2. Crawl the current Shopware 5 instance with Screaming Frog or a similar tool
3. Create a mapping table: old URL → new URL
4. Implement 301 redirects in Shopware 6 or at server level
5. After go-live: verify all redirects return correct status codes (301, not 302)

# Example: nginx redirect map for typical SW5 URL patterns
map $uri $redirect_url {
    ~^/detail/sArticle/(\d+)$     /product-detail-page;
    ~^/listing/$                  /category-page;
    ~^/blog/detail/sCategory/     /blog-category;
}

server {
    if ($redirect_url) {
        return 301 $redirect_url;
    }
}

Common mistake: filter URLs and search result URLs are not included in the mapping. This causes massive 404 errors for internally linked pages.

Metadata and Structured Data¶

• Check and transfer meta titles and descriptions
• Verify H1 headings on all important pages
• Review and rebuild structured data (Schema.org) if necessary
• Verify canonical tags
• Generate and submit the Shopware 6 XML sitemap to Google Search Console
• Correctly configure hreflang tags for multilingual shops

Phase 7: Testing and Go-Live¶

Test Scope¶

The testing phase is often treated as the last step before launch. In reality, it is a standalone sub-project:

• Walk through the entire order process — cart, checkout, confirmation email, order overview in customer account
• Test all payment methods — in test and live mode
• User accounts — login, registration, password reset, address management
• ERP synchronization — does a test order arrive correctly in the ERP?
• Shipping process — label creation, tracking number, status updates
• Performance — measure Core Web Vitals, test load times under stress
• B2B-specific — net prices, approval processes, quotas, debtor numbers
• Mobile — complete order process on smartphone and tablet

Go-Live Strategy¶

The switchover should be planned as a controlled process:

1. Final data sync — last migration run with current orders and customer changes
2. DNS switchover — point the domain to the new shop
3. Monitoring — actively monitor for the first 48 hours: 404 errors, server load, conversion rate
4. Rollback plan — in case of emergency: DNS back to the old shop. The old shop should remain operational for at least two weeks after go-live

A Monday or Tuesday go-live has proven effective — not before a weekend, not before holidays. This leaves enough time to fix problems before traffic peaks arrive.

Costs and Timeline¶

Realistic experience values from the DACH region:

Factors that drive effort up:

• ERP integration — when SAP, Dynamics, or JTL must be reconnected, it becomes a standalone sub-project
• Poor data quality — 30–50% of migration time goes to data cleanup
• Custom B2B logic — approval workflows, quotas, customer group pricing
• Multilingual support — each additional language multiplies effort for content, SEO, and testing
• International shipping — country-specific tax rules, customs handling, local payment methods

Common Mistakes and How to Avoid Them¶

1. Starting Migration Without an Audit¶

Jumping in without a complete inventory means discovering missing requirements during the test phase. That is the most expensive point for changes.

2. Underestimating Plugin Effort¶

"That plugin surely exists for SW6 too" — often it does not. 20–40% of plugins must be rebuilt or replaced with alternatives. This effort is regularly underestimated by a factor of 2–3.

3. Treating SEO as an Afterthought¶

Setting up 301 redirects after go-live is not enough. URL mapping, metadata, and structured data must be in place before launch. Rankings that are lost take months to recover.

4. Having No Rollback Plan¶

When something goes wrong at go-live — ERP sync broken, payment provider unresponsive — the old shop must be reachable again within minutes. Without a rollback plan, a technical problem becomes a business outage.

5. Going Live Before a Weekend or Sale Event¶

Going live on Friday afternoon so everything can "settle" over the weekend? Bad idea. Problems almost always surface within the first 48 hours. The go-live needs the entire team on standby.

Further Reading¶

• Official Migration Documentation — Shopware's own guide for the SW5-to-SW6 migration
• Migration Assistant: Setup and Process — step-by-step guide for the Migration Assistant
• Shopware 6 System Requirements — PHP, MySQL, Node.js, and other prerequisites
• Plugin Development in Shopware 6 — getting started with the new plugin API for custom development
• Shopware 6 Store — plugins and extensions for Shopware 6

Conclusion¶

A Shopware 5 to 6 migration is not an afternoon project. It is a platform change that takes 3–6 months and affects every area of the business — from IT through marketing and purchasing to accounting.

The most important success factor is preparation: a clean audit, a complete plugin inventory, and a realistic timeline prevent most problems. Skipping this phase means paying double later.

My recommendation: start with the technical audit, set the budget based on the results, and only then commission the implementation. Migration projects that start with a fixed-price quote and no audit almost always run into trouble.