Migrating away from Shopware to a custom Solidus store

What Shopware is, and who outgrows it

Shopware 6 is a modern, capable commerce platform, and I want to say that plainly before anything else. It is an open commerce platform built on the Symfony framework with a Vue administration, and its core is released under the permissive MIT licence.¹ It is strong across Germany, Austria and Switzerland, its ecosystem understands the legal requirements of German speaking markets, and most agencies there know it well. If you run a conventional catalogue on Shopware and it is doing its job, this article is not an argument to leave. A simple or modestly sized shop is very often right to stay put.

The business I am writing for is the one that has outgrown it. That owner is usually not fleeing a weak platform. They are after something specific: full ownership of the whole stack, a way out of a commercial edition licence tier or the running cost of the extension store, or the wish to build on Ruby on Rails so the shop is an application they control from end to end rather than a product tracking someone else's roadmap. This is the honest guide to that move, from Shopware to a custom store I build on Solidus, the open source Rails commerce framework. I build the store and run the migration, and the result belongs to you.

For the concepts that stay the same whoever you leave, how customer records move, what happens to products and URLs, why saved cards and subscriptions are the hard part, I link the deep guides rather than repeat them. Begin with the pillar, what moves and what does not. This article is about Shopware in particular: its editions, its export and its traps.

What you own, and what sits behind a paid tier

Shopware's structure is the first thing to grasp, because it is where most of the pressure to move comes from. There is one open source core and a ladder of paid plans above it.²

The Community Edition is free, listed at zero, and its core is open source under the MIT licence.²¹ Above it sit three commercial plans: Rise, listed from €600 a month excluding VAT, Evolve from €2,400 a month excluding VAT, and Beyond at a custom price.² The paid plans add features such as returns management, advanced product search, B2B components like quotes and approval workflows, and customer specific pricing, and Shopware states that the pricing is based on your gross merchandise value and further individual factors.² So the printed figures are a floor, not a quote.

There is one condition on the free edition that owners often meet without planning for it. Under Shopware's Fair Usage Policy, a business whose linked shops generate more than €1 million of gross merchandise value over the preceding 365 days must subscribe to Rise, Evolve or Beyond to keep access to the Shopware Account and the Shopware Store.²³ The policy is clear that it leaves the open source licence untouched: the Community Edition stays fully open source under MIT, you keep full access to the source code, and you can carry on running the software independently.³ What a shop above the line loses without a paid plan is the account and the extension store, not the code. That is a fair distinction, and it rewards careful reading rather than either vendor's summary or a rival's.

Then there is the deployment choice, which decides how much of the stack is actually yours. Shopware runs self hosted, on Shopware's platform as a service, or as fully managed software as a service.² The managed cloud starts quickly and Shopware handles updates and infrastructure, but it is, in Shopware's own words, more standardised and offers less flexibility for in depth customisation, while the platform as a service model targets merchants who need individual customisations and their own server infrastructure.⁴ The line that matters for a move is custom code: plugins, which are PHP modifications of the core, run on the self hosted and platform as a service models, not on the managed cloud. If you are on the managed cloud and your growth now needs bespoke logic, you have already reached the ceiling that pushes shops towards owning the application outright.

The export and API reality

This is where Shopware is genuinely good, and I will not pretend otherwise. A move off a self hosted Shopware starts from a strong position, because you have real access to your own data.

The built in Import/Export feature in the admin handles the bulk of a catalogue move. It works in CSV, with the files in UTF-8 and separated by semicolons, and it ships standard profiles you can duplicate and adapt.⁵ The object types it covers are broad: products, variant configuration, categories, customers, orders, media, properties, cross selling, advanced prices, newsletter recipients, promotions and promotion codes.⁵ A profile maps each column in the CSV to a field in the database, which is exactly the mapping exercise any migration is underneath.⁵

Two limits are worth knowing before you lean on it. The import adds information, it does not remove it, so it is a loading tool and not a two way sync.⁵ And the import and export history in the admin shows only the last 30 days of activity, so it is a working tool, not an audit trail.⁵ Neither is a flaw. They are simply the shape of the feature, and a migration plans around them.

For anything the CSV feature does not reach, Shopware exposes two HTTP APIs.⁶ The Admin API, under the /api path, offers CRUD operations for every entity in the system, among them products, orders, customers, media and configuration, authenticated with OAuth client credentials, and it is built for backend integration and data synchronisation.⁶⁷ The Store API, under /store-api, is the customer facing surface, built so that headless frontends such as single page apps or native apps can consume the shop over JSON.⁶⁸ There is also a Sync API for bulk writes.⁶ For a migration the Admin API is the one that counts, because it lets me read out the long tail the CSV profiles do not model cleanly, and verify counts against the source as I go.

On a self hosted Community Edition you also have direct database access, which is the strongest export position of all: nothing is withheld from you, because you hold the database. The managed cloud is the weaker case, where you work through the admin and the APIs rather than the database, so if you are on the cloud, confirm your export route early. Passwords are the one thing that does not travel through any of this as a reusable secret, for the same reason on every platform. I cover why, and what to do about it, in the customer accounts guide. The short version is that customers set a new password once, as a planned step, not a surprise.

The Shopware specific traps

A good export does not mean a clean exit. The traps are in the parts the CSV never touches.

