Magento to Shopware migration: the import is the smallest problem

The real work is in mapping Magento's EAV data model onto Shopware's entities, rebuilding the frontend, and replacing the extensions. If your budget is based on what the importer costs to run, you've scoped about a third of the project.

We've built on both platforms for years. This article covers what the importer handles, where it stops, and — honestly — when staying on Magento is the better call. The general migration methodology is in the Shopware 5 to 6 migration article and the Replatforming Guide; here we focus on what's specific to Magento.

What this article covers

• Why Magento merchants switch in 2026, and when they shouldn't

• What the Shopware Magento migration profile transfers and what it doesn't

• How Magento's EAV model maps to Shopware entities

• What gets rebuilt: frontend, extensions, integrations

• Timeline and budget realities

• When it makes more sense to stay on Magento

Why merchants migrate from Magento to Shopware in 2026

Three forces drive most projects: Adobe's direction with Magento, the total cost of ownership gap that widens with every extension, and Shopware's B2B Suite reaching feature parity for mid-market merchants.

Adobe Commerce Cloud is enterprise software priced and governed as such. Merchants who don't need the full Adobe Experience Cloud stack face licence costs, mandatory service agreements, and a release cadence they can't influence. Magento Open Source solves the licence problem but removes the support structure, leaving merchants responsible for security patches, PHP upgrades, and extension compatibility on their own.

Extension cost is the second lever. A typical mid-market Magento setup carries 20–40 paid extensions. Each has its own compatibility matrix, its own update cycle, and its own support contract. Every Magento minor release triggers a compatibility check across the whole stack. Shopware ships more functionality in core and its extension marketplace is smaller but more curated.

The third factor is the frontend. Magento's Luma and Blank themes are aging; Hyvä has improved the situation but requires its own ecosystem of compatible extensions. Shopware's Storefront is a clean Twig-based layer, and Shopware Frontends (the headless option) uses a documented API that doesn't change with every minor release.

When you should not migrate

Shopware is not the right answer for every Magento merchant. Before scoping a migration, check whether any of these apply.

You are running Adobe Commerce and actively using the B2B module, Shared Catalogues, or the Adobe Experience Cloud integrations (AEM, Target, Analytics). Shopware's B2B Suite covers many scenarios but the Adobe stack integrations have no equivalent in Shopware, and rebuilding them is a significant project on its own.

Your catalogue has more than 500 000 SKUs with complex configurable products and custom options. Shopware handles large catalogues but the data mapping from Magento's configurable/simple product model to Shopware's variant system requires careful planning, and performance testing at scale should happen before you commit.

You have heavily customised the Magento admin or built internal tools against the Magento API. Those integrations will need to be rebuilt against Shopware's Admin API, which has a different structure and authentication model.

If none of these apply, Shopware is a realistic target. If any of them apply, scope the rebuild cost before you decide.

What the Shopware Magento migration profile does

Shopware ships a Migration Assistant plugin that connects to a Magento 2 database and imports data via a predefined profile. The profile handles:

• Customers and addresses

• Orders and order items (status mapping is configurable)

• Products: simple, configurable, virtual, and downloadable

• Categories and the category tree

• CMS pages and blocks (basic content, not Page Builder)

• Product images (downloaded from the source store)

• Customer groups

• Tax rules and rates

• Property sets and attributes (mapped to Shopware properties and custom fields)

The importer runs in the Shopware admin. It reads directly from the Magento 2 database connection you configure, so the source store stays live during the migration. Delta runs are possible: you can re-run the migration and only changed records are updated.

What the migration profile does not cover

The gaps are where most projects underestimate effort.

• Bundle products and grouped products have no direct equivalent in Shopware and require manual remapping or a custom extension.

