Shopware 5 reached end-of-life on July 31, 2024. That was two years ago. If your shop is still running Shopware 5 today, you are not procrastinating anymore. You are operating unsupported production software, and the risk is compounding against you on three fronts at once: security, infrastructure, and the plugin ecosystem your shop depends on.
This post is not a gentle reminder. Two years of gentle reminders have already passed. It is an honest look at what you are actually running, why every month of delay makes the migration harder, and what a realistic path to Shopware 6 looks like based on migrations I have personally delivered.
When Did Shopware 5 Reach End-of-Life?
Shopware 5 reached official end-of-life on July 31, 2024. Per Shopware’s own documentation, what remains is a “reactive security fix” model: Shopware investigates issues customers actively report and ships a bug fix if warranted. Proactive security updates, new features, and active development have all stopped. Every shop still running Shopware 5 is operating unsupported production software.
Is Shopware 5 Still Secure in 2026?
No, not in any meaningful sense. “Secure” is not a binary. It is a function of time: how long has this software gone without a proactive security review, and how many vulnerabilities have been discovered in its dependencies since?
End-of-life means nobody is proactively scanning Shopware 5 for vulnerabilities anymore. Issues only get fixed if a customer reports them. In parallel, the economic incentive has inverted: finding a vulnerability and responsibly disclosing it returns nothing in 2026. Finding one and selling it to a criminal group returns real money. Your shop is the target.
For auditors, the calculation is simpler. PCI DSS Requirement 6.3.3 requires all system components to be protected from known vulnerabilities by applying security patches in a timely manner. Unsupported software cannot satisfy this requirement because no patches are being released for it. Your payment service provider tokenising cards does not move the requirement. If unsupported software sits on any layer that touches the cardholder data environment, the assessor writes a finding. I have seen this flagged during annual reviews and watched agencies scramble to build a three-week migration roadmap to keep the customer’s PCI DSS status active.
GDPR is the quieter risk. Article 32 requires “appropriate technical and organisational measures” to secure personal data, taking the “state of the art” into account. Running software two years past its end-of-life fails on both limbs. If a breach happens, the supervisory authority will ask when you became aware the software was unsupported and what you did about it. “We knew since July 2024 and did nothing” is the worst possible answer.
The productive question for a Shopware 5 merchant in 2026 is not whether to keep the old version on life support. It is how to spend the next six months. Every agency hour poured into extending Shopware 5’s shelf life is an hour not spent on plugin inventory, data cleanup, and integration mapping, which are the line items that actually determine the migration cost. The merchants who come through this cleanly treat the interim months as the migration runway, not as extended life support.
In that interim, harden what you are still running: a WAF rule set in front of the Shopware 5 storefront, admin access locked to an IP allow-list with 2FA enforced at the reverse proxy, log monitoring that alerts on unusual admin activity, regular offsite backups with tested restores, and a documented incident response path. None of this makes Shopware 5 secure. It buys you the months you need to finish the migration without a breach in the gap.
Can Shopware 5 Still Run on Modern PHP?
Shopware 5 runs on PHP 7.4 through 8.2, depending on which 5.x minor you are on. The final Shopware 5 release, 5.7.18 from June 2023, supports up to PHP 8.2. In practice most Shopware 5 shops I audit are pinned to PHP 7.4 or 8.0 because touching the runtime surfaces plugin incompatibilities nobody has the budget to chase down on a dying platform. That is the trap.
Per the PHP project’s own supported versions page: PHP 7.4 reached EOL on 28 November 2022. PHP 8.0 on 26 November 2023. PHP 8.1 on 31 December 2025. PHP 8.2 is on security-only support through 31 December 2026, then it goes EOL too. Even the newest PHP version that the final Shopware 5 release supports is eight months away from losing patches.
This creates a stack where every layer is unsupported. Your shop runs on PHP that no one patches, on top of a Shopware version no one patches, running plugins no one updates. That is not three separate risks. It is one compound risk where any single CVE in any layer can take the whole stack down.
The infrastructure problem compounds in a way most merchants do not see until their hoster sends a deprecation notice. Managed PHP hosting providers are systematically retiring PHP 7.4 support. Some have already dropped it entirely. The ones that still support it charge a premium for legacy PHP runtimes and cap you at specific patch levels. Every quarter, the pool of hosters willing to run your stack shrinks.
A migration I am currently leading started from Shopware 5.3 running on PHP 7.2. Their hosting provider issued a twelve-week notice to upgrade or migrate off the platform. At that point the client had no optional path. The choice was not “Shopware 5 or Shopware 6.” It was “emergency PHP upgrade that breaks parts of Shopware 5 we rely on, or migrate to Shopware 6 under real deadline pressure.” That is the position you do not want to be in.
The Composer constraint layer adds another trap. Shopware 5 pins dependencies to versions that themselves block modern tooling. You cannot upgrade Symfony components, you cannot adopt modern monitoring libraries, you cannot use up-to-date payment SDKs. The constraint graph is frozen in a version of PHP the ecosystem has moved past.
This is the point where “Shopware 5 still works, it has not crashed” stops being a reassuring statement and starts being a warning signal.
What Happens to Third-Party Shopware 5 Plugins?
The plugin ecosystem is where end-of-life hits first and hardest. Shopware 5 plugins are not a single codebase maintained by Shopware AG. They are thousands of independent packages built by agencies, freelancers, and plugin vendors. Most of them stopped shipping updates within a year of the official EOL.
The rot spreads in a predictable sequence:
- Payment providers go first. Klarna, Stripe, PayPal, Adyen, and Mollie all deprecate old SDK versions on a regular cadence. When your Shopware 5 payment plugin depends on an SDK version the PSP stops supporting, payments fail. Not all at once, usually. Specific flows break first: refunds, SEPA mandates, 3D Secure challenge flows. The shop keeps taking orders, but the back office becomes increasingly manual.
- Tax and compliance plugins break next. VAT rate changes, Germany’s mandatory B2B e-invoicing rollout, OSS reporting schema updates. These all require plugin updates you are not getting.
- ERP and PIM connectors rot quietly. SAP, Dynamics, Akeneo, and Pimcore all release new API versions. The Shopware 5 connector you rely on was written against an API that has since changed. Sync jobs start failing in specific edge cases, then more broadly.
- Theme dependencies break silently. Emotion templates built on older jQuery versions or Smarty configurations hit compatibility issues with any modernisation effort.
The part merchants underestimate is that your shop does not have a single “Shopware 5 is broken” moment. It has forty small breakages over eighteen months, each one costing a day of agency time to debug, a week of workaround, and a compounding loss of operational trust in the platform.
I recently audited a Shopware 5 shop where the owner believed everything was fine because sales were stable. The integration layer told a different story: nine of twenty-three third-party plugins had not received updates in over two years, three payment flows required manual intervention weekly, and their ERP sync was running on an undocumented patch a previous freelancer had applied before disappearing. That is not a functioning shop. That is a shop running on goodwill and duct tape.
”We Are Too Far Behind to Migrate” Is the Excuse That Costs You Most
The objection I hear most from Shopware 5 holdouts is some version of: “We are on an old version, we have too much custom code, our data is too complex, it is too late to start.” This is the cope talking.
A migration I am currently leading is from Shopware 5.3 to Shopware 6.7. Five point three is not a recent version. It shipped in July 2017. It is buried under five major versions of change, and it is being migrated to the latest stable Shopware 6 release. The Migration Assistant works. The data maps. The plugins have to be rebuilt, yes, but they would have to be rebuilt from any Shopware 5 starting version, because Shopware 6 is a complete rewrite regardless.
Volume is not the blocker either. Two of my completed Shopware 5 to Shopware 6 migrations moved shops with 25,000+ orders in order history. One of them also carried 12,000+ SKUs across multiple catalogs. Order history migrates cleanly. Customer data migrates cleanly. Product data migrates with the usual caveats around category mapping and custom fields. The number of zeroes in your order table is not what determines whether a migration is possible.
The commercial logic moved in your favour as well. Shopware AG now credits existing Shopware 5 subscription value toward Shopware 6 commercial plans. You are not paying twice during the overlap. Your Shopware 5 subscription keeps delivering what little support remains, while you run the migration, and the cost rolls into the Shopware 6 contract when you cut over.
The only thing that actually blocks migration is the decision to delay it further. Every month you wait, the plugin inventory rots more, the hosting pressure increases, and the engineering time required grows.
What an Honest Shopware 5 to Shopware 6 Migration Actually Looks Like
Most “how to migrate Shopware 5” content online describes a tidy technical sequence. The honest version is messier and more useful. This is the playbook I follow on every migration I lead.
- Plugin inventory is the first day of work. Not the code. The inventory. Every third-party plugin, every custom plugin, every theme override. Classified by: still maintained for Shopware 6, has a Shopware 6 equivalent from a different vendor, must be rebuilt from scratch, can be dropped entirely. This one document determines the bulk of the budget. The rebuild decisions also determine whether your Shopware 6 shop carries Shopware 5 architectural debt forward or starts clean. My Shopware 6 plugin development approach covers the patterns that make rebuilt plugins survive the next decade of updates.
- Data assessment is the second day. Order volume, customer count, product count, custom fields, media library size, CMS content structure. The Shopware Migration Assistant handles the core entities well, but custom field mappings and bespoke database tables need manual definition.
- Integration map is the third day. ERP connections, PIM sync, payment providers, shipping providers, fulfillment, accounting, analytics. Each one is either rebuilt or re-pointed. None of them migrate automatically.
- Staged cutover, not big-bang. I run both systems in parallel during the transition. Shopware 5 continues taking orders while Shopware 6 is built in a staging environment. We cut over piece by piece: catalog first, then customer accounts, then the transactional cutover. I have delivered this approach in a zero downtime platform migration, and the same pattern applies to every Shopware 5 to 6 project I take on.
Timeline expectations matter because merchants arrive with unrealistic ones. A small shop with twenty-five plugins and clean data migrates in two to three months. A medium shop with fifty plugins, an ERP integration, and an international catalog runs four to six months. Anything with custom B2B logic, heavy integration, or large historical data volumes runs six months plus. There is no two-week migration for a real production shop.
Cost drivers are predictable: plugin rebuilds are the biggest single line, data cleanup is the second, integrations are the third, content parity work (CMS, translations, SEO redirect maps) is the fourth. Everything else is small line items. Some plugins are trivial to rewrite. Others, like the custom shipping engine with bin-packing logic I built for one client, become genuine multi-week projects on their own.
Shopware 5 End-of-Life: Frequently Asked Questions
Is Shopware 5 still supported in 2026? No. Shopware 5 reached end-of-life on July 31, 2024. Shopware AG only investigates security issues that customers actively report and ships a bug fix if warranted. There are no proactive updates, no new features, and no active development.
Can I migrate from Shopware 5.3 directly to Shopware 6.7? Yes. I am currently delivering exactly this migration. The Shopware Migration Assistant bridges the gap regardless of which Shopware 5 minor version you are starting from.
Does Shopware 5 end-of-life mean my shop will stop working? Not immediately. It means the software around your shop (PHP versions, payment SDKs, third-party plugins) will fail piece by piece, while the shop itself remains unpatched against new vulnerabilities.
How long does a Shopware 5 to Shopware 6 migration take? Two to three months for small shops, four to six months for mid-sized shops with integrations, six months plus for B2B or large-data shops.
Is it worth migrating a low-volume shop? Yes, if you plan to keep operating at all. The alternative is a forced migration under hosting or compliance pressure, which costs more and gives you less control over timing.
What to Do Next
If you are running Shopware 5 in 2026, the question is no longer whether to migrate. It is how, in what order, and at what cost.
I run paid migration audits specifically for shops in this position. The deliverable is a scoped document: complete plugin inventory with rebuild vs replace decisions, data assessment with migration risk flagged, integration map with reconnection cost estimates, and a phased migration plan with realistic timelines and budget bands. The audit replaces guesswork with a plan your team and your stakeholders can actually work with.
I have delivered Shopware 5 to Shopware 6 migrations at the 25,000+ order scale, and I am currently running a Shopware 5.3 to 6.7 migration that proves no starting point is too far behind. If you want an honest assessment of what your migration actually costs and how to sequence it, let’s talk.
