Shopware maintenance
At Sharpness Solutions GmbH in Oldenburg, Shopware maintenance means this: someone reads your shop's logs before you call. Patch releases of the current 6.7 line are tested on a staging copy and then deployed — the current state of the line is 6.7.13.0 of 5 August 2026. The plugin landscape is tracked against every version, and the database, caches, message queue and search index are all under observation. This becomes binding through a service level agreement with a response time of 24, 8, 4 or 2 hours, charged as a monthly flat fee net per shop. We also take over shops built by someone else — after we have looked at the code and the hosting, not before. Last updated: 17 August 2026.
Enquiries about Shopware maintenance rarely start with an outage. They start when someone does the arithmetic: the last update was eighteen months ago, nobody in the company knows the Composer file any more, and the nightly ERP import is running — probably. All the while, the shop keeps selling. That is exactly the problem: a shop does not report that it is unmaintained. It reports when the checkout breaks, and by then the cause is months old. These four points cover most of what shop operators bring to us.
Under var/log/ there are errors that nobody looks at: failed payment callbacks, aborted imports, messages that ended up in the dead letter store of the message queue, scheduled tasks that have not run since a deployment. The shop looks fine because the home page loads. An error that nobody reads is still there — it is only waiting for the customer to find it.
Without a staging system and without a documented rollback, every update is a jump without a safety net, so it gets postponed. The gap to the current version grows, and with it the number of work steps an update has to catch up on: Composer conflicts, plugins without a matching version, a PHP version that is no longer sufficient. At some point a maintenance window turns into a project with a quotation and a budget approval.
Twenty extensions in the shop, and for half of them nobody knows whether they are still in use, who maintains them and what they were once bought for. With Shopware 6.7 this question can no longer be postponed: Vue 3 instead of Vue 2, Vite instead of Webpack, Pinia instead of Vuex — every plugin and every custom theme needs an adjustment for this. Anyone who maintains an extension for both 6.6 and 6.7 needs separate releases.
As long as nothing happens, nobody notices. On the day the checkout stops working, it is the only relevant question. Without an agreement, our default applies: processing in order of receipt within 48 hours during business hours, Monday to Friday 9:00 to 16:00 — honest, but too slow for a shop with an ongoing order volume. That is exactly what the service level tiers further down are for.
Shopware maintenance consists of four kinds of work that have little to do with each other technically. The first is security and bugfix releases within the current line: check whether the installation is affected, install it on staging, go through the back end, the checkout, the payment methods, mail delivery and order documents, then deploy. Not on release day and not blindly — an x.x.x.0 release does not go straight into live operation with us, because Shopware has withdrawn individual releases after publishing them. The most recent case was 6.7.12.0 of 7 July 2026, which could not be installed because of an incompatibility with Twig 3.28 and was replaced by 6.7.12.1. We wait for a reliable patch level and then catch up, instead of skipping a version and letting the gap grow. We run updates from the command line, not through the graphical updater, because that is the only way to keep a clear record of what happened.
The second kind of work is plugin compatibility, and it is the most thankless. Every update raises the question of which extension has a matching version, which one still has a maintainer and which one sits in the shop without being used. Store plugins, purchased extensions and your own code have three different life cycles here. We keep the Composer state clean instead of pinning versions until nothing can be resolved any more, and we keep a list that says: this extension is maintained, this one will be replaced at the next major version, this one will be uninstalled. We build our own plugins against the extension points of Shopware, not into the core — core hacks are the most common reason why a shop falls several versions behind.
The third kind of work is the underlying stack, the fourth is watching. The stack includes the PHP and database version, the object cache in Redis or Valkey, the HTTP cache, the search index, the message queue, cron jobs, certificates, the deployment path and backups with a restore test that has actually been carried out. A backup that has never been restored is an assumption. Watching includes the logs, the backlog in the queue, the run time of the nightly import, the error rate in the checkout and the growth of the tables that quietly get bigger. We also read the deprecation messages, because they announce the breaking points of the next major version while there is still time. At the end there is a record of the work carried out — ready to present, without anyone having to search for it first.
A Shopware shop that nobody has touched for two years still functions. It accepts orders, sends invoices, shows stock levels — until it stops doing so. The difference between "it works" and "it is maintained" is not a state of the shop but the length of the way back to the current version. In a maintained shop, the next update is a maintenance window. In an unmaintained shop it is a chain: core jump, plugins without a successor, PHP version, database, and in between custom code that nobody has documented. Every step depends on the previous one, and the date is not set by your calendar but by whatever breaks first.
Shopware 6.7 is the current textbook example. The move from 6.6 to 6.7 is the largest technical rebuild since Shopware 6 started — Vue 3, Vite and Pinia in the administration — and the effort therefore resembles a major version jump rather than a point release. Anyone who maintained their shop continuously had a manageable list of custom adjustments and a clear plugin landscape at that point. Compatible versions of the large store plugins have been available since the beginning of 2026, unlike in the first months after the release of 6.7 in June 2025. Anyone who did not maintain their shop has the same work on top of everything else that has accumulated in the meantime. Shopware 6.8 is expected for 2027. The next date is therefore already fixed, even though the exact day is missing.
What a maintenance contract cannot do: prevent a break-in or guarantee availability. It shortens the window between a published fault and the installed patch, keeps the underlying stack on a supported version, makes faults visible earlier and documents when action was taken. We do not quote availability percentages, because in a self-hosted shop they depend on things that are not all within our control. And if a monthly flat fee does not add up for your shop — a small product range, four extensions, no ERP — we say so and propose planned update assignments at a fixed interval instead. A contract that costs more than it prevents is a bad deal for both sides.
On a website, a fault is a display problem. In a shop it is a closed till, and usually one that cannot be seen from outside: the shop loads, the catalogue works, only the order has not gone through since this morning. This is why the monitoring of a shop needs different values from the monitoring of a website — not only availability and certificate, but the number of incoming orders in relation to the usual daily pattern, the error rate in the checkout process, the state of the queue and the run time of the indexing. A shop that has not taken an order for an hour is either on a public holiday or has a problem.
The second difference is the payment providers. A shop depends on third parties who change their interfaces on their own schedule: a new API version, a changed webhook payload, expiring certificates, an adjusted flow for customer authentication, deprecated endpoints with a deadline. These changes arrive regardless of whether you currently have a project, and they hit exactly the point where money flows. On top of that, Shopware 6.7 moved the payment handlers to the single AbstractPaymentHandler base class — so payment extensions are in motion from two sides at this point. Maintenance here means reading the providers' announcements and testing the payment method after every update with a real test purchase, not with a look at the home page.
The third difference is the ERP. An ERP integration breaks on updates on both sides, and nobody announces the updates on the ERP side to you through the shop. Added to this are the questions that are not technical ones: which system owns the price, which one owns the stock, which one owns the description? What happens if the import stops halfway through — does half the data stay as it is? May the same record be written twice without causing damage? And who reads the error log? Since Shopware 6.6, stock has been a real-time value: product.stock is updated through the order events, and the former available stock is only a read-only mirror of the same field. Differences from the ERP are therefore almost always a synchronisation or reservation problem. Without ongoing checks, such differences only become apparent when a customer buys something that is no longer there.
The most common reason for a maintenance enquiry is a shop that someone else built. We do take over such shops, but not unseen. Before we commit, there is a survey of the starting point, and the list is always the same: Shopware version and patch level, the Composer setup or the lack of it, the plugin list with origin and licence situation, the scope and state of the custom code, changes to the core, theme and Twig adjustments, interfaces to ERP, PIM, shipping and payment. Added to this is the hosting: PHP and database version, cache and search services, deployment path, whether a staging environment exists, what the backups look like and whether one has ever been restored. We need shell and database access, the repository, the Shopware account and administrator rights in the shop. Without SSH, a Shopware project cannot be supported in any meaningful way.
The survey includes data processing, because a shop holds personal data: a data processing agreement under Article 28 GDPR, the chain of sub-processors, the server location, the retention of the backups, who has which access and which accounts should have been blocked long ago. In takeovers we regularly find open points there: no contract with the previous service provider, plugins licensed in the name of the old agency, the Shopware account not issued to your company, access still held by people who no longer work there. We document the state we find and have it confirmed in writing, so that later it remains possible to tell what we found and what we caused.
And we do decline. Not often, but it happens: changes right across the core that turn every update into new development; central custom development that was delivered without source code; a checkout process whose behaviour nobody can explain any more; traces of a compromise in the file system or in the administrator accounts. In that case it is not a maintenance job but a rebuild or a new build with its own quotation — and we say so before the contract, not in the third month. We do not sign a response time for a state we cannot stand behind. A promised deadline on a shop that you do not understand is a promise that will not hold when it matters.
Our response times come in tiers, four levels per shop: BASIC with 24 hours for systems where an outage delays work but does not cost revenue. STANDARD with 8 hours for shops that are needed in day-to-day business. ADVANCED with 4 hours for shops with an ongoing order volume and connected systems. PREMIUM with 2 hours for systems where every hour of standstill costs money immediately. Billing is a monthly flat fee net per shop. The response time says when someone starts working on the issue — not when the system runs again; we keep these two values separate in the contract. Without an agreement, the following still applies: processing in order of receipt within 48 hours during business hours, Monday to Friday 9:00 to 16:00.
You do not choose the tier by which number sounds reassuring, but by a calculation you can do yourself: what does an hour of standstill cost? Revenue divided by the hours in which it is generated is the starting point. Add the orders that are not made up later because the customer buys from a competitor, the service load on the phone, the delay in the warehouse and shipping, and with a connected ERP the effort of cleaning up half-transferred data. Anyone who knows this total usually places themselves in the right tier without help. Two things are independent of the tier: outside Monday to Friday 9:00 to 16:00, nobody here answers the phone unless on-call duty has been agreed — and that costs money in the months when nothing happens as well. We quote the monthly flat fee after the survey, not on the phone: it depends on the number of extensions, the scope of the custom code, the interfaces and the chosen tier.
The operating model comes in two equally valid forms. Either the shop runs on our own servers in Germany, on Proxmox PVE clusters, with a suitable PHP version, object cache and search index — then operation and maintenance are in one hand and the boundary of responsibility disappears. Or we support it on your existing hosting; for that we need SSH access, a clean deployment path, a staging system and sufficient PHP and database versions. If any of this is missing, we set it up there or weigh it against the cost of a move, instead of making every maintenance job more expensive than it needs to be. Where hosting and application are separate, we put the boundary of responsibility in writing before we start, so that in the event of a fault nobody has to search for who is responsible. And we set up the ongoing support so that you can end it: source code in your repository, licences and access issued to your company, domains in your name, installation documented.
Process
If the answer is "nobody" or "I don't know", you are in the right place. Send us the domain and, if you have it, an access account. The first assessment of version, patch level, plugin landscape and hosting is free of charge; the detailed report of findings is a clearly defined first product at a fixed price, which we state in writing beforehand — and it belongs to you, even if you then hire someone else. Sharpness Solutions GmbH, Edewechter Landstrasse 161, 26131 Oldenburg. Telephone 0441 21 21 63 0, Monday to Friday 9:00 to 16:00, info@sharpness.de. We work remotely across Germany, with meetings in Oldenburg and the north-west by arrangement.
You describe the situation: which Shopware version is running, who built the shop, what was changed last, where the hosting is. We tell you which access we need for the survey — shell, database, repository, Shopware account, admin. If the previous service provider does not respond, we request the access ourselves.
The first assessment based on the domain and access is free of charge. The detailed report of findings is a clearly defined first product at a fixed price, which we state in writing beforehand: we look at the code, the plugin list, the logs, the hosting and the backups, and we write down what works, what is open, what has to happen first and what will be expensive. Only after that do we talk about a contract. A commitment made before looking at the code would be a guess, and guessing is not a method with third-party code.
If there is no staging system, we set one up first. That is where the first full update run takes place, including a plugin check and a test purchase through every active payment method. This also shows whether the existing backup can be restored. Whatever breaks, breaks on a copy.
You choose the tier — BASIC 24, STANDARD 8, ADVANCED 4 or PREMIUM 2 hours response time — based on the question of what an hour of standstill costs. Added to this are availability, the escalation path, on-call duty if needed, the boundary of responsibility towards the hosting and the data processing agreement. All in writing, nothing verbal.
We bring the patch level up to date, clear out extensions without a maintainer, move monitoring and the backup chain onto our processes and document the state. At the end there is a record that you can present to your management or your data protection officer.
After that comes regular operation: assess releases and install them in agreed windows, track plugin compatibility, keep an eye on logs and queue, check backups, answer questions from your team. Once a quarter we look ahead at what is coming for the shop — the next major version 6.8 is expected for 2027. You write to the same address as in the first conversation, not to a shared inbox.
Projects on this system
A selection — not the full client list.
Included are security and bugfix releases of the current Shopware line after testing on staging, plugin care, care for PHP, the database, cache and search services, backups with a restore test, monitoring of availability, logs, queue and the error rate in the checkout process, plus a record of the work carried out and the agreed response time. Not included are the jump to a new major version, new features, redesigns and the development of additional extensions. Those are separate projects with their own planning and their own quotation.
Maintenance runs as a monthly flat fee net per shop, in tiers according to the agreed response time; anything beyond that is charged by time and effort. We do not publish a price list, because the price depends on factors that can be verified: the number and origin of the extensions, the scope of the custom code, the interfaces, the chosen service level tier and whether operation is included. Anyone who quotes a monthly price without looking at the shop is calculating an average that you pay for. The first assessment based on the domain and access is free of charge; the detailed report of findings is a clearly defined first product at a fixed price, which we state in writing beforehand. The quotation for ongoing maintenance follows from that.
There are four tiers per shop: BASIC with 24 hours response time, STANDARD with 8, ADVANCED with 4 and PREMIUM with 2 hours. The decision is made with a calculation, not with a feeling: what does an hour of standstill cost? Revenue divided by the hours in which it is generated, plus the orders that are not made up later, plus the service load and the clean-up effort with a connected ERP. A shop with an ongoing order volume and an ERP connection therefore usually lands at ADVANCED or PREMIUM, a catalogue with an enquiry form at BASIC.
Binding response times only apply with a signed agreement. Without an SLA we process reports in order of receipt within 48 hours during business hours, Monday to Friday 9:00 to 16:00. This is not a negotiating tactic but the condition under which the tiered times can be kept at all: anyone who promises 2 hours has to keep capacity free for it, and that capacity cannot be sold twice. In the evening, at the weekend and on public holidays, nobody answers the phone unless on-call duty has been agreed.
No. A major version jump brings breaking changes, requires a check of every extension, adjustments to the theme and the custom code and a separate test run — that is a project with a quotation, not a maintenance window. The move from 6.6 to 6.7 shows the scale: Vue 3, Vite and Pinia in the administration mean an adjustment for every plugin and every custom theme. Shopware 6.8 is expected for 2027; extended support for 6.6 is extended accordingly until 6.8 appears, and the most recent release in the 6.6 line was 6.6.10.22 on 5 August 2026. Updates within the current line, by contrast, are part of maintenance. We describe support for a version jump from 6.6 to 6.7 at /shopware-hilfe.
The rhythm follows the releases, not a calendar entry: within the current line, Shopware publishes a patch release roughly once a month — 6.7.12.0 on 7 July 2026, 6.7.13.0 on 5 August 2026 — and each of them is assessed: does it affect the installation, what does it change for active extensions, how urgent is it. We do not install a new x.x.x.0 release on release day, because Shopware has withdrawn individual releases after publishing them; 6.7.12.0 could not be installed, and the fixes only became usable with 6.7.12.1. We therefore wait for a reliable patch level. Nothing is skipped, because every skipped version makes the next jump bigger.
No. We also support shops on third-party hosting, as long as the basics are in place: SSH access, a clean deployment path, a staging system and sufficient PHP and database versions. If one of these is missing, we set it up there or weigh it against the cost of a move — without shell access, every maintenance job is more expensive than a change of host. Alternatively, the shop runs on our own servers in Germany, on Proxmox PVE clusters; then operation and maintenance are in one hand. Where responsibility is split, we put the boundary of responsibility in writing before we start.
Yes, that is the most common reason for a maintenance enquiry. Before we commit, we look at the code, the plugin list, the logs, the hosting and the backups and provide written findings; only after that does a contract come about. We need shell and database access, the repository, the Shopware account and administrator rights in the shop. Missing documentation is not a reason to decline — undocumented code is the normal case. If the previous service provider does not respond, we request the access ourselves.
Yes. If changes run right across the core and turn every update into new development, if central custom development was delivered without source code, if nobody can explain any more what happens in the checkout process, or if we find traces of a compromise, then it is not a maintenance job. In that case a rebuild or a new build is due, with its own quotation, and we say so before the contract instead of in the third month. A promised response time on a shop that you do not understand will not hold when it matters.
Extensions are part of maintenance, because an up-to-date core on its own is of no use: the faults usually sit in third-party plugins and in custom code, and those are exactly what the vendor's support does not cover. For every update we check which extension has a matching version, which one still has a maintainer and which one sits unused in the shop. Anyone who maintains a plugin for two lines needs separate releases for 6.6 and 6.7 — the same applies to your own plugins, and that is why this list belongs in maintenance and not in a spreadsheet that nobody keeps up to date.
As a rule, no. Testing takes place on a staging copy, deployment happens in an agreed window, usually outside your main selling hours. What may be briefly noticeable is the clearing and warming of the caches after the deployment; for larger database migrations we plan a window with a maintenance page and announce it beforehand. Every change starts with a backup, and the way back to the previous version is documented, not improvised.
Through a data processing agreement under Article 28 GDPR, with named sub-processors and documented retention of the backups. If operation is included, the shop runs on our own servers in Germany. In takeovers we check this point as well, because something is regularly missing there: no contract with the previous service provider, access held by people who left the company long ago, plugins licensed in the name of the old agency. You receive the update record in a form that you can present to your data protection officer.
Especially then. A shop that nobody works on still changes from the outside: payment providers change interfaces and deprecate endpoints, the ERP is updated on the other side, browsers change their behaviour with cookies, security vulnerabilities are described publicly, and the PHP version in use eventually reaches its end of life. Meanwhile the shop keeps working — until it stops, and by then the cause is months old. Without changes to the shop, maintenance becomes smaller, not unnecessary.
Only to a limited extent. The work described here assumes a self-hosted shop: logs under var/log/, bin/console, your own staging, access to the database, cache and search index. In Shopware Cloud the vendor takes care of updates and infrastructure; what remains for us there is the care of configuration, apps built to the Shopware standard and interfaces via the Admin API and the Store API. We clarify which version you run in the first conversation — what a maintenance contract can cover at all depends on it.
Enquiry
Describe briefly how the shop is currently supported — or that it is not. We look at the code, the plugin list and the hosting and tell you what has to happen first, before we talk about a contract.