Magento 1 to Shopware 6: The One Migration Where the Platform Choice Is Open

Every replatforming conversation starts with the same unspoken math: how much of what we already paid for comes with us? It is the reason most Magento 2 stores stay on Magento even when they are frustrated with it. The theme works. The extensions work. The integrations took three years to get right. Moving means paying for all of it again.

From Magento 1, that math does not exist.

Magento 2 is a separate application that shares a name with Magento 1 — different codebase, different module architecture, different theming system, different database schema. Adobe's own tooling admits it by being called the Data Migration Tool rather than an upgrade command. So your theme does not come with you to Magento 2. Your extensions do not. Your custom modules do not.

Which means that for exactly one group of merchants — the ones still on Magento 1 — the platform decision is genuinely open. You are rebuilding no matter what you choose. The only question is what you rebuild on.

Where Magento 1 leaves you

Briefly, because we have written this up in full and you have probably heard it: Magento 1 reached end of support on June 30, 2020. No official security patches have shipped since. Magento is heavily scanned, card-skimmer campaigns against Magento 1 have been running for years, and the population of unpatched stores is well known to the people running them.

The argument that actually moves a decision is usually compliance rather than fear. PCI DSS requires critical patches within a defined window, and when no patches are issued the requirement is not merely unmet — it cannot be satisfied in principle.

There is one honest middle path. OpenMage LTS runs Magento 1 on PHP 8 and backports security fixes to the codebase you already have. As a way to buy two or three years to plan a migration properly, it is defensible. As a permanent answer for a business whose requirements are still growing, it compounds the problem.

What actually carries over, to either destination

This is the table nobody puts in front of you, and it is the one that should drive the decision:

The top six rows are identical. That is the point. The cost difference between these two projects is not in the migration — it is in the two rows at the bottom, and in how well your catalog fits each platform's product model.

What the Magento profile covers

Shopware publishes a free Migration Assistant, and a separate Magento profile plugin adds Magento 1.9.x and 2.x support to it. Both are needed; the profile does not work alone. The plugin tracks Shopware's own release line, so check the version matrix against the Shopware release you are targeting before you build a plan around it.

It reads your Magento database directly and moves the structured entities: products, categories, customers, orders, media, and the attributes behind them. That is real work you do not have to write.

What it does not touch is the same list as for any Magento-to-Shopware move, and we covered the mechanics in detail in Magento to Shopware 6 — particularly the variant model, which is where the schedule goes on a large catalog. Magento models configurable products as a parent plus child simples; Shopware generates variant combinations from property groups. Those are not the same shape, and converting between them is a series of explicit decisions rather than a mapping.

Everything in that post applies here. The rest of this one is what is different about coming from Magento 1 specifically.

The extension estate is the argument nobody makes out loud

Magento 1 has been unsupported for six years. Look honestly at what is in app/code/local and app/code/community and ask, for each one, whether the vendor still exists, still sells it, and has shipped anything since 2020.

For most stores the answer is no on the majority of the list. Which means:

• You are not comparing "keep my extensions" against "replace my extensions." You are replacing them either way.
• Several of those extensions encode business rules nobody documented, and the person who understood them has moved on. That archaeology is a fixed cost that lands on both projects equally.
• A handful will turn out to be doing something you no longer need at all, because the business changed and the module stayed. Finding those is the one genuinely good part of this project.

That last point is worth taking seriously. Merchants routinely rebuild on a new platform with a third fewer moving parts than they had, and the reduction comes from this audit rather than from anything the platform did.

The M1-specific problems

URL structure, and the .html suffix. Magento 1 ships with a .html suffix on product and category URLs by default, and a great many stores never changed it. Every one of those is an indexed URL that has to redirect to something. Shopware does not generate URLs that way, so this is not a settings change you can mirror — it is an explicit map, produced before cutover, from your sitemap, Search Console, and server logs. Anything in that export without a target is a decision you have not made yet.

Layered navigation URLs are the second half of the same problem. Magento 1 generates a large surface of filtered category URLs, some of which have picked up links and rankings over a decade. Decide deliberately which of those get targets and which get consolidated — but decide, rather than discovering the answer in your analytics a month later.

Customer passwords. Magento 1 and Shopware hash passwords differently and the stored hashes are not portable. Plan a forced reset with an email that explains why, and schedule it away from your peak weeks. This is a communications task more than an engineering one, and treating it as engineering is how it goes badly.

Order history as records, not live objects. Your migrated orders arrive as historical data. Reorder flows, RMA state, subscription state, and anything your customer service team clicks on in a live order will not behave the way it did. Work out early which of those your team actually uses daily, because the answer determines how much post-migration tooling you need.

A decade of catalog drift. Magento 1 stores that have been running since 2012 tend to carry attribute sets nobody can explain, attributes used on nine products, and product types chosen for reasons lost to history. The Migration Assistant will faithfully carry all of it across. Clean it in Magento 1 first, or at minimum decide what not to migrate — this is far cheaper before the move than after.

When Magento 2 is still the better answer

We work on both platforms, and this is not a post arguing for Shopware.

Magento 2 fits better if you have a very large catalog with complex attribute structures, real B2B requirements around company accounts, tiered pricing, and quoting, ERP integration built up over years against Magento's data model, or a team and agency relationship already deep in the Magento ecosystem. It also fits better if you are in the US and want the widest possible pool of developers and integrations to hire from.

Shopware fits better if you are in Europe or selling primarily into it, if you want a modern API-first core with a strong out-of-box content and merchandising story, or if your requirements are genuinely simpler than the Magento build you accumulated and you would rather not carry that weight again.

The version of this project that goes wrong is the one where a merchant picks a platform to escape frustration rather than to fit a requirement. From Magento 1 the frustration is real and entirely justified — but it is caused by running six-year-old unsupported software, and both destinations fix that equally.

What we would do

Spend a week on the audit before you spend a month on the decision. Three things, in this order:

1. Export every indexed URL from your sitemap and Search Console. The size of that file is the size of your SEO project, and it is the same number on both platforms.
2. List every extension and custom module, with a live/dead verdict on the vendor next to each one. This is the honest scope of the rebuild.
3. Look at your five worst catalog problems — the attribute set nobody understands, the configurables with hand-priced children — and check how each one maps into both product models. If one platform makes three of the five go away, that is a real signal.

Then choose. Whichever way it goes, the build itself is Shopware 6 development or Magento 2 development work, and the migration tooling is a helpful accelerator at the start of it rather than the project itself.

If you are going the other direction, or comparing against staying put, we have written up Shopware to Magento and why some stores should stay on Magento as well.

Emyrix works on both Magento and Shopware, and will say plainly when a replatform is not the answer. If you are on Magento 1 and want the audit above turned into a scoped comparison, get in touch.

Migration Assistant coverage and profile compatibility change between releases. Verify both against Shopware's current documentation before scoping around them, and check Adobe's lifecycle policy for Magento support dates.