A B2B store rarely goes down on the day someone installs an update. It goes down on the day someone else decides when the update happens: a published CVE, a host switching off a PHP version, a plugin vendor dropping maintenance. Those dates are already in the calendar. Shopware 6.5 receives security fixes until 28 February 2027, and extended support for 6.6 ends on exactly the same day (Shopware Release Policy). The 6.7 line has been the actively maintained one since 17 June 2025 (Shopware Release Policy), and the next major version, 6.8, is planned for 2027 (Shopware News). None of this calls for a panic upgrade. It calls for operational discipline: planned store maintenance with a window you set yourself — rather than letting a vulnerability set it for you.
The Deadlines Are Already in the Calendar
Under its own release policy, Shopware publishes one major version per year, minor releases every first Monday of the month and patches on demand (Shopware Release Policy). More important than the cadence are the four states a version passes through. Maintained is the latest minor version of the current major cycle — it receives patch updates if necessary. Extended support applies to the last minor version of a superseded cycle: selective bug fixes and security updates. Security fixes only means corrections arrive through a security plugin rather than a regular patch update. End of life means no regular corrections at all (Shopware Release Policy).
The second point has a consequence that maintenance contracts tend to overlook: what is actively maintained is the latest minor version — not the line as a whole. A store sitting on 6.7.4 while 6.7.12 is the current minor is not on an actively maintained version; it is in the security-fix regime (Shopware Release Policy). Choosing 6.7 as a target therefore implicitly means choosing a monthly rhythm. That is precisely the difference between a one-off upgrade project and a continuously maintained Shopware installation.
| Shopware line | Status in July 2026 | Next deadline |
|---|---|---|
| 6.4 | End of life | Security fixes ended on 14 May 2025 (Shopware Release Policy) |
| 6.5 (6.5.8.x) | Security fixes only, via the security plugin | 28 Feb 2027 (Shopware Release Policy) |
| 6.6 (6.6.10.x) | Extended support: selective bug fixes and security updates | 28 Feb 2027, then security fixes until 28 Feb 2028 (Shopware Release Policy) |
| 6.7 (current minor) | Actively maintained, minor release every first Monday | Security horizon of the 6.7 minors: 28 Feb 2028 (Shopware Release Policy) |
| 6.8 | Announced, not yet released | Planned for 2027, moved from 2026 (Shopware News) |
28 February 2027 Is a Double Deadline
Two Clocks Are Running: Shopware and PHP
The Shopware version is only one clock. The second one ticks underneath it, and often faster: PHP. Security support for PHP 8.2 ends on 31 December 2026 (PHP.net, Supported Versions) — roughly two months before security fixes for 6.5 run out. A store on 6.5 with PHP 8.2 loses the platform beneath it before the application above it expires. PHP 8.3 receives security fixes until 31 December 2027, PHP 8.4 until 31 December 2028 and PHP 8.5 until 31 December 2029 (PHP.net, Supported Versions).
According to the update guide, Shopware 6.7 runs on PHP 8.2, 8.3 and 8.4 and additionally requires Node.js 20 or higher, MySQL from 8.0.17 or MariaDB from 10.11; individual database versions are explicitly flagged as problematic, specifically MySQL 8.0.20 and 8.0.21 as well as MariaDB 10.11.5 and 11.0.3 (Shopware Update Guide). Redis from 7.0 is optional (Shopware Update Guide). Put both clocks together and an obvious target combination emerges: 6.7 on PHP 8.4 covers the security horizon of the 6.7 minors through February 2028 without a PHP change halfway through. Such a jump also touches the performance configuration of the store — caching behaviour and opcache settings belong on the checklist.
- PHP 8.2: security fixes until 31 Dec 2026 (PHP.net) — the earliest of the deadlines relevant here
- PHP 8.3: security fixes until 31 Dec 2027 (PHP.net) — carries past 28 Feb 2027
- PHP 8.4: security fixes until 31 Dec 2028 (PHP.net) — covers the 6.7 horizon of 28 Feb 2028
- Shopware 6.7: supports PHP 8.2, 8.3 and 8.4 (Shopware Update Guide)
- Database: MySQL from 8.0.17 or MariaDB from 10.11, with individual versions explicitly flagged as problematic (Shopware Update Guide)
The Earlier Clock Sets the Window
Inventory: What Actually Sits in the Store
Before anyone talks about effort, there has to be an honest inventory. Honest means: not what the documentation says, but what runs on the production system. In grown B2B stores the two diverge regularly, because adjustments were made directly on the system over the years that nobody tracks anymore (project experience). Six things belong on the sheet before a date is named.
Core Version and Patch Level
Not just 6.6 or 6.7, but the exact minor and patch level. It determines whether the store is actively maintained or already running in the security-fix regime.
PHP and Database Version
The specific PHP version of the web server and of the CLI, plus the MySQL or MariaDB version. Both carry their own deadlines, which may fall before the Shopware one.
Plugin Inventory
Every installed extension with version, vendor and compatibility status against the target version — including plugins that are installed but deactivated.
Custom Extensions
The share of self-written plugins drives testing effort more than the number of third-party plugins, because here no vendor takes over the adaptation.
Template Overrides
Overridden Twig blocks and adapted storefront templates are the real cost centre of any major version change — more on that below.
Interfaces and Jobs
ERP sync, price imports, cron jobs, message queue workers and webhooks: everything that runs in the background without a click and can fail silently during an upgrade.
Template overrides deserve their special place. A major version change alters storefront templates and admin architecture; overridden blocks built on old structures have to be reworked one by one. For 6.7 there is an additional factor: the administration moved from Webpack to Vite — which is why plugins with admin components need separate versions for 6.6 and 6.7 (Shopware Update Guide). Add the move to Vue 3 without compatibility mode, the switch from Vuex to Pinia, and a reworked caching layer with delayed invalidation (Shopware Update Guide). For operations this means: a plugin compiled for 6.6 is not yet a 6.7 plugin. How strongly such adaptations shape search and navigation is covered in the article on onsite search with part numbers — search configurations are a classic candidate for silent regressions after an upgrade.
- Read the exact core version including patch level from the production system rather than from the documentation
- Check the PHP version for web server and CLI separately — they diverge more often than expected
- Build a plugin inventory with a compatibility matrix against the target version, deactivated extensions included
- List self-written extensions and their touchpoints with the core
- Count overridden templates and Twig blocks and assess each one
- Document cron jobs, queue workers and interfaces, including the systems at the other end
- Clarify the hosting frame: operating system, database version, Node version, available resources
The Risk Is Not in the Core, It Is in the Extensions
The Shopware core is tested by a vendor with a considerable interest in upgrades working. What the vendor cannot test is what you built around that core. And in a B2B store, that is exactly where the revenue sits. A B2C store loses a cart when a template breaks; a B2B store loses the trust of a purchasing department that compares the price on screen against the framework agreement.
After an upgrade you do not test the homepage. You test the four things that trigger the order in B2B: the right price, the right permission, the right stock, and the way back into the ERP.
The critical areas are the same in every B2B project. The ERP integration transfers orders, customers, stock and documents — when it breaks, accounting notices first, not the store. The price and tier logic decides which customer sees which price at which quantity, and in many installations it is solved through custom extensions. The customer group and permission logic controls who may see prices at all, who may order and who may approve. And the punchout or OCI integration depends on session handling and cart handover — an area a standard test run rarely touches.
- ERP sync: order export, customer and item import, document returns, error and retry logic
- Price logic: customer-specific prices, tiers, discount groups, net and gross display per customer group
- Permission logic: customer groups, roles within the company account, budget and approval limits, assortment visibility
- Punchout and OCI: catalogue entry from the procurement system, cart handover, session behaviour
- Stock and delivery times: availability display per warehouse, delivery time calculation, partial deliveries
- Document processes: order confirmation, invoice, credit note and their number ranges
The Upgrade Path
A dependable upgrade path consists of few but non-negotiable steps. Shopware itself recommends going through Composer rather than the browser updater because it is more stable and avoids timeouts, and it points out explicitly that Shopware does not create backups of its own — operations has to arrange those separately (Shopware Update Guide). Equally recommended: a test environment in which the update is rehearsed beforehand, and a backup even when the test ran smoothly (Shopware Update Guide).
- Staging clone with anonymised live data: a test system with demo data proves little. Only a clone with real data volume, real price structures and real customer groups — with personal data anonymised — reveals migration duration and data problems.
- Dependency update before the core update: first lift plugins and custom extensions to their target-compatible releases, then the core. The other way round you debug two sources of error at once.
- Database migration dry run: run the migrations on the clone and measure how long they take. That number is the lower bound of your production window — and in large catalogues it is the surprise.
- Work through the smoke test catalogue: a fixed set of revenue-critical flows, the same every time. Not clicking by instinct, but a list that still works at three in the morning.
- Rollback plan with a defined fallback time: decide in advance by when the rollback call is made, how long the way back takes, and what happens to orders received during the window.
- Production window and follow-up: run the update in the planned window, then hold a defined observation phase watching error logs, queue length and ERP returns.
The Dry Run Is the Only Serious Estimate
Smoke Test Catalogue: the Ten Revenue-Critical B2B Flows
The catalogue is the heart of the whole discipline, because it detaches sign-off from gut feeling. It is written once, worked through at every upgrade and extended after every incident. The order deliberately is not that of the homepage but that of the money. The following ten flows have proven themselves as a base and can be extended per store (project experience).
- Login with a real company account and switching between several stored delivery addresses
- Item view with a customer-specific price: the price on the detail page matches the framework agreement
- Tier price across a quantity threshold: the step applies in the cart, not only in the display
- Quick order by part number and import of an order list with several line items
- Availability and delivery time for a stocked item and for a drop-shipped item
- Approval process: an order above the budget limit goes into approval instead of straight into the order
- Checkout with purchase on account and a stored credit limit, including order confirmation
- Order export to the ERP: the order arrives complete, including line items, prices and customer reference
- Punchout entry from the procurement system and handover of the cart back
- Document retrieval in the customer account: order confirmation and invoice are available and correctly assigned
Two additions are project-dependent but frequently mandatory. If you offer self-service through a B2B customer portal, test the portal functions separately, because they often sit on custom extensions. And if you export, check the sanctions list screening in the order process after every upgrade — a silently deactivated check is a compliance risk that only surfaces in normal operation once it is too late.
Deployment Windows: Tuesday Morning Is the Peak
In B2C the matter is simple: you deploy while the customers sleep. In B2B the customers sleep at the same time as your own team — and order while both are working. Order activity in business customer stores follows the working hours of purchasing departments and typically peaks in the morning on midweek days, not on a Sunday evening (project experience). That inverts the familiar window logic.
Two uncomfortable consequences follow. First, the quietest window in B2B is often the one in which your own specialists are not working either — precisely when a rollback is hardest to organise. Second, the time until the next working day is the real deadline: a fault created on Friday evening has until Monday morning to be discovered, or not. Anyone who coordinates the window with sales and the e-commerce lead rather than with IT alone gets a more realistic answer.
| Aspect | B2C store | B2B store |
|---|---|---|
| Demand peak | Evenings and weekends | Weekday mornings, often Tuesday and Wednesday (project experience) |
| Quietest window | Weekdays in the early morning | Friday evening to Saturday morning (project experience) |
| Who notices a fault first | Individual customers | Purchasing, field sales and the ERP sync practically at once |
| Consequence of a fault | Abandoned cart | Blocked procurement at the customer, queries into sales |
| Reachability during the window | Support mostly asynchronous | Contacts on the customer side usually reachable on weekdays only |
| Rollback decision | Can wait until the next working day | Has to be made before the next working day begins |
The Window Is a Sales Decision, Not an IT Decision
Plugins Without a Successor: Replace, Rebuild or Drop
The compatibility check before the update knows three answers: already compatible, compatible with the new Shopware version, or not compatible — the latter meaning there is no successor version for that extension (Shopware Update Guide). The third answer is the only one that forces a decision, and it shows up more often at a major version change than at a minor update, because shifts such as the move from Webpack to Vite require separate plugin versions for 6.6 and 6.7 (Shopware Update Guide). Three routes are open, and each has a price.
Replace
Substitute the function with a maintained alternative or with built-in features. Cheap when the scope is comparable — expensive when data structures have to be migrated and editors have to relearn.
Rebuild
Reimplement the function as your own extension. Sensible when it is business-critical and the scope is small. From that moment on, its upkeep permanently belongs in your budget.
Drop
Remove the function without replacement. The least popular and often the right option — especially when an honest usage review shows the function is barely used.
The decision should be made before the upgrade window is set, not inside it. What works in practice is confronting every plugin without a successor with two questions: which revenue process breaks without this function, and how often was it actually used in the past twelve months? A surprising number of extensions do not survive the second question (project experience). What remains moves into a cleanly maintained set of custom extensions — and thereby into the hands of those who also own the ongoing Shopware development.
Maintenance as a Running Cost Instead of an Emergency Invoice
The economic core of the topic is unspectacular: maintenance costs money whether you plan it or not. The difference is who sets the date. For the reporting period July 2024 to June 2025, the German Federal Office for Information Security counted an average of 119 new vulnerabilities per day, around 24 percent more than in the previous period (BSI). Vulnerabilities of medium and high severity rose by about 20 percent, while critical ones remained nearly unchanged at minus 2 percent (BSI). At the same time, observed exploitation of vulnerabilities rose by 38 percent (BSI), and around 80 percent of reported attacks targeted small and medium-sized enterprises (BSI).
In its conclusion the BSI also names the cause: known vulnerabilities in exposed systems are patched late or not at all, and timely updates are among the levers that lower the risk directly (BSI). An online store is by definition an exposed system. Moving maintenance into a running cost line does not buy security in any absolute sense, but it shifts the probabilities markedly in your favour — and it trades an incalculable emergency invoice for a predictable monthly item. Which regulatory requirements may apply on top is set out in the article on IT security and NIS2 in the B2B store.
- Monthly minor cadence: Shopware ships minors every first Monday (Shopware Release Policy) — only the latest one is actively maintained
- Fixed maintenance slot: a recurring window agreed with sales instead of dates set on demand
- A maintained smoke test catalogue: grows with every incident and makes sign-off repeatable
- Staging as a permanent state: not an environment built once the project starts, but one that already exists
- Plugin portfolio upkeep: an annual review for extensions without a successor, before the deadline bites
- Stack calendar: end dates for Shopware, PHP, database and operating system in one place, with the earliest date setting the pace
That is precisely our definition of store maintenance and support: not a ticket system waiting for incidents, but an operating model with dates, catalogues and a way back. If you want to know where your store stands relative to 28 February 2027, the inventory is the first step — it costs a few days and answers the question of whether you are planning a maintenance window or setting up a project. How the individual pieces work together is shown in the overview of our services for B2B stores.
Sources and Studies