Why German merchants choose a Magento to Shopware migration
Most German merchants move because keeping Magento current has become expensive, and Shopware 6 offers a comparable feature set with a free open-source edition and a large ecosystem focused on the DACH market.
The reasons we hear most are practical. Magento 1 shops have been running without official security patches since 2020. Magento 2 shops face regular upgrade projects to stay on a supported 2.4 release, and every upgrade drags extension updates and theme fixes behind it. Adobe Commerce merchants pay a licence on top. Meanwhile Shopware is developed in Germany, many German payment, shipping, legal-text and ERP providers publish Shopware extensions, and German-speaking developers and agencies know the platform well.
There are also reasons not to move. A large Magento 2 installation with deep custom modules, a skilled in-house team and a current version may be cheaper to maintain than to replace. A Magento to Shopware migration pays off most when an upgrade is due anyway, the shop has accumulated extension debt, or the licence cost no longer matches the value.
- Magento 1: no official security patches since 30 June 2020
- Magento 2: supported only on current 2.4 releases, with upgrades every few years
- Adobe Commerce: licence cost on top of development and hosting
- Shopware 6: free Community Edition under the MIT licence, paid plans when needed
Magento 1 and Magento 2.4 support timelines: what the dates mean
Magento 1 reached end of life on 30 June 2020, when Adobe released its final security patches for Magento Commerce 1 and Magento Open Source 1. Any Magento 1 shop still online today carries every vulnerability found since then unless a third party has patched it.
For Magento 2, Adobe’s software lifecycle policy gives each 2.4.x release three years of standard support from general availability. Adobe lists 2.4.6 with standard support ending on 11 August 2026 and 2.4.7 on 31 May 2027, with one additional year of support at no extra cost for Adobe Commerce customers on those two versions. 2.4.8 runs to 31 May 2028 and 2.4.9, released in May 2026, to 31 May 2029.
In practice this means a Magento 2 shop faces an upgrade project every couple of years just to stay supported. If your next upgrade is a large jump, with PHP, search engine and extension changes, it is the natural moment to price a Magento to Shopware migration against it. Adobe’s extended year applies to Adobe Commerce customers; if you run Magento Open Source, check the terms for your edition directly with Adobe.
Should you upgrade Magento or migrate to Shopware?
Upgrade Magento if your shop is on a recent 2.4 release, your extensions are maintained, and your team is comfortable with the platform. Migrate if the next upgrade is a big leap, your extensions are abandoned, or the Adobe Commerce licence feels out of proportion.
We put both options in front of you with numbers. For the upgrade: which version jump, which extensions need replacing, what theme work follows, and what the next upgrade after that looks like. For the migration: the data mapping effort, the theme rebuild, extension replacements and SEO work. The comparison is usually clear once both are costed on the same basis.
Two situations almost always favour moving. Magento 1 shops, because an upgrade to Magento 2 is itself a full rebuild with a data migration, so choosing Shopware costs little extra. And smaller Magento 2 shops whose owners find the admin heavy and the hosting demanding for their catalogue size.
Lean towards upgrading
Recent 2.4 version, maintained extensions, in-house Magento skills, heavy custom modules that would be costly to rebuild.
Lean towards Shopware
Magento 1, large version gap, abandoned extensions, licence pressure, or a small team overwhelmed by Magento upkeep.
How a Magento to Shopware migration works technically
The migration runs from inside a fresh Shopware 6 installation. Shopware’s documentation describes two extensions from the Shopware Store: the Migration Assistant and the Magento migration profile, which together connect to your Magento database and read the data out.
The connection needs database host, port, user, password and name, plus the table prefix if your Magento installation uses one. Shopware’s docs say the Magento database is generally read only during migration, so no changes are made there. For product and category images, the Shopware server also needs access to the Magento installation directory, and the docs stress entering the exact installation path and source URL, otherwise image migration can fail.
Once connected, the migration can be run repeatedly. The first run exposes data problems; subsequent runs confirm fixes and refresh orders and customers. A final run just before go-live picks up the latest changes. Stores become sales channels, store views become languages, and a pre-mapping step asks you to assign Magento order statuses, payment methods and tax rates to their Shopware 6 equivalents, which should exist before you start.
For Magento 2, Shopware notes that country, currency and language assignments made in sales channels are not in the database and cannot be migrated, so those settings are recreated by hand.
Mapping Magento attributes and attribute sets to Shopware properties
Attributes are where Magento and Shopware differ most. Magento groups them into attribute sets per product type; Shopware 6 has no attribute sets and uses properties for filterable information and variant generation, plus custom fields for everything else.
Shopware’s documentation explains the rules. All attributes are migrated except “manufacturer” and “cost”; the manufacturer attribute feeds Shopware’s own manufacturer entity. User-created attributes that are filterable in layered navigation, or used for configurable products, become properties. Other user-created attributes become custom fields. System attributes are handled by the core mapping.
That means the quality of your Shopware catalogue depends on how tidy your Magento attributes are. Before the first run we export the attribute list with usage counts and settings, then decide with you which attributes to merge, rename or drop. Twenty colour attributes created by different staff over the years should become one property. Attributes nobody filters by should not clutter the storefront. An hour of clean-up here saves days of fixing after the migration.
- Export attributes with type, usage count and filter settings
- Merge duplicates such as colour, colour_new and farbe
- Decide property versus custom field for each attribute
- Check option labels for German and other store-view languages
Configurable products, variants and other Magento product types
Configurable products map neatly: Shopware’s documentation says a Magento configurable product becomes a Shopware product container, and the simple products attached to it become its variants. One-dimensional and multidimensional variants are both supported.
The difference is conceptual. In Magento, each child is an independent simple product that happens to be linked. In Shopware 6, variants belong to a main product and inherit its settings unless overridden. That is usually an improvement, but it means child-level data that differs from the parent, such as separate descriptions or images per size, needs checking after migration.
The documentation lists simple and configurable products as the migrated product types. If your Magento catalogue uses bundle, grouped or virtual products, plan for them explicitly: bundles can become Shopware products with a custom plugin or a Store extension, grouped products often work better as cross-selling or Shopping Experiences layouts, and product options that Magento handles under Custom Options are covered in Shopware by its Custom Products extension, according to Shopware’s own dictionary for Magento users.
Customer groups, tier prices and B2B price lists
Customer groups migrate, but prices tied to them need planning. Magento tier prices and group prices must be rebuilt with Shopware 6 advanced prices, which are driven by Rule Builder conditions such as customer group or quantity.
For consumer shops this is straightforward: a few quantity breaks and perhaps a trade group. For B2B shops it can be the largest single part of a Magento to Shopware migration. Adobe Commerce B2B features such as company accounts, shared catalogues, requisition lists and quote negotiation do not have a one-to-one match in Shopware’s free edition. Shopware lists B2B Components, including quote management, from its Evolve plan upwards, and customer-specific pricing in Beyond.
We map your real B2B processes before choosing. Many dealers need only group prices, order approval and quick reorder, which Community Edition plus a small custom plugin can cover. Others genuinely need hierarchical company accounts and negotiated quotes, where a paid plan is cheaper than rebuilding it. Price lists coming from an ERP are best synchronised by an interface rather than migrated once; that work is priced from US$900.
For dealer ordering beyond the shop itself, see B2B portal development.
Migrating Magento customer passwords without forcing resets
Customers can keep their existing passwords. Shopware 6 supports legacy password encoders: the migrated customer record keeps the Magento hash, Shopware checks it with the matching algorithm at login, and on the first successful login re-hashes the password with its own standard method.
Shopware’s documentation adds one important instruction for Magento projects: do not uninstall the migration extension after going live, because the Magento password algorithms would then no longer be available and migrated customers could not log in. We leave it installed and note this in the handover pack, so a future developer does not remove it during a clean-up.
We test password migration on staging with real sample accounts from different eras of your shop, since older Magento installations used different hashing methods than newer ones. We also prepare a friendly reset email and a clear “forgot password” flow for the few accounts that fail, for example because they were created by an import without a password. Customers should never be locked out without an easy way back in.
Orders, invoices and order history
Order history migrates, so customers see past orders in their accounts and your team can look them up. Shopware’s documentation explains that orders are migrated according to delivery: an order with a delivery in Magento arrives as delivered, one without arrives as open, unless you choose other statuses in the pre-mapping.
Document templates are different. Magento generates invoices and credit memos on the fly when you open them, whereas Shopware 6 creates documents and stores them. Shopware notes that Magento document templates therefore cannot be migrated. Your new invoice layout is set up in Shopware 6, and historical invoice PDFs should be exported from Magento and archived before the old system is switched off.
Keep that archive for as long as your accountant or Steuerberater says you must; we do not advise on retention periods, but we make sure the export is complete and readable. If you send invoices to business or public customers in structured formats, the new shop can produce them; see our page on XRechnung and ZUGFeRD.
Multi-store setups: websites, store views and sales channels
Magento’s website, store and store view hierarchy becomes Shopware sales channels and languages. Shopware’s documentation says Magento stores become sales channels where possible, and store views become the languages of those channels.
For a German shop with an Austrian and Swiss storefront, or a German and English version, the mapping is usually clean. More complex setups, with separate brands on different domains, different catalogues per website, or B2B and B2C on separate stores, need a plan agreed before the first run. We draw the old hierarchy and the new one side by side, including domains, languages, currencies and catalogues, so there are no surprises.
Remember that for Magento 2 the country, currency and language assignments per sales channel are recreated manually. We also check hreflang between language versions, VAT settings per country and shipping zones, which Shopware rebuilds with the Rule Builder rather than migrating.
Building a 301 redirect plan from Magento URL rewrites
Rankings survive a Magento to Shopware migration when every URL that has traffic or backlinks points to its new equivalent with a 301 redirect. Magento stores its URLs in a rewrite table, which makes a complete inventory possible.
We export all URL rewrites for products, categories and CMS pages, crawl the live shop to catch anything missing, and pull top landing pages from Google Search Console so priorities are clear. Magento URLs often end in .html and include category paths; Shopware 6 builds SEO URLs from templates you configure. We decide whether to keep the old structure through Shopware’s SEO URL templates, which reduces redirects, or move to a cleaner pattern with a full redirect map.
The map is tested on staging before launch: every old URL is requested and checked for a single 301 hop to a live page. After cutover we resubmit sitemaps and watch Search Console daily for 404s. Nobody can guarantee rankings through a migration, and we do not promise them; a tested redirect plan is simply the best protection available. Our relaunch SEO guide has the full method.
- Export the Magento URL rewrite table for all store views
- Crawl the live shop and merge the results
- Prioritise URLs with traffic or backlinks
- Test every redirect on staging for a single 301 hop
- Watch Search Console daily for the first weeks
Replacing Magento extensions with Shopware extensions or plugins
No Magento module runs on Shopware, so each one gets a decision: replace it with a Shopware Store extension, rebuild the logic with the Rule Builder or Flow Builder, write a custom plugin, or retire it.
Common Magento modules for payments, shipping labels, legal texts, newsletter sign-up, search and product feeds usually have maintained Shopware equivalents, often from the same German service providers. Shopware’s documentation notes it has no native newsletter module and leaves that to extensions, while managing newsletter recipients in its own list. Custom Magento modules written for your business, such as special pricing, configurators or ERP connectors, need rewriting as Shopware 6 plugins or apps.
The extension list appears in your quote as a table with one line per module: what it does, the decision, and the cost. Retiring what nobody uses is the cheapest and most useful line in any migration.
Choosing a Shopware edition after leaving Magento
Match the edition to the features you actually used in Magento, not the ones you licensed. According to Shopware’s pricing page, the Community Edition is free and open source under the MIT licence, and the paid Rise, Evolve and Beyond plans are priced on gross merchandise value and other individual factors.
Magento Open Source shops selling mainly to consumers usually land on Community Edition. Adobe Commerce merchants who depended on B2B features should compare Evolve, which Shopware lists with B2B Components, quote management and advanced search, against rebuilding only the features they use. Beyond adds items such as multi-inventory, customer-specific pricing and subscriptions for larger operations.
We present two or three edition scenarios in the quote with the build cost for each, so you can see where a licence saves development and where it does not.
How much does a Magento to Shopware migration cost, and how long does it take?
With BtechWaleTech, a Magento to Shopware migration starts at US$750 and usually takes four to eight weeks; B2B portals, ERP interfaces or heavy custom modules are priced as custom software from US$900. Maintenance starts at US$120/mo after two free months.
Across the market, quotes differ widely, so ask every bidder for the same breakdown: data migration with test runs, attribute clean-up, product types beyond simple and configurable, B2B price rebuilds, password migration, theme and CMS rebuild, extension replacements, redirect map, and post-launch support.
A typical timeline: week one for installation, hosting and the first migration run; weeks two and three for attribute, price and customer-group fixes; weeks three to six for the storefront, Shopping Experiences, shipping and payments; the last one or two weeks for testing, redirects and cutover. Delays usually come from pending decisions on attributes and extensions, not from the migration itself.
Wider budget benchmarks are on website development cost in Germany.
Migrating from Magento with a remote team in India
India is three and a half hours ahead of German summer time and four and a half hours ahead in winter. German mornings overlap with our afternoons, which is when we review data issues with you and agree mapping decisions.
Because Magento and Shopware both run on servers, the whole migration happens remotely: you give us read access to the Magento database and files, we build Shopware 6 on hosting in your name, and you follow progress on a staging shop. A shared tracker lists every attribute decision, extension, data issue and redirect question with an owner.
The first two weeks: a call to walk through your shop and export lists; an itemised USD quote in about two working days; then, after written approval, week one sets up Shopware 6 and runs the first migration, and week two delivers the attribute and extension decision tables. Invoices come from India, payable in USD or EUR by Wise or wire per milestone. NDAs are agreed in writing on request; otherwise our terms apply. Your Steuerberater advises on booking.
Worked example: a hypothetical Magento 2 spare-parts dealer near Stuttgart
This scenario is invented to show the method, not a client story.
Say a spare-parts dealer near Stuttgart runs Magento Open Source 2.4 with about 12,000 simple products, 60 custom attributes built up over eight years, a B2C store and a B2B store with tier prices for three dealer groups, and 22 extensions. The next upgrade needs PHP and search changes, and the owners want to compare that with moving.
We would cost both. For the Magento to Shopware migration, the quote would list the Shopware 6 build from US$750, an attribute clean-up reducing 60 attributes to about 25 properties and a set of custom fields, the two stores as sales channels, tier prices rebuilt as advanced prices for the dealer groups, password migration tested on old and new accounts, 14 extensions replaced from the Store, five retired and three rewritten as plugins, and a redirect map from the URL rewrite table. Timeline: about eight weeks on Community Edition, with a delta migration on a Sunday night.
Magento to Shopware migration checklist
Use this list to prepare your team. The first half belongs before the first migration run; the second half before and just after cutover.
- Full Magento database and file backup, restore tested
- Attribute list cleaned: duplicates merged, unused attributes dropped
- Order statuses, payment methods and tax rates created in Shopware 6 for pre-mapping
- Extension list with a decision per module
- URL rewrites exported and top landing pages identified
- Historical invoices exported and archived
- Password logins tested with old and new sample accounts
- Shipping rules, VAT and currencies checked per sales channel
- German checkout wording, legal pages and withdrawal function tested
- Migration extension left installed after launch for Magento passwords