Shopware-Wartung: Was ein Retainer leisten muss
Shopware-Wartung ist mehr als Updates und Tickets. So verbinden wir Betrieb, SLA und Weiterentwicklung im Retainer mit unserem F.O.C.U.S.-System.
Professionelle Shopware-Wartung umfasst sechs Bausteine: Monitoring und Alerting, Security- und Versions-Updates, Plugin- und Schnittstellenpflege, Backups mit getesteter Wiederherstellung, priorisierte Bugfixes mit SLA und laufende technische Pflege. Ein Retainer bündelt diese Leistungen mit verbindlich reservierter Kapazität — bei uns, je nach Shopgröße, Individualcode und SLA, ab rund 1.000 Euro monatlich.
Denn ein Shopware-Shop ist nach dem Go-live nicht fertig. Er ist ab diesem Tag ein produktives System: Shopware veröffentlicht Updates, Erweiterungen verändern sich, Schnittstellen liefern neue Sonderfälle und das Geschäft entwickelt neue Anforderungen. Gleichzeitig erwarten Kunden, dass Suche, Checkout, Payment und Bestellübertragung jederzeit funktionieren.
Genau dafür braucht es Wartung. Doch der Begriff wird sehr unterschiedlich verwendet. Bei einem Anbieter bedeutet er lediglich, dass bei Bedarf jemand ein Ticket liest. Bei einem anderen umfasst er Updates, Monitoring und eine bestimmte Zahl an Entwicklungsstunden. Das macht Angebote schwer vergleichbar.
Dieser Beitrag zeigt, was ein belastbarer Shopware-Wartungsvertrag enthalten sollte, was ein Retainer davon unterscheidet und welche Optionen Kunden bei nuonic für die laufende Weiterentwicklung haben. Der entscheidende Punkt ist: Wartung hält nicht nur den heutigen Zustand am Leben. Richtig organisiert schafft sie die technische und organisatorische Grundlage, um den Shop kontrolliert weiterzuentwickeln.
Shopware-Wartung, Support und Retainer: der Unterschied
Die drei Begriffe beschreiben unterschiedliche Ebenen derselben Verantwortung: Wartung beugt Risiken vor und pflegt den technischen Stand, Support reagiert auf Störungen mit definierten Reaktionszeiten, und ein Retainer reserviert verbindliche Kapazität für beides — optional ergänzt um planbare Weiterentwicklung. Ein Retainer ist damit kein vorab bezahlter Stundenblock, sondern ein Verantwortungsmodell.
| Begriff | Aufgabe | Typische Inhalte |
|---|---|---|
| Wartung | Risiken vorbeugen und den technischen Stand pflegen | Security-Patches, Shopware-Updates, Plugin-Kompatibilität, Backups, technische Pflege |
| Support | Auf Störungen und konkrete Fragen reagieren | Fehleranalyse, Bugfixes, Incident-Kommunikation, definierte Reaktionszeiten |
| Retainer | Verbindliche Kapazität und Zusammenarbeit reservieren | Wartung und Support, optional ergänzt um planbare Weiterentwicklung |
Ein Retainer ist damit nicht einfach ein vorab bezahlter Stundenblock. Sein Wert liegt in der Verbindlichkeit: Ein Team kennt das System, verfolgt seinen Zustand, hält Kapazität vor und arbeitet nach einem vereinbarten Rhythmus. Das reduziert Einarbeitung, Abstimmung und die Wartezeit bis zur ersten sinnvollen Maßnahme.
Auch ein Retainer braucht klare Grenzen. Eine neue ERP-Integration ist kein kleiner Wartungsfall. Ein kritischer Checkout-Fehler sollte umgekehrt nicht im normalen Feature-Backlog verschwinden. Leistungsumfang, Prioritäten, Reaktionszeiten und der Umgang mit größeren Vorhaben gehören deshalb ausdrücklich ins Betriebsmodell.
Was zu professioneller Shopware-Wartung gehört
Ein Shop kann von außen erreichbar sein und intern trotzdem immer riskanter werden. Veraltete Plugins, fehlgeschlagene Queue Jobs oder wachsende Fehlerprotokolle fallen häufig erst auf, wenn Umsatz betroffen ist. Gute Wartung verbindet deshalb Prävention, Beobachtung und Reaktion in sechs Bausteinen: Monitoring und Alerting, Security- und Versions-Updates, Plugin- und Schnittstellenpflege, Backups und Wiederherstellung, Bugfixes mit SLA sowie laufende technische Pflege.
Monitoring und Alerting
Ein einfacher Uptime-Check reicht nicht. Abhängig vom System gehören auch Antwortzeiten, Fehlerraten, Queue Worker, Cronjobs, Speicher, Zertifikate und geschäftskritische Prozesse in die Überwachung. Das Ziel ist nicht, jede Abweichung zum Alarm zu machen, sondern die Signale zu erkennen, die für Kunden oder Betrieb relevant werden.
Security- und Versions-Updates
Sicherheitskorrekturen brauchen einen anderen Rhythmus als ein großes Funktionsupdate. Zu jedem Update gehören mindestens die Prüfung der Abhängigkeiten, ein Test in Staging, ein Backup mit Rückfallweg und die Nachkontrolle nach dem Deployment. Auch Shopware selbst empfiehlt in seiner Update-Dokumentation eine Testumgebung, aktuelle Backups und die Prüfung der Erweiterungskompatibilität vor dem Update.
Plugin-, Theme- und Schnittstellenpflege
Ein Shopware-Shop besteht selten nur aus dem Core. Payment, Versand, ERP, PIM, Suche, Tracking und individuelle Plugins bilden ein Abhängigkeitsnetz. Wartung muss dieses Netz berücksichtigen. Ein grüner Core-Update-Check beweist noch nicht, dass der komplette Bestellprozess funktioniert.
Backups und Wiederherstellung
„Backup vorhanden“ und „System wiederherstellbar“ sind nicht dasselbe. Es muss klar sein, welche Daten und Dateien gesichert werden, wie lange die Wiederherstellung dauert und wer sie im Ernstfall ausführt. Ein Rollback ist Teil des Deployments, nicht die spontane Idee nach einem Fehler.
Bugfixes mit Priorität und SLA
Nicht jeder Fehler ist ein Notfall. Ein defekter Checkout braucht eine andere Reaktion als ein kosmetischer Abstand im Kundenkonto. Unser Shopware-Support mit Wartung und SLA arbeitet deshalb mit Störungsklassen und definierten Reaktionszeiten. So ist vor dem Ernstfall geklärt, was kritisch ist und wer handelt.
Technische Pflege
Logs bereinigen, Deprecations abbauen, Tests ergänzen, langsame Abfragen analysieren und Dokumentation aktualisieren: Diese Arbeit ist wenig sichtbar, entscheidet aber darüber, ob das nächste Update Routine oder Rettungsprojekt wird. Technische Schulden verschwinden nicht durch einen Wartungsvertrag. Sie werden damit sichtbar und priorisierbar.
Warum Support auf Zuruf langfristig teuer wird
Einzelbeauftragungen wirken zunächst flexibel, verschieben die Kosten bei einem geschäftskritischen Shop aber an die ungünstigste Stelle: in den Störfall. Niemand verfolgt kontinuierlich Update-Stand und Warnsignale, vor jeder Änderung muss sich ein Team neu einarbeiten, und Kapazität fehlt genau dann, wenn der Fehler dringend ist. Dazu kommen zwei schleichende Effekte:
- Kleine Risiken bleiben liegen, bis sie gemeinsam ein großes Problem bilden.
- Wartung, Features und strategische Wünsche konkurrieren in einer ungeklärten Liste.
Ein Retainer ersetzt nicht jede Einzelentscheidung. Er schafft aber einen verbindlichen Rahmen, in dem Entscheidungen mit Systemkenntnis getroffen werden. Das ist der Unterschied zwischen „jemand kann Tickets bearbeiten“ und „ein Team übernimmt laufend Verantwortung“.
F.O.C.U.S.: Wartung mit Richtung statt Ticket-Fließband
Unser F.O.C.U.S.-System beginnt nicht mit einer pauschalen Monatszahl. Es verbindet den sicheren Betrieb mit messbarer Weiterentwicklung. Die fünf Phasen — Facts, Objectives, Constraints, Execution und Scaling — werden nach einem Go-live nicht abgelegt, sondern bilden einen wiederkehrenden Steuerungskreis: vom belastbaren Zustandsbild über messbare Ziele und explizite Grenzen zu kontrollierten Releases und dem nächsten Verbesserungszyklus.
F — Facts: den tatsächlichen Zustand kennen
Beim Einstieg prüfen wir Versionen, Individualcode, Erweiterungen, Infrastruktur, Deployments, Monitoring, Backups, Tests und offene Fehler. Dazu kommen fachliche Fakten: Welche Prozesse tragen Umsatz? Wo entsteht manuelle Arbeit? Welche Störungen gab es bereits?
Das Ergebnis ist keine allgemeine Checkliste, sondern ein Zustandsbild des konkreten Systems. Bei der Übernahme eines fremdentwickelten Shops beginnt die Zusammenarbeit deshalb mit einem Code- und System-Audit.
O — Objectives: Betrieb und Wirkung gemeinsam definieren
„Der Shop soll laufen“ ist notwendig, aber nicht messbar genug. Ziele können Verfügbarkeit, kürzere Ladezeiten, weniger Checkout-Fehler, schnellere Deployments oder weniger manuelle Auftragsarbeit sein. So erhält auch die Weiterentwicklung eine Richtung: Maßnahmen konkurrieren nach Wirkung, nicht nach Lautstärke des jüngsten Tickets.
C — Constraints: Grenzen früh sichtbar machen
Budget, Teamkapazität, alte Plugins, fehlende Tests, Releasefenster und ERP-Abhängigkeiten begrenzen jede Roadmap. Wir machen diese Grenzen explizit. Das verhindert, dass ein scheinbar kleines Feature unbemerkt ein Update blockiert oder ein Wartungsbudget mit einem Integrationsprojekt überladen wird.
U — Execution: kleine, kontrollierbare Releases
Updates, Bugfixes und Verbesserungen laufen über denselben nachvollziehbaren Weg: priorisieren, umsetzen, prüfen, ausrollen und beobachten. Je nach Umfang entsteht daraus ein Wartungsrelease, ein Entwicklungssprint oder ein eigenes Projekt. Unsere Seite zur Shopware-Entwicklung zeigt, wie wir Individualfunktionen und Integrationen umsetzen.
S — Scaling: aus Betriebserfahrung besser werden
Monitoring, Supportfälle und Nutzungsdaten liefern neue Facts. Häufige Fehlerursachen können automatisiert, langsame Prozesse optimiert und wirksame Funktionen ausgebaut werden. Damit wird Wartung zur Grundlage für Optimierung und Wachstum, statt nur den Status quo zu konservieren.
Drei Optionen für die Weiterentwicklung bei nuonic
Nicht jeder Shop braucht dauerhaft dieselbe Entwicklungskapazität. Deshalb trennen wir die verbindliche Betriebsbasis von der passenden Form der Weiterentwicklung — mit drei Modellen: dem reinen Wartungs-Retainer für sicheren Betrieb, Wartung plus laufender Weiterentwicklung für ein kontinuierliches Backlog und einem eigenständigen Projekt für größere Entwicklungsschritte.
Option 1: Wartungs-Retainer für sicheren Betrieb
Dieses Modell passt zu stabilen Shops, deren fachlicher Funktionsumfang sich nur gelegentlich verändert. Der Schwerpunkt liegt auf Monitoring, Security- und Shopware-Updates, Fehlerbehebung und vereinbarten Reaktionszeiten. Kleinere Anpassungen lassen sich priorisiert einplanen; größere Vorhaben werden separat bewertet.
Unsere Wartungsmodelle beginnen – abhängig von Shopgröße, Individualcode und SLA – bei rund 1.000 Euro monatlich. Die Einordnung weiterer Lizenz-, Projekt- und Betriebskosten steht auf unserer Seite zu Shopware-Kosten.
Option 2: Wartung plus laufende Weiterentwicklung
Dieses Modell eignet sich, wenn neben dem Betrieb kontinuierlich ein relevantes Backlog bearbeitet werden soll. Zusätzlich zur Wartungsbasis reservieren wir planbare Entwicklungskapazität. Sie kann beispielsweise in Conversion-Verbesserungen, Automatisierung, neue Shop-Funktionen, Schnittstellenpflege oder Performance fließen.
F.O.C.U.S. hält dabei Betrieb und Produktarbeit in einem gemeinsamen System: Risiken bleiben sichtbar, Ziele werden priorisiert und Änderungen gelangen in kontrollierten Releases live. Der Vorteil gegenüber wechselnden Einzelaufträgen ist der erhaltene Kontext. Das Team, das Fehlerbilder und Architektur kennt, entwickelt auch die nächste Funktion.
Option 3: Eigenständiges Projekt für einen größeren Entwicklungsschritt
Eine ERP-Anbindung, ein B2B-Portal, ein Replatforming oder ein neues Storefront-Konzept sollte nicht künstlich in ein kleines Monatskontingent gedrückt werden. Solche Vorhaben erhalten eigene Ziele, Budget, Roadmap und Abnahmekriterien. Der bestehende Wartungs-Retainer sichert währenddessen den laufenden Betrieb.
Nach dem Go-live kann das Ergebnis wieder in die reguläre Betreuung übergehen. Wie diese Verbindung über mehrere Jahre funktioniert, zeigen unter anderem unsere COMSPOT Case Study und die Xucker Case Study.
Welches Modell passt zu welchem Shop?
Die Kurzantwort: Ein stabiler Shop ohne großes Backlog braucht den Wartungs-Retainer, ein dauerhaft priorisiertes Backlog die Kombination aus Wartung und Weiterentwicklung, ein klar abgegrenzter größerer Schritt ein eigenständiges Projekt mit laufender Wartung — und ein unklarer Zustand nach einem Agenturwechsel zuerst ein System-Audit. Die Zuordnung im Überblick:
| Situation | Sinnvoller Einstieg |
|---|---|
| Der Shop ist stabil, Updates und Reaktionszeiten sollen geregelt sein | Wartungs-Retainer |
| Es gibt dauerhaft ein priorisiertes Backlog | Wartung plus Weiterentwicklungs-Retainer |
| Ein klar abgegrenzter, größerer Entwicklungsschritt steht an | Eigenständiges Projekt plus laufende Wartung |
| Eine andere Agentur hat den Shop gebaut und der Zustand ist unklar | System-Audit, Stabilisierung, dann passende Retainer-Stufe |
Das Modell darf sich verändern. Nach einem größeren Projekt kann mehr Kapazität für Stabilisierung sinnvoll sein; in einer Wachstumsphase kann ein laufender Entwicklungsrhythmus wichtiger werden. Entscheidend ist, dass Leistungsumfang und Verantwortung bewusst angepasst werden – nicht erst, wenn das Budget oder die Technik bereits unter Druck stehen.
Und wenn der Weg zum passenden Modell über einen neuen Partner führt: Wie der Wechsel im laufenden Wartungsprojekt strukturiert gelingt, beschreibt unser Whitepaper mit Phasenmodell, Asset-Inventar und Übergabe-Checkliste.
Woran ein guter Wartungsvertrag zu erkennen ist
Ein guter Wartungsvertrag beantwortet zehn Fragen konkret — von den enthaltenen Systemen über Monitoring, Update-Verfahren und Reaktionszeiten je Störungsklasse bis zu Berichtswesen, Vertretung und messbaren Kennzahlen. Fehlen klare Antworten, wird häufig nur Verfügbarkeit verkauft, nicht Verantwortung. Vor der Unterschrift sollten mindestens diese Fragen beantwortet sein:
- Welche Systeme, Erweiterungen und Umgebungen sind enthalten?
- Was wird überwacht und wer erhält welche Alarme?
- Wie werden Security-, Minor- und Major-Updates behandelt?
- Welche Reaktionszeiten gelten je Störungsklasse?
- Wie funktionieren Backup, Wiederherstellung und Rollback?
- Welche Leistungen sind Wartung, welche Weiterentwicklung?
- Wie werden Prioritäten, Kapazität und offene Risiken berichtet?
- Wer arbeitet tatsächlich am System und wie ist Vertretung geregelt?
- Wie werden größere Vorhaben aus dem Retainer herausgelöst?
- Welche Kennzahlen zeigen, ob Betrieb und Entwicklung besser werden?
Fazit: Der Retainer ist das Betriebssystem der Zusammenarbeit
Shopware-Wartung schützt Umsatz, Daten und Handlungsfähigkeit. Ein guter Retainer macht daraus eine verlässliche Zusammenarbeit: mit Systemkenntnis, reservierter Kapazität, transparenten Prioritäten und einem klaren Weg von der Störung zur Verbesserung.
F.O.C.U.S. verbindet diese Ebenen. Facts verhindern Blindflug, Objectives geben der Weiterentwicklung Richtung, Constraints schützen vor falschen Zusagen, Execution bringt Änderungen kontrolliert live und Scaling macht aus Betriebsdaten den nächsten Verbesserungszyklus.
So bleibt der Kunde flexibel: nur verbindlicher Betrieb, Betrieb plus laufende Weiterentwicklung oder ein eigenständiges Projekt für den nächsten großen Schritt. Wer den aktuellen Zustand zuerst belastbar einordnen möchte, kann mit einem System-Audit und einem Wartungsmodell starten.
Offizielle Quellen
Reden wir über dein System.
Kein Pitch-Deck. Ein Gespräch mit denen, die auch bauen.