Shopware 5 to 6: what a run of real migrations actually taught us

The estimate is always wrong in the same direction

We have now taken a decent number of shops from Shopware 5 to Shopware 6, and the pattern is embarrassingly consistent: the data migration lands roughly where we quoted it, and everything around the data takes two to three times longer than anyone wanted to hear. Products, categories, customers and orders move across with the migration tooling and a few days of cleanup. Then the project meets the fifty small things that made the old shop actually work, and those are not in any tool.

In most of them the underestimate was not technical incompetence. It was that nobody — not the client, not us — had a complete list of what the old shop did. A shop that has been live for six years has accumulated behaviour the way a house accumulates cables: a discount rule someone added for one trade fair, an export that finance quietly depends on every month, a redirect table from a relaunch two owners ago. You cannot quote what you have not inventoried, and the inventory is the part everybody wants to skip because it produces nothing visible.

The plugin inventory is not a step in the project. It is the project.

Every migration we have done was, underneath the label, a plugin problem wearing a data-migration costume. A typical SW5 shop runs somewhere between twenty and sixty plugins. Some have a SW6 successor with the same name and different behaviour. Some have a successor from a different vendor. Some are simply gone, because the developer looked at the rewrite cost and decided not to. And a few are yours — bespoke work from years ago whose author has left the building.

The lesson we learned the hard way is to do this inventory before the offer, not after the kickoff, and to force a decision per plugin: replace, rebuild, buy, or drop. Drop is a real option and the cheapest one, and it is the option nobody offers the client. In most projects a meaningful share of plugins were being paid for and not used — installed for a campaign in 2018, never removed, still in the backup, still in the estimate. Killing them is the highest-return hour in the whole migration.

• Replace — a real SW6 equivalent exists and the behaviour is close enough.
• Rebuild — the function is business-critical and nothing on the market fits.
• Drop — nobody has used it in two years and nobody will miss it.
• Defer — useful, not needed on day one, cheaper once the shop is stable.

Nobody budgets for the template, and the template is a rewrite

Clients hear 'migration' and picture the same shop on newer foundations. Then they see that the SW5 theme does not come along in any form. Smarty templates do not become Twig by being copied. The old theme's structure, its blocks, its dozen small overrides accumulated across years — all of that is a rewrite, and it is a rewrite that produces, on a good day, a shop that looks exactly like the one you already had.

This is where we now argue hardest, and where we lose money by being honest. If you are rewriting the front end anyway, rebuilding a pixel copy of a six-year-old theme is the single worst use of that budget. Take the standard SW6 theme, accept that some things will look different, and spend the difference on the checkout and the product page. The clients who insisted on the pixel copy got the pixel copy, on time, and got no benefit from it whatsoever.

The launch day produces no new revenue, and that surprises people

This is the hardest conversation and we have got better at having it early. A migration is a five- or six-figure project whose deliverable, on the morning it goes live, is the same business you had the night before. Same products, same customers, same margin. If anything, revenue dips for a few weeks while rankings settle, staff relearn the admin, and the first crop of bugs surfaces. The value is real but it is deferred: you are buying the ability to change things in year two through five.

Which is why a profitable, stable SW5 shop with no pending change requests does not have to move this year. We say that out loud in sales meetings and it costs us projects. But the migrations that went badly were almost all the ones where nobody could name a business reason beyond the version number — and a project without a business reason has nothing to arbitrate scope against when the plugin surprises arrive in week seven.

What we changed in how we run these

Three things. We now run the data migration once in week one, not in month four — badly, into a throwaway environment, purely to find out what breaks. It always breaks somewhere unglamorous: a custom field with no SW6 counterpart, an attribute table someone wrote by hand, orders with a payment method that no longer exists. Finding that in week one is cheap. Finding it two weeks before go-live is a schedule.

Second: we insist on a written URL map before anything else, because the SEO damage from a botched migration outlives every other mistake in the project. Third: we plan for four weeks of stabilisation after go-live and put it in the offer as a line item, because it happens whether it is in the offer or not. The only question is whether it happens as planned work or as an argument.

Frequently asked questions