Skip to content

Expert Answers to Your Magento, Shopify & Shopware Questions

Vendor-neutral, engineer-written explanations. Clear definitions first, then practical steps with real examples — no fluff.

Stagebit builds and maintains stores on Magento, Adobe Commerce, Shopify, Shopware, and Laravel, and this library holds the questions our own engineers get asked most often on each platform.

What Does the Shopware Migration Assistant Carry Over, and What Does It Not?

SB
Written by Stagebit Engineering Team
Updated September 2026 4 min read Verified by engineers

Run the Shopware Migration Assistant and most of your shop shows up on the other side without you touching it: catalog data, customer accounts, order history, SEO URLs, the works. What doesn’t come across is anything visual or logic-based. Your theme, your Flow Builder rules, your payment method setup, none of that survives the trip. Think of it as a data mover, not a full shop clone.

The Shopware Migration Assistant is Shopware’s official plugin for transferring store data into Shopware 6, either from Shopware 5 or from another Shopware 6 shop. This applies to Migration Assistant version 6.7.0.0 and newer.

Migrates automaticallyDoes not migrate
Products, categories, manufacturers, propertiesThemes and templates
Customers and full order historyFlow Builder flows
Media, CMS layouts, category connectionsCustom extension database tables
SEO URLs and templatesPayment methods (mapped, not copied)
Promotions, wishlists, newsletter sign-upsImport/export profiles
Most shop settings, with translationsShopware 5 product streams

Quick Answer

Migrated automatically: products, customers, orders, categories, manufacturers, properties, media, promotions, wishlists, newsletter recipients, layouts, and SEO URLs, plus most store settings and their translations. Skipped: themes and templates, Flow Builder flows, import and export profiles, custom database tables from third-party extensions, and Shopware 5 product streams. Product streams need rebuilding with the Shopware 6 Rule Builder instead. Payment methods aren’t copied either, you set them up fresh in the target shop and map old orders to the new ones as part of the migration run.

What the Migration Assistant Carries Over

The core of your shop moves without much fuss. Here’s what actually crosses over:

  • Products, categories, manufacturers, and properties, along with dynamic product groups and their filters
  • Customer accounts and full order history, including order documents
  • Cross-selling relationships and product reviews
  • Media files, CMS layouts, and how categories connect to them
  • Promotions, wishlists, and newsletter sign-ups
  • SEO URLs and their templates
  • Most shop settings: currencies, countries, languages, customer groups, tax rules, shipping, delivery times, number ranges, email templates, snippets, custom fields, and sales channel setup

All of it comes with translations attached, so a shop running in three languages doesn’t lose two of them in the move.

What the Migration Assistant Leaves Behind

Six things won’t show up automatically, and each one needs a different kind of manual work.

  • Themes and templates. Shopware 5 ran on Smarty, Shopware 6 runs on Twig. There’s no converting one into the other. You reinstall or rebuild the theme in the target shop.
  • Flows. Flow Builder automations stay behind. If you built rules around order events or customer triggers, you’re recreating them by hand.
  • Custom extension data. Data stored in Shopware’s standard tables comes along fine. Data in an extension’s own tables doesn’t, and that extension needs a fresh install on the new shop.
  • Payment methods. Not copied directly. Set up the payment methods you want in the target shop first, then map the old ones to them during migration.
  • Import and export profiles. Custom profiles and log history from that module get left behind and have to be rebuilt.
  • Shopware 5 product streams. These relied on dynamic product group logic that Shopware 6’s Rule Builder doesn’t use, so they can’t transfer. Build them again from scratch.

What Still Needs a Manual Check

Three things technically migrate but shouldn’t be trusted blindly before launch.

  • SEO URLs. They usually come across fine, but a changed category tree can quietly break individual URLs. Crawl the new shop and compare before you go live.
  • Extension settings. Even when an extension’s data transfers, its license and configuration often need re-entering. Check with the extension’s developer if you’re unsure.
  • Payment method mapping. Confirm every old payment method has a matching new one. Miss one and historical orders show the wrong method.

Which Source Systems This Applies To

Everything above describes migrating within Shopware, Shopware 5 to Shopware 6, or Shopware 6 to Shopware 6. Moving from a different platform like Magento changes the picture, since the assistant is translating field structures between two different systems instead of moving within one schema. If the theme rebuild and extension audit are the real unknowns in your Shopware 5 to 6 project, get a Shopware developer to scope that before you touch the data.

Split the work into two jobs and this gets a lot less stressful. One job is data, and the Migration Assistant handles that on its own. The other is everything visual and behavioral: theme, flows, payment mapping. That part needs a person, and it needs its own timeline. Run them side by side instead of back to back, and launch day stops being a scramble. For a sense of how long that second half usually takes, see our answer on Shopware 5 to 6 migration timelines.

This breakdown is based on Shopware’s official migration documentation, current as of Migration Assistant 6.7.0.0.

Was this answer helpful?

Your feedback helps us improve our answers.

Still need help?

Planning a Shopware migration?

If you're weighing what the Migration Assistant will and won't handle for your shop, our Shopware developers can scope the theme rebuild, flow recreation, and extension work it leaves behind.

Talk to Shopware Experts