Payments live in handlers and gateways, not in your database. Shopware processes card and local payment methods through payment handlers that talk to a gateway, and the saved cards and tokens behind recurring or one click payments belong to that gateway, not to the shop. Those do not come out in a CSV and they are not yours to copy. Whether they can move at all depends on the gateway, and it is the single hardest question in the whole migration. I set out the honest options, from reconnecting the same gateway to planning for re entry, in the payment tokens guide. Flag this on day one, not in the final week.

Subscriptions are a plugin or a commercial feature. Shopware does not carry recurring billing in the free core, and it comes instead from an extension or sits inside the paid feature set. That means the subscription contracts, their billing dates, their saved mandates and their next charge all live in a specific plugin's tables or a gateway, in a shape unique to that plugin. There is no general export for them. Moving live subscriptions without interrupting a single charge is the most delicate work in any migration, and I treat it as its own project inside the move. The subscriptions guide walks through it.

SEO URLs and the redirect map. Shopware builds its own SEO URLs, and a growing shop has years of links and rankings attached to them. Lose that map at cutover and you lose traffic that looks, on the dashboard, like the new shop performing worse. Every old URL that earned a visit or a link needs a permanent redirect to its new home. That is a spreadsheet with a named owner, and it is the best money you will spend on the project. The mechanics are in the products and catalogue guide, which covers the redirect work because product and category URLs are the bulk of it.

Plugins hold business logic you forgot you depend on. The ecosystem is Shopware's strength and also its lock in. Over a few years a shop accumulates plugins for pricing rules, legal texts, feeds, a point of sale link, an ERP connector, and the exact behaviour of the checkout. None of that is in the catalogue CSV. Each plugin is a small supplier you depend on, and some of them encode rules nobody has written down anywhere else. Before any move I inventory them and decide, for each, whether the behaviour is rebuilt as application code, replaced by a service, or dropped because it is no longer earning its keep.

What the move onto Solidus actually looks like

The honest shape of the move is this: the catalogue and customers come across with mapping work, the orders come across as readable history, and the payments, subscriptions, storefront and integrations are rebuilt. The table is the quickest way to see where each thing sits.

Solidus is where I land this. It is an open source commerce framework on Ruby on Rails, licensed under the three clause BSD licence, and it ships with a REST API, so the shop you own can also feed a mobile app or a second storefront without an upgrade tier.⁹ The honest cost is that there is no theme store and no marketplace of hundreds of plugins, so year one costs more than staying put, and you need a developer who knows Rails. What you get for that is an application with no licence fee, no plan tier that gates your own checkout, and no €1 million line to cross. The checkout, the pricing rules, the subscription logic: each is ordinary application code with tests, not a plugin and a quote. I keep the five year money honest in the total cost of ownership article, and I compare the platforms side by side, Shopware included, in the platform comparison. For the payment methods a shop selling into Germany and Austria cannot do without, invoice after delivery, SEPA, EPS, there is a dedicated guide.

A worked example

Take an invented business: Lee Works Supply (leeworks.example), a Cork trade and retail shop for workwear and site equipment, turning over about €2.8 million a year online. It has run Shopware 6 Community Edition, self hosted, for four years. Three things have converged. Its turnover is now well over the €1 million line, so the Fair Usage Policy means a paid plan to keep the Shopware Account and Store, which it has been quoted well into four figures a month.²³ Its trade side wants per customer price lists and monthly invoices that the current plugin stack handles awkwardly. And the owner wants the shop to share code with an internal stock tool, which a platform roadmap will never prioritise. None of this is Shopware being poor. It is a shop that has outgrown a rented ceiling and wants to own the building.

Here is how I would run it. In discovery I inventory every plugin and decide its fate, agree who owns the data on the shop's side, and settle the payment question first: Lee Works uses one gateway for cards and a separate invoice provider, and the plan is to reconnect the same card gateway to the new shop so saved cards stay put, which I confirm in writing before anything else. The catalogue, variants, customers and three years of order history come out through the Import/Export profiles and the Admin API, and I rerun the import scripts against a copy of the live data until the counts match the Shopware admin exactly.⁵⁷ The storefront, the trade price lists and the invoice logic are built as Solidus application code with executable tests. The redirect map, around three thousand rows, is built from search analytics and checked by a named person at Lee Works. Subscriptions do not apply here, which is why the honest first question saved weeks: the one place they might have hidden was a recurring reorder plugin, and it turned out to be a saved basket, not a billing contract.

Cutover is a Tuesday morning in the shop's quietest month. The old Shopware stays exactly as it is for 30 days as the fallback, and only then does Lee Works stop paying for it. The result is a Rails application Lee Works owns, with no licence tier above it and no account access to lose at the next turnover milestone.

When you should stay on Shopware

I would tell several shops to stay, and I would rather say so now than after you have spent money.

Stay if you are comfortably under the €1 million line, your catalogue is conventional, and the Community Edition plus a handful of plugins does what you need. You are getting a capable platform for no licence fee, and a custom build would be a cost without a matching return.² Stay if your team is productive in the Shopware admin and the only complaint is the subscription you would owe above the fair usage line, and that subscription is bearable. Stay, for now, if you are weeks away from your peak season, because a migration belongs in the quiet months and never before the rush.

Move when the shop is where you compete and the platform has become the thing in your way: when a paid plan tier is buying you features you do not use in order to unlock the one you need, when the plugin stack is holding business logic you would rather own and test, or when you want the Rails engineering model so the shop is one application among your own. That is a real reason, and it is the one I build for.

If you want a second opinion on your own numbers, bring them to a free workshop, and the first two weeks of work are on me. I will tell you honestly whether leaving Shopware pays off for you, and if it does not, I will say so.