The Shopware Migration Assistant is a free plugin from Shopware that transfers data from an existing shop system to a Shopware 6 installation. Using interchangeable migration profiles, it supports Shopware 5 as well as Magento 1 and 2, amongst others, as source systems. It is the standard tool for the data aspect of a replatforming project — but deliberately covers only part of a complete migration.
What the Migration Assistant is and how it works
The Migration Assistant (technically the plugin SwagMigrationAssistant) is installed in the new Shopware 6 installation. It connects in read-only mode to the source system’s database: Nothing is changed on the old shop; it remains untouched and fully operational during the migration. The Assistant reads the source data, maps it to the corresponding Shopware entities and writes it to the new installation.
A key feature is repeatability: A migration can be run multiple times without creating duplicates, because the Assistant remembers which source record has been mapped to which target record. This allows you to test a subset first and then synchronise again later if orders or customers have been added to the source shop.
Supported source systems and profiles
Support for source systems is provided via interchangeable migration profiles. The Assistant comes with the profile for Shopware 5 as standard. Additional profiles are available as separate extensions:
- Shopware 5: the standard case, included directly in the Assistant.
- Magento 1 and 2: via the separate Magento migration profile from the Shopware Store.
- Other profiles (such as those for Gambio or OXID) come from the community or third-party providers.
A migration from Magento therefore requires two components: the Migration Assistant itself and, in addition, the Magento migration profile. Only when used together do they connect a Magento 1.9 or Magento 2 database to Shopware 6.
Which data is transferred
The Assistant covers the structured master data that forms the core of a shop:
| Data type | Examples |
|---|---|
| Catalogue | Products, variants, categories, manufacturers, attributes |
| Customers | Customer accounts, addresses, customer groups |
| Orders | Orders and order lines (with restrictions) |
| Media | Product images and media folders |
| Configuration | Languages, currencies, tax rates, delivery countries |
Limitations and known issues
The Migration Assistant is a good starting point, not a complete migration. It transfers data, but not the shop’s visual appearance or functional logic. Three areas remain fundamentally unresolved:
- Frontend and theme: Magento themes (Luma, PWA Studio) cannot be converted into Shopware themes (Twig, Shopware frontends). The frontend must be rebuilt.
- Extensions: Magento extensions do not have an automatic Shopware equivalent. Each individual function must be reassessed and, if necessary, redeveloped.
- Custom business logic and interfaces: ERP, PIM or CRM integrations are not migrated but must be re-integrated.
Even with regard to raw data, there are documented weaknesses in the Magento profile, particularly concerning order data. Some orders are imported as net orders, although they should be gross; delivery address, dispatch method, dispatch status and dispatch costs are missing after import; and the table that Shopware needs for the correct tax calculation of the items remains empty. Such import results should be checked on a random basis after migration, not accepted blindly. Many projects therefore deliberately do not migrate historical orders on a one-to-one basis, but instead archive them separately and start Shopware with a clean order master.
Migration process using the Assistant
In practice, a migration using the Assistant follows a recurring pattern:
- Establish a connection: Enter the source system and login details in the Assistant; for Magento, also install the Magento profile.
- Check data: The Assistant analyses which data types are recognised and where there are gaps or conflicts.
- Confirm mapping: Source values (e.g. customer groups, tax rates, delivery countries) are mapped to their Shopware equivalents.
- Execute migration: The actual data transfer takes place, ideally on a test system first.
- Follow-up work and re-synchronisation: Verify order data, complete missing fields, and re-migrate records added subsequently.
As the front end, interfaces and custom functions are the deciding factors, the Migration Assistant is only the start of a replatforming process. A realistic overall timeframe for a Magento-to-Shopware migration is three to six months, depending on complexity.
Prerequisites and setup
A migration requires a working Shopware 6 installation in which the Migration Assistant is installed and activated, as well as read-only access to the source database. For a Magento migration, the Magento migration profile is also required, as it recognises the Magento-specific tables. The connection is set up in the Shopware admin area under ‘Settings → Migration Assistant’: The database host, name, username and password of the source system, as well as the path to the media files, are entered.
It is important that the media (product images) are accessible — either via a URL from the source shop that is still running or via a local path. If this access is missing, the data records will migrate, but the images will remain blank. This alone demonstrates that a migration requires planning: the old shop must remain accessible during the transfer.
When the Migration Assistant is worthwhile — and when it isn’t
The Assistant is the tool of choice when an existing shop with a substantial database needs to be migrated to Shopware 6 and the master data — products, customers, orders — must be retained. It is virtually unrivalled, particularly for Shopware 5 to 6 migrations, because the source and target systems come from the same provider and the mapping is correspondingly well-developed.
It is less suitable if a complete rebuild with a fresh catalogue is planned anyway. Those who are fundamentally restructuring their product range are sometimes better off building up the product data directly from a PIM or via a targeted import, rather than carrying over legacy data. Even with very unusual source systems without a ready-made profile, a customised import can be more cost-effective than developing a profile from scratch. This decision should be made at the start of the project, not during the implementation phase.
Architecture: Reader, Converter and Writer
Technically, the Migration Assistant operates in three steps that reflect the principle of any clean data migration. A Reader reads the raw data from the source system — in the case of Magento, directly from the EAV tables of the source database. A Converter translates this raw data into the format of Shopware entities, whilst storing in a mapping table which source data record has been mapped to which target data record. Finally, a Writer writes the converted data to the Shopware database via the Data Abstraction Layer.
This separation explains two key features of the tool: Firstly, the migration is repeatable because the mapping table prevents duplicates. Secondly, it is extensible — custom migration profiles or additional data converters can be added as plugins, for example to include data from a specific Magento extension not supported by the standard.
Migration Assistant versus manual export and import
In theory, a migration can also be carried out via CSV export and import or using a custom script. In practice, however, there are several arguments in favour of the Assistant: it understands the source structure (such as Magento’s EAV architecture), maintains the mapping automatically and is designed for repeatability. A pure CSV approach, on the other hand, quickly loses track of relationships between data records — which variant belongs to which parent product, which order belongs to which customer.
Conversely, the Assistant reaches its limits where data structures are fundamentally different or where custom logic needs to be transferred. In such cases, a mapping script or middleware complements the standard approach. The rule of thumb: the Assistant reliably handles structured bulk data, whilst special cases remain the subject of project-based work.
Best practices for a clean migration
- Always migrate to a test system first and check the result before setting up the production system.
- Verify order data specifically — particularly for the Magento profile, whose tax and shipping fields have known gaps.
- Deliberately limit the scope: Do all historical orders need to be included, or is a clean start with archived legacy orders sufficient?
- Perform multiple synchronisations: shortly before go-live, migrate any data records created in the meantime once more to ensure nothing is lost.
- Plan the frontend, extensions and interfaces early on as separate work packages — the Assistant does not cover them.
Used correctly, the Migration Assistant takes care of the most laborious and error-prone part of a replatforming project: the transfer of master data. However, it does not replace the project — it is its first, well-automated step.
Multilingual shops and multi-shop setups
A migration becomes challenging when the source system supports multiple languages, currencies or independent sales channels. Magento maps this via websites, stores and store views, whilst Shopware 6 uses sales channels and languages. These structures do not correspond one-to-one, which is why the mapping must be configured manually in the Migration Assistant: Which Magento store view corresponds to which Shopware language, and which website to which sales channel?
This is precisely where a test migration pays off. It is only in the test system that it becomes clear whether translations, prices per channel and customer groups are mapped correctly. If these mappings are overlooked, typical subsequent errors occur — missing translations, incorrectly assigned prices or products appearing in the wrong channel. For international retailers, this part of the migration is often more time-consuming than the product transfer itself.
Frequently asked questions about the Shopware Migration Assistant
How much does the Migration Assistant cost? The plugin is free of charge. For Magento, the Magento migration profile is also required, which can be obtained from the Shopware Store.
Does the Assistant alter the old shop? No. It only accesses the source database in read-only mode; the old shop remains unchanged and can continue to operate.
Does the Assistant also migrate the theme? No. The design and front end are not transferred, but are rebuilt in Shopware.
Can I run the migration multiple times? Yes. The Assistant remembers the mapping between source and target records and can synchronise again without creating duplicates.
Is the Migration Assistant sufficient for a complete migration? No. It covers the structured master data. The front end, extensions, business logic, interfaces and SEO redirect mapping remain project-based work.
Does the Assistant also support Magento 1? Yes. The Magento migration profile covers both Magento 1.9 and Magento 2 as source systems. As Magento 1 has been without security updates since 2020, it is a common starting point for migrations.
How long does a migration take using the Assistant? The data transfer itself depends on the size of the catalogue and the number of orders, and can take anywhere from a few minutes to several hours. However, the main time factor in a replatforming project is not the transfer itself, but the front-end, interfaces and testing — which usually takes a total of three to six months.
Further reading: the official documentation describes the migration process in detail in the Shopware migration documentation.