Shopware 5 reached end-of-life on July 31, 2024. That was 2 years ago. If your shop is still running Shopware 5 today, you’re 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.
Two years of gentle reminders have already passed. This is the honest version: what you’re 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’ve 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. Security 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. Meanwhile, 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.
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 can’t satisfy that requirement, because no patches are being released. Your payment service provider tokenising cards doesn’t move the requirement either. If unsupported software sits on any layer that touches the cardholder data environment, the assessor writes a finding. I’ve seen this flagged during annual reviews, with agencies scrambling 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 how to spend the next 6 months. Every agency hour spent 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 determine the migration cost. Merchants who come through this cleanly treat the interim months as the migration runway.
In that interim, harden what you’re 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’re on. The final Shopware 5 release 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’s the trap.
Per the PHP project’s 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 months away from losing patches.
Every layer of the stack 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. Each one amplifies the others. A single CVE in any layer can take the whole stack down.
The infrastructure problem compounds in a way most merchants don’t 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 still supporting 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’m currently leading started from Shopware 5.3 running on PHP 7.2. Their hosting provider issued a 12-week notice to upgrade or migrate off the platform. At that point the client had no good path. The choice became: emergency PHP upgrade that breaks parts of Shopware 5 they rely on, or migrate to Shopware 6 under real deadline pressure. That’s the position you don’t want to be in.
The Composer constraint layer adds another trap. Shopware 5 pins dependencies to versions that themselves block modern tooling. You can’t upgrade Symfony components, can’t adopt modern monitoring libraries, can’t 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 hasn’t 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 thousands of independent packages built by agencies, freelancers, and plugin vendors, with no single team maintaining them. Most 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 aren’t 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 how this looks in real life. Your shop accumulates 40 small breakages over 18 months instead of one big “Shopware 5 is broken” moment. Each breakage costs 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. 9 of 23 third-party plugins hadn’t received updates in over 2 years, 3 payment flows required manual intervention weekly, and their ERP sync was running on an undocumented patch a previous freelancer had applied before disappearing. The shop was running on goodwill and duct tape.
”We’re 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’re on an old version, we have too much custom code, our data is too complex, it’s too late to start.” This is the cope talking.
A migration I’m currently leading is from Shopware 5.3 to Shopware 6.7. 5.3 shipped years before the current Shopware 6 architecture even existed. It’s buried under five major versions of change, and it’s being migrated to the latest stable Shopware 6 release. The Migration Assistant works. The data maps. The plugins have to be rebuilt, but that holds true for any Shopware 5 starting version, because Shopware 6 is a complete rewrite.
Volume isn’t 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 doesn’t determine 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 aren’t 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 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. Real migrations are messier and the playbook is more useful in detail. This is what I follow on every migration I lead.
Plugin inventory is the first day of work. 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. 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 rebuilt or re-pointed. None of them migrate automatically.
Staged cutover. I run both systems in parallel during the transition. Shopware 5 keeps taking orders while Shopware 6 is built in a staging environment. The cutover happens piece by piece: catalog first, then customer accounts, then the transactional cutover. I’ve 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 25 plugins and clean data migrates in 2 to 3 months. A medium shop with 50 plugins, an ERP integration, and an international catalog runs 4 to 6 months. Anything with custom B2B logic, heavy integration, or large historical data volumes runs 6 months plus. There’s 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.
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’m currently delivering exactly this migration. The Shopware Migration Assistant bridges the gap regardless of which Shopware 5 minor version you’re starting from.
Does Shopware 5 end-of-life mean my shop will stop working? Not immediately. 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? 2 to 3 months for small shops, 4 to 6 months for mid-sized shops with integrations, 6 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’re running Shopware 5 in 2026, the question is how to migrate, 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’ve delivered Shopware 5 to Shopware 6 migrations at the 25,000+ order scale, and I’m 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, get in touch.
