In short and in plain language
Taking care of an online shop costs money every month. How much depends mostly on how the shop is built.
Shopware puts out a new version every month. Each new version has to be tested first. The more add-ons a shop has, the longer the test takes.
Your own code and links to other programs also take work. Fast help at night costs more than help on a work day.
Plan two extra items: money for emergencies and money for the big update. A big update comes about once a year.
A maintenance contract for an online shop is usually negotiated as a monthly amount, but it is made of work that can be counted: installing and testing updates, checking extensions, keeping integrations in step, handling incidents and preparing the next version jump. How much of that work arises depends less on the size of the product range than on how the shop is built. Shopware says so plainly for major updates: the effort required for adaptation depends on the level of customization and the number of extensions in use (Shopware). On top of that comes a cadence that is not up for negotiation: for self-hosted shops, minor releases ship monthly (Shopware). This article breaks a maintenance budget into five building blocks, shows the cost drivers that make each of them grow or shrink, and explains how to arrive at a figure for 2027 that still holds up in the fall.
Key takeaways
- For self-hosted shops, Shopware publishes a minor release on the first Monday of every month (Shopware), which makes twelve a year, plus one major version a year. Every version needs a test before it goes live.
- The effort of an update grows with the number of extensions and the level of customization (Shopware). An inventory listing vendor, version, license and owner is the first step of any budget plan.
- Every integration with the ERP, payment or shipping is a separate test path after every update. The number of integrations times the test paths per integration gives the checks per release.
- Response time moves the price more than the size of the product range: a round-the-clock commitment requires standby at night and on weekends, a first response on business days does not.
- The emergency allowance and the reserve for the next version jump belong next to the flat fee as separate lines. Security updates for PHP 8.2 end on December 31, 2026 (The PHP Group).
- The baseline load grows even if nothing in the shop changes: according to the 2025 situation report, an average of 119 new vulnerabilities per day were disclosed worldwide (BSI), and from March 15, 2027 TLS certificates may be valid for 100 days at most (CA/Browser Forum).
Why maintenance has no standard price
Anyone who asks for a maintenance quote usually receives a monthly amount. Behind it lies work whose volume the provider has to estimate in advance: how many updates will there be, how long does testing take, how often does someone have to step in without it being planned? For two shops with the same revenue, the answers can be far apart. Whether a contract is billed as a flat fee or by the hour, and which services belong in it, is covered in Maintenance contract: key contents. This article starts one step earlier, with the question of how much work a flat fee has to cover in the first place and what makes that amount grow.
The vendor names the core of it for major updates: the effort required for adaptation depends on the level of customization in the shop and the number of extensions in use (Shopware). A shop with a standard theme and a few extensions from the store mainly needs a functional test after an update. A shop with its own theme, custom-built plugins and several connected systems needs the same update checked at every point where its own code meets the core. The monthly amount reflects that difference, whether it is shown openly or not.
The work can be split into five building blocks, and each has its own drivers. Some are outside your control, such as the release cadence of the shop system and of the PHP scripting language. Others are yours to decide: how many extensions run, how much custom code the shop contains, how many integrations are maintained and how quickly someone should respond in an incident. Once you know these drivers, you can read a quote and justify a budget.
The five building blocks of a maintenance budget
A maintenance budget consists of three predictable parts and two that fluctuate. The predictable ones recur month after month at a similar level, the fluctuating ones depend on events nobody can schedule. The table shows what goes into each block, who sets the pace and which driver determines the amount.
| Building block | What it includes | Pace setter | What drives the amount |
|---|---|---|---|
| Base maintenance | Core and extension updates, backups, certificates, monthly report | Minor release on the first Monday of each month (Shopware) | Number of extensions, scope of testing |
| Security updates | Patch and security releases, security plugin, dependencies | On demand, without prior notice (Shopware) | Custom development, distance to the current version |
| Monitoring | Availability, error logs, background jobs, certificate expiry | Continuous | Number of monitored processes and integrations |
| Emergency allowance | Incidents, attack aftermath, errors after third-party changes | Unplanned | Response time, service hours |
| Upgrade reserve | Major version, PHP switch, replacing extensions | Major version once a year (Shopware) | Custom development, number of extensions |
Base maintenance, security updates and monitoring belong in the monthly flat fee of a maintenance contract, because their scope can be derived from how the shop is built. The emergency allowance and the upgrade reserve are separate budget lines: the allowance covers work outside the agreed scope, the reserve covers the move to a new major version. Squeezing both into the flat fee means either paying permanently for a buffer that is rarely used or facing the first major update without funds. Which tasks the hosting provider handles at server level and which sit with maintenance is explained in Hosting provider or maintenance.
Release cadence as the baseline load
The vendor sets the first driver. For self-hosted shops and PaaS installations, Shopware states that minor releases occur monthly, on the first Monday of every month (Shopware). Major versions with deeper changes arrive once a year, patch releases on demand and without prior notice (Shopware). That makes twelve minor releases a year a given, before a single patch is added.
The release notes show how dense this cadence is in practice. Between major version 6.7.0.0 on June 17, 2025 and version 6.7.15.1 on October 7, 2026, the 6.7 line saw 40 versions in total: one major version, 15 minor releases and 24 patch releases (Shopware). Each of them calls for a decision: install and test, bundle it with the next version, or skip it deliberately and record the reason.
For minor and patch updates, the vendor gives a sober assessment: they necessitate testing but generally do not bring changes that break existing code (Shopware). That names the cost block. It is not the update itself that takes time but the testing afterward. The smaller each version, the larger the share of testing in the total effort, and the more an automated check of revenue-critical processes pays off. How such tests are set up is shown in the article on update testing and regressions.
An older major version does not stand still either. Once the next major version is out, the last minor version of a line enters extended support with selective bug fixes and security updates (Shopware). In the 6.6 line, version 6.6.10.0 was followed by 29 more patch releases up to 6.6.10.29 (Shopware). Staying on an older line saves the jump, but not the cadence.
Besides the shop system, other deadlines add to the baseline load. TLS certificates issued since March 15, 2026 may be valid for 200 days at most; from March 15, 2027 the limit drops to 100 days (CA/Browser Forum). From then on, every certificate has to be renewed after 100 days at the latest, and every renewal has to work, including on domains for images, integrations or test systems. It remains a small item as long as renewal runs automatically and is monitored.
Rule of thumb for the baseline load
Cost driver: extensions
Every extension comes with its own vendor, its own release cadence and its own statement about which Shopware versions it supports. With every core release, the same questions arise for each extension: is there a matching version, what does the changelog say, and does the feature still work after the update as it did before? With a major version, the vendor first has to adapt the extension. Until that happens, the shop waits.
That is why maintenance effort does not grow with revenue but with the number of extensions, as the vendor itself notes for major updates. Two further effects add to it. First, updates for many extensions depend on a valid license; once it lapses, access to fixes ends without anything showing up in the shop. Handling these deadlines is covered in the article on extension license expiry. Second, extensions nobody uses anymore still cause testing effort as long as they are installed.
For budget planning, an inventory therefore counts for more than an estimate. For each extension it should contain at least the following:
- Name, vendor and source
- Installed version and latest available version
- Compatibility with the current and the next Shopware major version
- License term and access to updates
- Function in the shop and affected processes, such as checkout, shipping or search
- Replacement or removal plan in case the vendor stops maintaining it
The cheapest lever lies in the inventory itself: every extension that is no longer needed and gets removed reduces testing effort from the next release on. Conversely, every new extension raises the question of who will still maintain it two years from now. The purchase price is often the smaller part; maintaining it across all the releases that follow usually costs more.
Cost driver: custom development
In a shop, custom development means self-written plugins, a custom theme, overridden templates in the storefront and in emails, custom rules and flows. No vendor adapts this code to new versions. Either maintenance does it or nobody does. Shopware defines breaking changes as modifications that require developers to adjust their existing code to maintain compatibility (Shopware). Such changes mostly arrive with the annual major version.
The vendor announces them in advance. Deprecated features still work in the current version but are marked for removal in subsequent releases (Shopware). For custom code, each of these markers is a task on the list before the next jump. Working through them during the year spreads the effort over many small steps. Leaving them alone piles them up for the upgrade.
Overridden templates are an underestimated part of custom development. A theme that replaces individual storefront blocks and custom email templates do not automatically pick up improvements to the core. After an update, someone has to compare whether the original template has changed in a way the custom version lacks. The effort rises with the number of overridden spots, not with their size.
This driver becomes measurable through three figures from your own setup: the number of custom plugins, the number of overridden templates and the share of processes covered by an automated test. The higher the test coverage, the less each release costs, because the check does not have to be repeated by hand every time. A sound Shopware update strategy therefore separates core, extensions and custom code from the start.
Cost driver: integrations
Integrations connect the shop with ERP systems, payment providers, carriers, marketplaces and newsletter tools. Each of them is a path on which data crosses the shop's boundary, and each of these paths can behave differently after an update. Are orders still handed over completely, do payment confirmations arrive, do stock levels and prices match after synchronization? No functional test in the frontend checks that.
With integrations, two sides change. The shop follows its vendor's cadence, the partner system its own. Payment providers deprecate old versions of their APIs, ERP vendors change data formats, carriers switch procedures. Which deadlines to watch is described in the article on payment APIs and deprecations.
Integrations also tend to fail quietly. An export that does not run overnight produces no error page, just orders the next morning that did not reach the warehouse. For the budget, this means every integration needs a test path after every update and monitoring in operation, for example of background jobs, queues and reconciliation counts. That is part of monitoring and grows with the number of connected systems.
A simple calculation is enough for planning: the number of integrations times the number of test paths per integration gives the checks per release. Each integration also needs a named contact on the other side, because an error at the boundary can rarely be fixed from one side alone.
Cost driver: response time
Response time is the driver you choose most directly, and the one that shifts the price most visibly. A round-the-clock commitment requires someone who knows the shop to be reachable at night, on weekends and on public holidays. A first response on business days does not. The difference between response and resolution matters: response time says when someone starts working on the problem, not when it is fixed. What such a commitment means in practice is explained in Response time SLA: what good emergency support delivers.
In our tiers, this driver shows up directly in the price. The Basic SLA costs €199 net per month with response during service hours, Mon–Fri 9 am–6 pm, the Business SLA €349 with prioritized response, the Enterprise SLA €699 with top priority, each within service hours; your quote sets out the response times. All prices are net plus VAT with a minimum term of 6 months, then cancelable monthly; prices as of September 2026 (pricing overview). Updates, monitoring, backups and the monthly report are included in every tier. The price difference lies in priority, response time and update cadence, not in the size of the product range.
Which tier fits depends less on the size of the shop than on when revenue comes in and what an hour of downtime costs. A shop that receives many orders in the evening and on weekends needs standby at those times. A B2B shop with orders during office hours can manage with a business-day commitment, provided monitoring also alerts at night. How to work out the value of an hour of downtime is shown in the article on the cost of shop downtime; the tiers in detail, all with response during service hours, Mon–Fri 9 am–6 pm, are on the SLA maintenance contract page.
The emergency allowance for the unplanned
Part of maintenance defies any planning. According to the 2025 situation report of the German Federal Office for Information Security, an average of 119 new vulnerabilities per day became known worldwide in the reporting period (BSI), around 24 percent more than in the previous reporting period, partly due to methodological effects (BSI). The figure covers all IT products and affects a single shop only to a small extent. But every chain of advisory, assessment, update and test starts with such a report, and its timing cannot be predicted.
For Shopware there is a security plugin that backports fixes to existing installations. It explicitly does not replace regular updates (Shopware). It does not cover vulnerabilities in dependencies such as Symfony or Twig; those still require an update of the dependency or of Shopware itself (Shopware). How security updates are scheduled in day-to-day maintenance is described on the security updates page.
The emergency allowance is therefore not a substitute for the flat fee but its counterpart for work outside the agreed scope: errors after third-party changes, the aftermath of an attack, interventions during a campaign. Without a contract, we charge €95 net per hour for individual assignments, billed in 15-minute increments, without a committed response time (pricing overview). Under a maintenance contract, emergency support is included in every tier with the agreed response time; anything beyond that belongs in the allowance. The emergency support page describes how an assignment runs.
The size of the allowance can be derived from your own history: how many unplanned assignments were there last year, how long did they take, and which of them fell outside what a contract covers? Without that history, a small allowance reviewed quarterly makes more sense than a large one that expires unused.
A reserve for the next version jump
The most expensive single item in maintenance is rarely an emergency but the next major version. Shopware releases it once a year, accompanied by a release candidate that is typically available about two months earlier (Shopware). Support phases do not follow a fixed calendar: support transitions are tied to major releases, not fixed timelines (Shopware). The reserve should therefore be built up over the year, not in the month of the upgrade.
How large it needs to be depends on the same drivers as base maintenance, only more so: every extension needs a version for the new major release, every custom plugin needs adapting, every integration needs a full test. In our pricing, the major upgrade is therefore not part of the monthly flat fee but a fixed price after analysis, whose scope depends on the starting version and the extensions. That makes the item predictable once the analysis is done and keeps it out of the monthly amount.
In 2027, the reserve also has to cover the scripting language. Each PHP branch receives two years of active support (The PHP Group), followed by two additional years of fixes for critical security issues only (The PHP Group). Shopware requires at least PHP 8.2 and recommends PHP 8.4 (Shopware). Security updates for PHP 8.2 end on December 31, 2026 (The PHP Group); on the same day, active support for PHP 8.4 ends, which then receives security fixes until December 31, 2028 (The PHP Group). A switch affects the server, the core and every extension and needs its own test run. The process is described in the article on PHP EOL management.
Postponing is possible, but not free. The security plugin is explicitly meant to bridge the time until a proper update (Shopware), and an older line in extended support receives only selected fixes. Postponing the jump moves the reserve into the next year and usually makes it larger, because deprecated features and outdated extension versions keep piling up.
Internal capacity as a cost factor
Besides money, capacity counts, and it is often scarcer. Germany is short of 79,000 IT specialists (Bitkom). Among companies with open IT positions, 26 percent (Bitkom) are looking for specialists in IT administration and systems operations; no other area is named more often. The figures are based on surveys of 853 and 602 companies with 3 or more employees in Germany (Bitkom). For shop maintenance, this means: whoever plans it in-house is planning around a role in particularly high demand on the job market, and needs a backup for vacation and sick leave who also knows the shop.
An external maintenance contract shifts this question but does not fully answer it. Even then, the shop needs someone internally who sets priorities, approves changes and coordinates maintenance windows with sales and marketing. That share belongs in the budget as internal time, even if it does not appear on any invoice.
How to arrive at the budget figure for 2027
The drivers turn into a figure when you capture them in a fixed order. The following steps can be completed in November and provide a basis that makes any quote traceable.
Build the inventory
Record extensions, custom plugins, overridden templates, integrations and server components with version, vendor and owner.
Enter the deadlines
Transfer minor releases, PHP deadlines, extension license end dates and certificate terms into a calendar for 2027.
Measure effort per release
Follow one update with timestamps: staging, test, sign-off, go-live, check. The total is the basis for base maintenance.
Choose the response time
Note when revenue comes in and what an hour of downtime costs, and derive the service hours you need from that.
Set allowance and reserve
Emergency allowance based on last year's incidents, reserve for the major version and PHP switch as separate budget lines.
Review quarterly
Compare planned and actual hours and adjust the allowance or tier before the gap grows large.
Record extensions, custom plugins, overridden templates, integrations and server components with version, vendor and owner.
Transfer minor releases, PHP deadlines, extension license end dates and certificate terms into a calendar for 2027.
Follow one update with timestamps: staging, test, sign-off, go-live, check. The total is the basis for base maintenance.
Note when revenue comes in and what an hour of downtime costs, and derive the service hours you need from that.
Emergency allowance based on last year's incidents, reserve for the major version and PHP switch as separate budget lines.
Compare planned and actual hours and adjust the allowance or tier before the gap grows large.
A maintenance quote can then be measured against a few questions. They show whether the provider knows the drivers of your shop or is only offering an average:
- Which updates are included in the flat fee, and at what cadence are they installed?
- Is there testing on a staging environment before go-live, and which processes does the test cover?
- Which response time applies during which service hours, and how is work outside them billed?
- How are the major version and the PHP switch priced, as a fixed price or by effort?
- What minimum term applies, and can the tier be changed?
- What does the monthly report contain, and who receives it?
What the monthly flat fee covers
In our model, the monthly price covers planned operations; anything one-off is billed at a fixed price stated in advance. The flat fee includes tested updates, round-the-clock monitoring, verified backups, certificate management, the monthly report and incident handling during service hours with the agreed response time. Not included are new features and integrations that go beyond fixing errors, the upgrade to a new major version, and third-party license and hosting fees, which we pass on without a markup.
The calculation is thus split in two: the flat fee follows the drivers extensions, custom development, integrations and response time; the emergency allowance and the reserve sit next to it as separate lines. Knowing the drivers of your shop lets you check any quote against them and tells you in advance where the budget will grow. The initial assessment is free of charge with us; we only quote fixed prices after we have seen the system.
Related Articles
White-Label Maintenance for Agency Client Sites
Agencies build shops, then care slips. How white-label maintenance works: cooperation models, SLA boundaries, tenant separation and reports in your own brand.
Anchor Performance Monitoring in Your Maintenance SLA
Make performance monitoring a fixed SLA component: performance budgets, alerts, monthly reports and regression watch for consistently fast online shops.
Maintenance Contract: Key Contents
Maintenance contract for online shops and websites: SLA tiers, included services, response times, pricing models and the contract clauses worth reading twice.