Shopware maintenance: what a retainer must deliver
Shopware maintenance is more than updates and tickets. Here is how we combine operations, SLAs and continuous development in a F.O.C.U.S. retainer.
Professional Shopware maintenance covers six building blocks: monitoring and alerting, security and version updates, extension and integration maintenance, backups with tested recovery, prioritised bug fixes with SLAs, and continuous technical housekeeping. A retainer bundles these services with reliably reserved capacity — at nuonic starting at around €1,000 per month, depending on store size, custom code and SLA.
Because a Shopware store is not finished after go-live. From that day on, it is a production system: Shopware releases updates, extensions change, integrations produce new edge cases and the business develops new requirements. At the same time, customers expect search, checkout, payment and order transfer to work whenever they need them.
That is what maintenance is for. Yet the term can mean very different things. For one provider, it only means that somebody reads a ticket when requested. For another, it includes updates, monitoring and a number of development hours. This makes proposals difficult to compare.
This article explains what a reliable Shopware maintenance agreement should include, what distinguishes a retainer, and which options nuonic clients have for continuous development. The essential point is that maintenance should do more than preserve today's state. When organised properly, it creates the technical and operational foundation for controlled evolution.
Shopware maintenance, support and retainers: the difference
The three terms describe different layers of the same responsibility: maintenance prevents risk and keeps the technical platform current, support responds to incidents with defined response times, and a retainer reserves reliable capacity for both — optionally combined with planned development. A retainer is therefore not a prepaid block of hours but a responsibility model.
| Term | Purpose | Typical scope |
|---|---|---|
| Maintenance | Prevent risk and keep the technical platform current | Security patches, Shopware updates, extension compatibility, backups, technical housekeeping |
| Support | Respond to incidents and specific questions | Error analysis, bug fixes, incident communication, defined response times |
| Retainer | Reserve reliable capacity and a working relationship | Maintenance and support, optionally combined with planned development |
A retainer is therefore not simply a block of hours paid in advance. Its value is reliability: one team knows the system, follows its condition, reserves capacity and works to an agreed cadence. This reduces onboarding, coordination and the time until the first useful action.
A retainer still needs explicit boundaries. A new ERP integration is not a small maintenance request. Conversely, a critical checkout failure must not disappear into a normal feature backlog. Scope, priorities, response times and the treatment of larger initiatives must be part of the operating model.
What professional Shopware maintenance includes
A store can be reachable from the outside while becoming riskier internally. Outdated extensions, failed queue jobs or growing error logs are often noticed only once revenue is affected. Good maintenance therefore combines prevention, observation and response across six building blocks: monitoring and alerting, security and version updates, extension and integration maintenance, backups and recovery, prioritised bug fixes with SLAs, and technical housekeeping.
Monitoring and alerting
A basic uptime check is not enough. Depending on the system, response times, error rates, queue workers, cron jobs, storage, certificates and critical business processes should also be monitored. The aim is not to turn every deviation into an alert, but to identify signals that may affect customers or operations.
Security and version updates
Security fixes need a different cadence from a major feature update. Every update needs, at minimum, a dependency review, a staging test, a current backup and rollback path, and post-deployment checks. Shopware itself recommends, in its update documentation, a test environment, current backups and an extension compatibility check before updates.
Extension, theme and integration maintenance
A Shopware store rarely consists of the core alone. Payments, shipping, ERP, PIM, search, tracking and custom extensions form a network of dependencies. Maintenance has to include that network. A green core update check does not prove that the complete order process works.
Backups and recovery
“A backup exists” and “the system can be recovered” are not the same. It must be clear which data and files are protected, how long recovery takes and who performs it during an incident. Rollback is part of deployment planning, not an improvised idea after something has failed.
Prioritised bug fixes and SLAs
Not every defect is an emergency. A broken checkout needs a different response from a cosmetic spacing issue in the account area. Our Shopware support and maintenance service therefore uses incident classes and defined response times. Criticality and ownership are agreed before an incident occurs.
Technical housekeeping
Reviewing logs, removing deprecations, adding tests, analysing slow queries and updating documentation are not highly visible tasks. They do, however, determine whether the next update becomes routine or a recovery project. Technical debt does not disappear because there is a maintenance agreement. The agreement makes it visible and possible to prioritise.
Why ad-hoc support becomes expensive
Individual assignments can look flexible, but for a business-critical store they move cost to the worst possible moment: the incident. Nobody consistently follows update status and warning signs, the team has to relearn the system before every change, and capacity is uncertain precisely when the problem is urgent. On top of that come two creeping effects:
- Small risks remain unresolved until they combine into a larger failure.
- Maintenance, features and strategic requests compete in an unstructured list.
A retainer does not remove every individual decision. It creates a reliable framework in which decisions are made with system context. That is the difference between “someone can process tickets” and “a team continuously assumes responsibility.”
F.O.C.U.S.: maintenance with direction, not a ticket factory
Our F.O.C.U.S. system does not begin with an arbitrary monthly number. It connects safe operations with measurable development. The five phases — Facts, Objectives, Constraints, Execution and Scaling — are not filed away after go-live; they form a recurring control loop: from a reliable picture of the system's condition through measurable objectives and explicit limits to controlled releases and the next improvement cycle.
F — Facts: understand the real condition
At the start, we review versions, custom code, extensions, infrastructure, deployments, monitoring, backups, tests and known defects. We also examine business facts: Which processes generate revenue? Where is manual work created? Which incidents have already occurred?
The result is not a generic checklist but an assessment of the actual system. When taking over a store built by another agency, the relationship therefore starts with a code and system audit.
O — Objectives: define operations and impact together
“The store should run” is necessary but not measurable enough. Objectives can include availability, shorter response times, fewer checkout errors, faster deployments or less manual order processing. This gives development a clear direction as well: measures compete based on impact, not on the volume of the latest ticket.
C — Constraints: expose limitations early
Budget, team capacity, legacy extensions, missing tests, release windows and ERP dependencies constrain every roadmap. We make those limits explicit. This prevents a supposedly small feature from blocking an update, or a maintenance budget from being overloaded with an integration project.
U — Execution: small, controlled releases
Updates, bug fixes and improvements follow the same traceable path: prioritise, implement, verify, deploy and observe. Depending on scope, the result is a maintenance release, a development sprint or a separate project. Our Shopware development page explains how we deliver custom features and integrations.
S — Scaling: learn from operations
Monitoring, support cases and usage data generate new facts. Recurring causes can be automated, slow processes improved and effective features expanded. Maintenance becomes the basis for optimisation and growth instead of merely preserving the status quo.
Three development options at nuonic
Not every store needs the same development capacity at all times. We therefore separate a reliable operating baseline from the right form of development — with three models: a pure maintenance retainer for reliable operations, maintenance plus continuous development for an ongoing backlog, and a separate project for larger development steps.
Option 1: a maintenance retainer for reliable operations
This model suits stable stores whose business functionality changes only occasionally. Its focus is monitoring, security and Shopware updates, defect resolution and agreed response times. Smaller adjustments can be prioritised; larger initiatives are assessed separately.
Our maintenance retainers start at around €1,000 per month, depending on store size, custom code and SLA. Our overview of Shopware costs explains the other licence, project and operating cost blocks.
Option 2: maintenance plus continuous development
This model is suitable when there is a meaningful backlog to deliver alongside ongoing operations. In addition to the maintenance baseline, we reserve predictable development capacity. It can be used for conversion improvements, automation, new store functionality, integration work or performance.
F.O.C.U.S. keeps operations and product work in one system: risks remain visible, objectives drive prioritisation and changes reach production through controlled releases. The advantage over changing one-off assignments is retained context. The team that understands the architecture and its failure modes also develops the next feature.
Option 3: a separate project for a larger development step
An ERP integration, a B2B portal, replatforming or a new storefront concept should not be forced into a small monthly allowance. Such initiatives receive their own objectives, budget, roadmap and acceptance criteria. The existing maintenance retainer protects ongoing operations in parallel.
After go-live, the result can return to regular support. Our COMSPOT case study and Xucker case study show how that relationship works over several years.
Which model fits which store?
The short answer: a stable store without a large backlog needs the maintenance retainer, a continuously prioritised backlog needs maintenance plus development, a clearly bounded larger step needs a separate project with ongoing maintenance — and an unclear condition after an agency change starts with a system audit. The mapping at a glance:
| Situation | Useful starting point |
|---|---|
| The store is stable; updates and response times need structure | Maintenance retainer |
| There is a continuously prioritised backlog | Maintenance plus a development retainer |
| A clearly bounded larger development step is planned | Separate project plus ongoing maintenance |
| Another agency built the store and its condition is unclear | System audit, stabilisation, then the appropriate retainer level |
The model can change. After a large project, more stabilisation capacity may be useful; during a growth phase, a continuous development cadence may matter more. Scope and responsibility should be adjusted deliberately, before budget or technology is already under pressure.
And if the path to the right model leads through a new partner: how the switch succeeds in a running maintenance project is described in our whitepaper with phase model, asset inventory and handover checklist.
How to recognise a good maintenance agreement
A good maintenance agreement answers ten questions concretely — from the systems included, through monitoring, update procedures and response times per incident class, to reporting, cover and measurable metrics. Without clear answers, the agreement often sells availability rather than responsibility. At least these questions should have concrete answers before signing:
- Which systems, extensions and environments are included?
- What is monitored, and who receives which alerts?
- How are security, minor and major updates treated?
- Which response times apply to each incident class?
- How do backup, recovery and rollback work?
- Which services are maintenance and which are development?
- How are priorities, capacity and open risks reported?
- Who actually works on the system, and how is cover organised?
- How are larger initiatives separated from the retainer?
- Which metrics show that operations and development are improving?
Conclusion: the retainer is the operating system of the relationship
Shopware maintenance protects revenue, data and the ability to act. A good retainer turns that protection into a reliable working relationship, with system context, reserved capacity, transparent priorities and a clear path from incident to improvement.
F.O.C.U.S. connects these layers. Facts prevent guesswork, Objectives give development direction, Constraints protect against unrealistic commitments, Execution brings changes live safely and Scaling turns operational data into the next improvement cycle.
Clients remain flexible: reliable operations only, operations plus continuous development, or a separate project for the next major step. If the current condition needs to be understood first, the relationship can begin with a system audit and maintenance model.
Official sources
Let's talk about your system.
No pitch deck. A conversation with the people who build.