• Custom option data on simple products (Magento's per-product customisation layer) is not migrated. If you use custom options for personalisation or configuration, plan to replace them.

• Gift cards are not included in the migration profile.

• Magento Page Builder content does not import into Shopware's Shopping Experiences (CMS). Pages built with Page Builder need to be rebuilt in the Shopware CMS editor.

• URL rewrites are imported as redirects but the mapping logic needs review: Magento generates a large number of URL rewrites, many of which are internal redirects that don't need to become Shopware SEO URLs.

• Promotions and cart price rules are not migrated. Shopware's promotion engine has a different rule structure and all promotions need to be rebuilt.

• Reward points and store credit have no equivalent migration path.

• Newsletter subscribers can be exported from Magento and imported into Shopware, but the migration profile does not handle this automatically. You need to export the subscriber list and import it via the Shopware import/export module.

How Magento's EAV model maps to Shopware

This is where most of the technical complexity lives. Magento uses an Entity-Attribute-Value (EAV) database model for products and customers. Attributes are rows in a separate table, not columns. This gives Magento flexibility for large attribute sets but makes queries expensive and the schema non-obvious to external tools.

Shopware uses a relational model with a fixed product schema and two extension mechanisms: Properties (for filterable attributes like colour and size) and Custom Fields (for non-filterable additional data). The migration profile maps Magento attributes to one of these two mechanisms based on rules you configure, but the mapping is not always obvious and needs review for every attribute set.

Specific things to plan for:

• Magento attribute sets become Shopware property groups. If you have many attribute sets with overlapping attributes, consolidation before migration simplifies the Shopware data model.

• Configurable product options in Magento (size, colour selectors) become variant options in Shopware. The mapping works for simple cases but breaks down when configurable products have more than two dimensions or when the option values are not consistent across the catalogue.

• Magento tier prices (quantity-based pricing) map to Shopware's advanced pricing rules. The logic is similar but the data structure differs; expect manual review for complex pricing tables.

• Multi-store setups in Magento (multiple websites, store views) map to Shopware's sales channel and language structure. The mapping is not one-to-one: a Magento store view used for language is a Shopware language; a store view used for a different domain is a Shopware sales channel. Review your Magento store structure before starting the migration.

What gets rebuilt

After the data import, three areas require rebuild work regardless of how clean the migration ran.

The frontend. Your Magento theme does not transfer. Whether you were on Luma, Blank, or Hyvä, the frontend needs to be rebuilt in Shopware's Storefront (Twig) or as a headless frontend using Shopware Frontends. For most mid-market merchants, this is the largest single item in the project budget.

Extensions. Every Magento extension you rely on needs a Shopware equivalent or a custom replacement. Start by auditing your extension list and mapping each one to a Shopware app, a Shopware plugin, or a custom development. Extensions with no Shopware equivalent that cover core business logic are the highest-risk items in the project.

Integrations. ERP, PIM, CRM, payment providers, shipping providers, and any custom API integrations need to be rebuilt or reconfigured against Shopware's APIs. Shopware provides a documented REST API and webhook system, but the endpoints and authentication model differ from Magento's API. Allocate time for each integration separately.

Timeline and budget realities

A Magento to Shopware migration for a mid-market merchant with a standard catalogue (under 50 000 SKUs, one storefront, 10–20 extensions) typically runs four to eight months from kickoff to go-live. The data migration itself takes days. The rest of the timeline is frontend development, extension replacement, integration work, testing, and content rebuild.

Budget anchors to plan for:

• Frontend rebuild: typically 30–40% of the total project budget

• Extension replacement and custom development: 20–30%

• Integration rebuild: 15–25%

• Data migration, QA, and go-live: the remainder

These are planning anchors, not quotes. The actual split depends on the complexity of your frontend, the number and type of your extensions, and the number of integrations. A project with a headless frontend and a heavy ERP integration will look very different from a standard storefront with off-the-shelf extensions.

SEO continuity during migration

URL structure is the first SEO concern. Magento and Shopware generate URLs differently. If your Magento store uses category paths in product URLs (e.g. /category/subcategory/product.html), Shopware's default URL structure will not match. Plan your Shopware URL structure before the migration and set up 301 redirects for every changed URL. The migration profile imports Magento URL rewrites as Shopware SEO URL redirects, but review the output: Magento often has thousands of internal redirects that add noise.

Meta data (title tags and meta descriptions) migrates with the product and category data. Check the character lengths after migration: Magento and Shopware have different field length defaults and some meta fields may be truncated.

Structured data changes with the frontend rebuild. If your Magento theme had custom schema.org markup, verify it is rebuilt in the Shopware theme. Shopware's Storefront includes basic product schema, but review it against your current implementation.

The migration in practice

A Magento to Shopware migration that goes well follows a consistent pattern: a thorough discovery phase where the Magento setup is audited before any development starts, a data migration that runs early and iterates, a frontend built in parallel, and a cutover plan that minimises downtime.

Projects that run into trouble usually share one of three characteristics: the discovery phase was skipped or too short, the data migration was treated as a one-time event rather than an iterative process, or extension replacements were scoped without checking Shopware's marketplace first.

If you're at the point of scoping a Magento to Shopware migration and want an independent assessment of what your specific setup involves, we're happy to take a look.