Shopware 5 at the end: an honest roadmap for whoever is still on it
We used to argue that a profitable SW5 shop could stay. That argument has run out — not because the framework got worse, but because everything around it moved on. What unsupported really costs, and how a very late mover should plan.
Photo: free stock photography (Unsplash licence) — see imprint
The argument for staying has expired — the framework did not change, the world did
For years we told clients the same thing, and we meant it: a profitable, stable SW5 shop does not have to move this year. A migration is a six-figure project that produces no new revenue on launch day, and spending that money to end up where you already are is a bad trade while the old install is quietly earning. That advice was right when the only thing wrong with SW5 was that something newer existed.
That is no longer the situation. The code on your server is exactly as good as it was — it still takes orders, it still prints invoices, your team still knows every corner of it. What changed is everything it depends on: the PHP it runs under, the payment plugins it talks to, the security expectations of the people who insure and audit you. You are not being punished for a bad platform. You are running a fine platform in a world that has stopped shipping parts for it.
Unsupported does not mean broken — it means alone
Nothing switches off. That is the misunderstanding that keeps late movers calm for one year too many. An unsupported shop runs happily until the day something outside it changes, and then there is nobody to ship the fix. A payment provider adjusts an API, your hoster retires a PHP version, a vulnerability turns up in a library — each of those is a normal Tuesday for a maintained shop and an emergency for yours.
The practical cost shows up as an asymmetry. Every small external change becomes a project, because the fix has to be written by you instead of installed by you. We have watched clients pay more for one weekend of emergency patching by a developer who had to relearn a decade-old codebase than a year of maintenance would have cost. That is the real bill for staying, and it does not appear in any budget until it does.
The people who force your hand are not Shopware
Late movers wait for an announcement. The announcement is not what moves them — a third party is. Your payment service provider changes a flow and the old plugin stops settling. Your hoster stops offering the PHP version your install needs, and the next one it offers makes SW5 throw fatal errors on paths you have not touched since 2016. Your card processor asks about your patch level and does not accept 'it is stable' as an answer. Your insurer asks the same question in different words, in a form, with consequences.
None of these arrive on a date you can plan around, and all of them arrive with a deadline attached. That is the actual difference between moving now and moving later: not the cost, which is similar, but who picks the date. A migration you schedule takes nine months of ordinary work. A migration your PSP schedules takes nine months of ordinary work compressed into whatever time they gave you, at emergency rates, with the shop half-broken in the middle.
- Payment: plugins for an unsupported version stop being maintained before the shop does.
- Hosting: the PHP version you need eventually leaves the supported list of every serious host.
- Card data: 'unpatched and unsupported' is an uncomfortable line in any PCI conversation.
- Cyber insurance: policies increasingly ask what you run and what you patch — in writing.
- Your own people: nobody wants to inherit a decade-old install as their first project.
A staged plan for a shop that has run the same install for a decade
Do not start with the migration. Start with a quarter of unglamorous work that is worth doing even if you never move: find out what you actually run. Which plugins are load-bearing, which are dead code nobody dared delete, which customisations exist only in a template file somebody edited in 2017. A ten-year-old install always contains features the business no longer uses and the business is always surprised by the list. That inventory is what makes the real quote honest instead of a guess with a large buffer.
Then split the move rather than swallowing it. Stabilise first: get the current install onto the newest PHP and the newest patch level it will tolerate, so that the thing you are migrating from is not also on fire. Build the new shop in parallel with the reduced scope the inventory gave you, run both for a period with the old one still taking money, and cut over once. The one sequence that reliably fails is the big-bang rewrite that also redesigns the frontend, changes the ERP interface and adds a new PIM, because then nobody can tell which of the four projects broke the checkout.
If you are going to be late anyway, be late deliberately
There is still an honest case for waiting — but it is narrower than it was, and it has conditions. If your shop is a low-traffic catalogue with an external payment page, no card data anywhere near your server, and a business that may not exist in this form in three years, then buying eighteen more months from an old install is a defensible commercial decision. Just make it a decision rather than a drift. Write down what would force your hand, who is watching for it, and what the plan is when it happens.
| Stage | What you do | Worth it even if you never migrate? |
|---|---|---|
| Inventory | List every plugin, customisation and dead feature | Yes — it is the only honest basis for any quote |
| Stabilise | Newest PHP and patch level the install tolerates | Yes — buys time and removes the loudest risk |
| Reduce scope | Delete what the business stopped using years ago | Yes — less code is cheaper to run and to move |
| Build in parallel | New shop next to the old one, old one still selling | No — this is the migration |
| Cut over once | One date, one scope, no redesign bolted on | No — but it is where late movers save themselves |
- Shopware 5 did not get worse; the PHP, payment and security world around it moved without it.
- Unsupported means every small external change becomes your project instead of your update.
- The difference between now and later is not the cost — it is who picks the date.
- A ten-year-old install is mostly features nobody uses; find them before you pay to move them.
Frequently asked questions
No, and that is exactly the danger. Nothing switches off — the shop keeps selling, which makes it easy to keep postponing. What ends is the supply of fixes. The shop breaks later, at a moment chosen by a payment provider, a hoster or an attacker, and by then you are fixing it under a deadline you did not set.
For a decade-old install with real customisations, plan six to twelve months from inventory to cut-over, and expect most of that time to go on data, plugin replacements and the integrations nobody documented — not on the shop itself. If someone quotes you three months without having looked at your plugin list, they are quoting a different shop than yours.
Technically yes, and a few shops with strong in-house teams do it competently. Be honest about what it means: you have adopted a framework as your own product, including its dependencies, and you now need someone who reads security advisories for libraries you did not write. That is a standing cost forever, for a platform you will still leave eventually. It buys time, not a destination.
Yes, but the list is short: low traffic, no card data on your infrastructure, payment handled entirely on the provider's page, and a business whose future is genuinely uncertain. In that case buying another year is a fair commercial call. Everyone else is not saving money by waiting — they are moving the cost to a quarter where they will have less control over it.
We do this for a living — Shopware, Node.js, React, ERP integration and automation for B2B.
Talk to an engineer