Shopware help
A 500 error in the checkout, wrong stock figures from the ERP, a shop nobody has updated in months. That is what brings people here. Sharpness Solutions in Oldenburg helps operators of self-hosted Shopware 6 shops with outages, updates, migrations from Shopware 5 and interfaces to ERP, PIM and CRM systems. Shopware 5 left maintenance at the end of July 2024; the current version is Shopware 6.7. As of 16 August 2026. Phone +49 441 21 21 63 0, Monday to Friday, 9:00 to 16:00 CET.
Anyone searching for Shopware help is not looking for an agency profile. They have a symptom. These six cases cover most of what people call us about: a 500 error in the checkout, a failed update to Shopware 6.7, a shop still on the discontinued Shopware 5, stock figures that disagree with the ERP, poor load times, an agency that has stopped answering. Usually the account begins with “it all worked yesterday”. The cause was in place long before that.
The shop loads, but the order fails. First place to look: var/log/ in the Shopware directory. Then bin/console cache:clear, then deactivate the plugins one at a time. If the error survives that, it sits in the code — usually in an extension somewhere in the order process.
Shopware 6.7 moved the build system from Webpack to Vite, replaced Vuex with Pinia and removed the Cached*Route classes. Extensions built on any of that break silently. We check your plugin list against 6.7 before you update.
Shopware 5 has been out of the manufacturer's maintenance since the end of July 2024. The shop keeps selling, but every new vulnerability stays open unless you buy patches through safefive — the paid third-party service that took the maintenance over. safefive postpones the migration date. It does not replace it.
Since Shopware 6.6 stock is a real-time value: product.stock is written forward by the order events, and the former “available stock” is now only a read-only mirror of the same field. Differences from the ERP are therefore almost always a synchronisation or reservation problem, not an indexing problem.
Before Redis enters the conversation, we check three things: is the instance still running in development mode? Is the HTTP cache switched on? How many plugins sit in the request path? Development mode is the most common finding.
You have a shop, but no access credentials, no documentation and nobody to ask. That is unpleasant and still solvable. What you are contractually entitled to is a question for a lawyer, not for your new agency. The technical review runs without the old agency taking part.
A 500 error (HTTP 500, “Internal Server Error”) in the checkout of a Shopware 6 shop almost always has one of three causes: cache, indexing or a plugin. The order to work through yourself: 1. Read the log files under var/log/. 2. bin/console cache:clear, cache:clear:http and cache:warmup. 3. bin/console dal:refresh:index if new products do not appear. 4. bin/console plugin:deactivate, then cache:clear again. Messages such as “Unable to generate a URL for the named route” point to the cache or to routing. An error from the search index — Elasticsearch or OpenSearch — when a category is opened points to the index, and bin/console es:index is the answer. “Class not found” or a blank page points to a plugin. If you have been through all of that and are still in the dark, you need someone with shell access.
The manufacturer does not run a support hotline for technical faults. The telephone number on shopware.com leads to sales and general enquiries; technical support requires a paid plan and runs through account.shopware.com, and operators of the Community Edition are explicitly referred to the community forum. So anyone looking for somewhere to report a fault is looking for something that does not exist at the manufacturer in that form. Here, somebody picks up the phone, Monday to Friday, 9:00 to 16:00 CET. We do not promise response times in hours across the board. Either they are in a service level agreement or they are nowhere. Outside Monday to Friday, 9:00 to 16:00 CET, nobody here answers the phone. If you need someone on a Saturday evening, you need an on-call arrangement. That exists only with an SLA, and it costs money in the months when nothing happens as well.
When something breaks, we work backwards from the last state that worked: what was deployed last, which plugin was installed, what the Composer state looks like. We reproduce the fault on a staging system, not in the live shop. Nothing gets fixed until the cause has a name. A rollback is a decision, not a panic reaction. Anyone who runs updates only through the graphical interface and has no staging system also has no way back. That is the gap we close first, because it makes the next emergency cheaper than this one.
Migrating from Shopware 5 to Shopware 6 is not an update. It is a rebuild with the data carried over. The Shopware Migration Assistant is free in the Shopware Store and currently compatible with 6.6.0.0 to 6.7.13.0; the Migration Connector plugin is installed in the source shop as well. It carries over products, variants, manufacturers, categories, customers, orders including order documents, media, shipping methods, cross-selling, custom fields, SEO URLs and product reviews, among other things. Before the run starts there is a data check that asks for mappings — assignments for everything that cannot be resolved automatically.
The Shopware Migration Assistant migrates data and nothing else. It does not migrate your appearance, your functions or your interfaces. The theme and the extensions are built again, and the ERP, PIM and CRM connections are wired up again. That is where the cost sits, not in the data transfer, and it is the part operators are regularly surprised by. One more trap: leave the sales channels created during the first run in place. If customers are attached to them, the database refuses to delete them anyway with a foreign key violation, and removing the channel by some other route risks incomplete subsequent runs. After every run, compare the number of customers and orders carried over against the old shop. Customers and orders do simply go missing.
In the end, a migration succeeds or fails on the redirects. The SEO URLs from Shopware 5 can be carried over, but Shopware 6 uses a different URL structure; without a complete redirect plan you lose rankings built up over years on the day you switch, and you lose them for good. We generate the plan from the old data, not from assumptions, and check it before the cutover. If you have no time for that right now, safefive patches for Shopware 5 buy you some air. That is an extension of the deadline, not a solution. Nobody guarantees position 1 along the way, and neither do we.
Shopware 6 has two APIs plus a special route for bulk data that is regularly mistaken for a third. The Admin API is the administrative interface: authentication over OAuth 2.0 in the client credentials flow, the integration is created under Settings → System → Integrations, the Access Key ID is the client_id and the Secret Access Key is the client_secret. The token is requested by POST to /api/oauth/token, is valid for 600 seconds by default and is then sent along as a bearer header; when it expires, you request a new one. The Store API is the customer-facing interface for product search, cart and checkout. It authenticates through the sales channel's sw-access-key header, not through OAuth.
For bulk data there is the Sync API: not a separate access route, but an endpoint of the Admin API at /api/_action/sync, using the same token. It knows only two operations, upsert and delete, so it does not distinguish between creating and changing. What decides the runtime is the indexing-behavior header: without it, indexing happens immediately inside the request; with use-queue-indexing the message queue takes over; with disable-indexing it is skipped entirely. Run a full import without that header and you will wait orders of magnitude longer. For B2B procurement there are OCI and cXML punch-out catalogues on top. That is neither a core feature nor a module of the B2B Components — it comes from a third-party extension or is built in-house on the Store API. The buyer starts in the procurement system, fills the cart in the shop and hands it back.
The hard questions in an ERP connection are not technical but operational: who owns which field — price, stock, description? What happens when the import breaks off halfway through? May the same record be written twice without doing damage? And who reads the error log? Shopware 6 handles static tiered and customer group prices through the Rule Builder. For customer-specific prices out of the ERP there are two routes: the Customer Specific Pricing API in the Shopware Commercial extension and, in the B2B Components, the Individual Pricing module. Anyone who avoids both and turns every customer into their own customer group drives the product_price table into absurdity. The row count then grows with every customer times every article, and the lookup against that table becomes the bottleneck in the checkout.
A slow Shopware shop usually has a chain of causes rather than a single culprit, and the chain can be worked through in a fixed order. First: is the instance still running in development mode? Then Shopware writes debug logs on every request and recompiles templates. Switching to production mode alone usually produces the single largest gain; how large, we say after the measurement, not before it. Second: is the HTTP cache actually switched on via SHOPWARE_HTTP_CACHE_ENABLED=1? Third: how many plugins sit in the request path, and what are they doing there? Only after that is it worth talking about infrastructure.
Valkey, Redis and OpenSearch do not repair a bad query. A search index does not speed it up, it only moves it, and a silent fallback to the MySQL search hides the problem until the catalogue grows. Set SHOPWARE_ES_THROW_EXCEPTION=1 so that fallback becomes visible. On the database side, two values belong in the configuration: group_concat_max_len from 320000 upwards and a sql_mode without ONLY_FULL_GROUP_BY. On the PHP side there are four: opcache.validate_timestamps=0, opcache.interned_strings_buffer=20, zend.assertions=-1 and realpath_cache_ttl=3600. These are operating parameters, not insider tips. They are missing surprisingly often all the same.
The operating stack recommended in the Shopware documentation can be held against your hosting line by line: PHP 8.4 recommended and 8.2 as the minimum, memory_limit from 512M; MariaDB 11.4 or MySQL 8.4; Node.js 24 with npm 10 for the administration build; Valkey 8.0 or alternatively Redis 7+; OpenSearch 2.17.1; Caddy as the recommended web server, with Nginx and Apache also supported. Anything below that is not a performance problem, it is a hosting problem. We run Shopware instances on our own servers in Germany, on Proxmox PVE clusters, with PHP 8.4, Valkey and OpenSearch.
We take over existing Shopware shops, but not blind. It starts with a review: Shopware version and patch level, the Composer and plugin list with the origin of each entry, the amount of custom code, the state of the hosting, the deployment routes that exist, the backups and whether they can actually be restored. Out of that comes a findings report with a risk list and an estimate — a self-contained first deliverable, not a sales conversation. Only then do we say what we can take on. A commitment made before looking at the code would be guesswork, and guessing about somebody else's code is not a method.
For the handover we need access, and the list is always the same: hosting or server, database, Git repository, Shopware account, API keys and integrations, plus the configuration of Redis or Valkey and of any Varnish in front. You do not have to change your hosting for this. We work on what is there; moving to our servers is a separate decision with a separate quote. Missing documentation is not a reason to decline. Undocumented code is the normal case, not the exception. The real risk in changing agency is rarely the change itself, it is the unknown state of the old system. How long a change takes is decided by exactly that state: with complete access and an existing Git repository we are typically looking at a few weeks. The number you can rely on is in the findings report, not before it.
After the findings report there are two ways of working with us. Either you commission individual pieces of work — one fault, one update, one interface — and we bill by time and materials. Or we agree a maintenance contract with an SLA that sets out response times, availability and scope in writing. The difference from the manufacturer's support: Shopware supports its own product, not your third-party plugins and not your custom code. That is exactly where the errors that reach us most often sit. You cannot support code you do not know. That is why we take on no support without a review first. We have been developing in Oldenburg under the Sharpness name since 1999; the contracting party is Sharpness Solutions GmbH.
Process
+49 441 21 21 63 0, Monday to Friday, 9:00 to 16:00 CET, or through the form. You describe the symptom, we tell you what we see. What the repair costs is in the findings report afterwards. We work remotely across Germany; meetings in the north-west by arrangement.
You describe the symptom; we ask for the Shopware version, the hosting, the plugin list and the last deployment. The symptom turns into a hypothesis. You can reach us Monday to Friday, 9:00 to 16:00 CET, by phone or through the form.
We need shell or SFTP access, the database, Git and an admin account. Then we read logs, the Composer state and the plugin list instead of guessing. If there is no staging system, we set one up first.
We tell you in writing what is broken, why it is broken and what the repair costs. Plus the risks we found along the way — prioritised, not as a wish list.
The work happens on a staging system, not in live operation. We run updates from the command line rather than through the graphical updater, we avoid x.x.x.0 releases and wait for a patch level that holds.
After going live we measure the same values as before: response times, error rate in the log, indexing time. Without a before value, every improvement is a claim. You get the result as a comparison, not as an adjective.
After that, either a maintenance contract with an SLA, monitoring and planned updates — or a clean handover to your team including the documentation. Both are fine. A shop nobody maintains is not.
Projects on this system
A selection — not the full client list.
There is no public support hotline for technical faults at Shopware: existing customers on a paid plan go through account.shopware.com, and operators of the Community Edition are explicitly referred to the community forum. According to Shopware's price overview, the paid plans start at Rise from 600 euros per month and Evolve from 2,400 euros per month, each plus VAT. Technical help for a self-hosted shop therefore usually comes from service providers. We are one of them, in Oldenburg, Monday to Friday, 9:00 to 16:00 CET, on +49 441 21 21 63 0.
We do not commit to binding response times without a maintenance contract. Within business hours, Monday to Friday, 9:00 to 16:00 CET, we take your fault report by phone or through the form and tell you when we can deal with it. Outside those hours nobody here answers the phone. If you need someone in the evening, at the weekend or on a public holiday, you need an on-call arrangement. Fixed deadlines, availability and scope are set out in a maintenance contract with a service level agreement — which also costs money in the months when nothing happens.
We bill individual jobs by time and materials, while ongoing support runs through a maintenance contract with a monthly fee and a service level agreement. We name figures once we have seen the shop. The findings report with a risk list and an estimate is a self-contained first deliverable at a fixed price, which we state in writing beforehand. Migrations and interfaces are priced from that report, not on the phone. The current hourly rate and the price of the findings report are available on request.
We work with Shopware Cloud (SaaS) too, but within narrower limits: the work described on this page assumes a self-hosted Shopware 6 shop, either Community Edition or Commercial on-premise — logs under var/log/, bin/console, your own staging, your own servers. Shopware Cloud has neither a shell nor bin/console. There we handle configuration, app development to the Shopware standard and interfaces through the Admin API and Store API; anything touching servers, cache and database is reserved for the manufacturer. Which of the two you run is something we establish in the first phone call.
The current version is Shopware 6.7.13.0, released on 5 August 2026 (this page is dated 16 August 2026). For new projects, the current 6.7 level is the right choice. For existing shops the rule is: stay on the current major version and follow the patch levels promptly. Avoid new x.x.x.0 releases — Shopware blocked 6.7.12.0 shortly after publication. According to the release notes, that version cannot be installed or updated to because of a defect found afterwards, and 6.7.12.1 is to be used instead. Wait for a later patch level.
Shopware 6.7 is maintained for as long as 6.7 is the current major version; Shopware names no fixed end date, and the next major version, 6.8, was pushed back to 2027 on 12 November 2025. The reason there is no year attached: Shopware ties support transitions to major releases rather than to calendar dates — in Shopware's own words, “Support transitions are tied to major releases, not fixed timelines.” There are four states: maintained, extended support, security fixes only, and end of life. Extended support for 6.6 is extended accordingly until 6.8 is released.
Yes — Shopware 5 reached end of life at the end of July 2024: the manufacturer develops no further security updates and has handed commercial security support to safefive. A Shopware 5 shop keeps selling after that, it just stops getting safer. If you cannot migrate immediately, safefive buys you time: the security plugin is free in the Shopware Store but requires a contract, and the cost depends on annual net revenue and is charged per productive instance.
Shopware 6.7 was an infrastructure release with hard breaking changes, which is why extensions and custom templates are what break. The administration build system moved from Webpack to Vite, state management from Vuex to Pinia, Store API route caching and all Cached*Route classes were dropped, the payment handlers were consolidated into a single AbstractPaymentHandler class, and header and footer load via ESI. Custom field names may no longer contain hyphens or full stops. On top of that came accessibility rework in the storefront, which can take custom templates apart. We check the plugin and template state against 6.7 before an update goes into production.
The data run itself in the Shopware Migration Assistant takes hours, depending on the size of the catalogue and the order history. What sets the schedule is not that run but the rebuild: the assistant does not carry over the theme, the extensions or the interfaces — those are built and connected again. How many weeks that amounts to depends on the number of extensions, on the ERP, PIM and CRM connections and on the state of the old data. A number you can rely on is in the findings report before the project starts, not in the first phone call.
Stock levels diverge because “stock” and “available stock” have shown the same real-time value since Shopware 6.6: product.stock is updated through the order events, and availableStock is now only a read-only mirror. If the ERP delivers correct figures and the shop still shows the wrong ones, the transfer is the problem: which system writes last, are reservations counted twice, does the import break off? In the cart, the quantity can be raised beyond the stock level as long as the closeout flag is not set. That is the first thing to check; with sets, bundles or several sales channels on one warehouse, server-side validation is added.
A slow Shopware 6 shop almost always has one of five causes, in order of frequency: the instance is still running in development mode, the HTTP cache is not switched on, there is no object cache in Redis or Valkey, OpenSearch is missing on a large catalogue, or too many plugins sit in the request path. Moving from development mode to production mode usually produces the single largest gain. Work through that chain from the top down before you think about more hardware. Hardware hides causes, it does not remove them.
Redis or Valkey, Varnish and OpenSearch are not automatically necessary for a Shopware 6 shop — whether they are worth it depends on catalogue size, traffic and architecture. Shopware recommends Valkey 8.0 or Redis 7+ for caching and for delayed cache invalidation under many concurrent writes, a reverse proxy such as Varnish mainly when there are several application servers, and OpenSearch 2.17.1 once the MySQL search reaches its limits. Set SHOPWARE_ES_THROW_EXCEPTION=1 while you are at it, otherwise the search falls back to MySQL silently and you take a problem for solved that is still there.
Enquiry
Describe briefly what is not working or what is coming up. For an acute fault, better to call — we are faster than any form.