Shopware 5 in 2021: patch it, extend it, or plan the exit?
Shopware 6 exists and is getting better every release. That is not a reason to move a profitable Shopware 5 shop this year. Here are the three honest paths, what each one costs, and how to tell which one you are actually on.
Photo: free stock photography (Unsplash licence) — see imprint
A profitable Shopware 5 shop is not a problem waiting to be solved
Every agency call this year opens the same way: 'we are still on Shopware 5, how bad is it?' The honest answer is usually 'not bad at all, and please stop letting people make you feel behind'. Shopware 5 is a mature system that ships orders every day, and your customers have never once asked which major version renders the cart. The pressure to move is coming from the industry, not from your P&L.
What is true is that the clock runs in one direction. Shopware 6 is where the new work goes, the plugin market slowly follows the platform, and the PHP version under your shop has an end-of-life date that was set by people who have never heard of your business. None of that is an emergency in 2021. All of it is a reason to make a deliberate decision this year instead of drifting into someone else's deadline in three years.
Path one: patch it, take the money, change nothing
This is the path nobody sells you, which is exactly why it deserves to go first. You keep the shop on a current 5.x line, you apply security patches, you keep the plugins you have, and you spend your development budget on marketing, product data and logistics instead. The shop stops being a project and becomes what it should have been all along: infrastructure.
The cost of this path is small and predictable — a maintenance retainer, a few days a year, an occasional plugin update that breaks something in the checkout. The cost you are not seeing is optionality: every month you stay, the eventual migration gets slightly larger, because you keep adding products, categories, URLs and small customisations to the thing you will one day have to lift. That is fine as long as you are honest that it is happening.
Path two: extend it — but only where the money is
Plenty of shops still need real work done in 2021: a proper B2B pricing model, an ERP connection that stops the manual CSV ritual, a checkout that does not lose people at the shipping step. Doing that work in Shopware 5 is perfectly rational. The developers exist, the codebase is well understood, and a feature that earns money in six weeks beats the same feature that earns money in nine months after a migration.
The rule we use is simple: extend Shopware 5 where the value is in the business logic, not in the platform. An ERP interface, an import pipeline, a pricing engine — those are yours, they encode how your company actually works, and most of that thinking survives a migration even if the code does not. A deep custom theme, a rebuilt frontend, a bespoke checkout flow — those are platform-shaped, they will be thrown away, and every euro spent there is a euro you burn twice.
Path three: plan the exit before someone else plans it for you
The worst migrations we see are the ones that started as emergencies. A payment provider drops support for the old plugin, or a security advisory lands on a PHP version nobody wants to touch, and suddenly a six-figure project has to be scoped, sold internally and delivered in one quarter. That project always ships late, always ships thin, and always launches with the same revenue it had the day before — because a migration is not a growth initiative, it is a platform change wearing a business case.
Planning the exit does not mean starting it. It means writing down, on one page, what your shop actually consists of: which plugins are load-bearing, which customisations exist and why, which integrations would have to be rebuilt, and which of your 12,000 URLs earn traffic worth keeping. That page takes a few days and costs almost nothing. It is also the single thing that turns a panicked rewrite into a scheduled one, and it does not commit you to a date.
The signals that actually decide it
Version numbers do not decide this. Your roadmap does. If everything you want to build in the next two years is a variation on what the shop already does, stay and stop paying for the debate. If your plans require things Shopware 5 was never shaped for — a second sales channel on the same catalogue, an API-first integration, a content layer your marketing team can touch without a developer — then you are not choosing between versions, you are choosing between having those things and not having them.
- Your plugin vendors are quietly stopping SW5 releases — a real signal, check it yearly.
- You cannot hire anyone who wants to work on it — a slow, expensive signal.
- Every small change costs three days because nobody dares touch the theme.
- Your roadmap needs a second channel or an API-first integration — SW5 will fight you.
- Growth is flat and the shop is not the reason — then a migration fixes nothing.
| Path | Typical yearly cost | Right when | Wrong when |
|---|---|---|---|
| Patch and hold | A small retainer, a few days a year | Shop is profitable and the roadmap is boring | Plugins or PHP are already forcing your hand |
| Extend business logic | Scoped per feature, earns back in months | The gap is ERP, pricing, imports, B2B rules | The work is theme-deep and will be thrown away |
| Plan the exit (paper only) | A few days of inventory work | Always — it commits you to nothing | Never; the paper is the cheap part |
| Migrate now | A project with a project's bill | The roadmap genuinely needs what SW6 is | The reason is that 5 sounds older than 6 |
- A profitable, stable Shopware 5 shop does not have to move in 2021 — say that out loud.
- Extend the business logic, never the theme: one survives the migration, the other is paid for twice.
- Write the exit plan now and start it later — the plan is what makes it scheduled instead of panicked.
- Your roadmap decides the version, not the version number.
Frequently asked questions
No. If your shop is profitable, patched and does what your roadmap needs, staying is a legitimate decision and not a failure of nerve. What you should do this year is the cheap part: write down what the shop consists of, which plugins are load-bearing, and which vendors are still shipping updates. That page is what lets you choose your own date later instead of inheriting one.
It depends entirely on where the feature lives. An ERP connection, an import pipeline or a B2B pricing model encodes how your company works — the thinking behind it survives a migration even though the code will not, and it earns money in the meantime. A deep custom theme or a bespoke checkout is platform-shaped and gets deleted on migration day. Spend on the first kind, be very disciplined about the second.
Watch three things, not the version number. First: are the plugins you depend on still getting releases? Second: can you still find someone willing to work on the code at a sane rate? Third: how long does a small change take — if a text edit costs three days because nobody dares touch the theme, you are already paying for the migration without getting it.
On launch day, no — expect the same revenue you had the week before, and budget for a small dip while rankings and habits settle. A migration buys you capability: a platform your roadmap can grow into, an API you can build against, a frontend a marketer can touch. If nobody can name a specific thing that capability unlocks, the project has no business case yet.
We do this for a living — Shopware, Node.js, React, ERP integration and automation for B2B.
Talk to an engineer