Shopware-Wartung nach dem Go-Live: Wie Agenturen und Freelancer Support und SLAs aufsetzen
Der Shop ist live, die Rechnung ist gestellt, das Projektteam löst sich auf — und dann kommt die erste Ticket-Mail: „Der Checkout wirft seit heute einen Fehler." Wartung ist der Teil eines Shopware-Projekts, über den beim Angebot am wenigsten gesprochen wird und der am längsten dauert. Genau deshalb entstehen hier die meisten Reibungen zwischen Agentur und Freelancer. Wer die Betriebsphase vorher als eigene Leistung definiert, statt sie als kostenlosen Nachklapp zu behandeln, verdient nicht nur planbarer, sondern liefert auch bessere Shops ab.
1. Wartung ist eine eigene Projektphase — keine Kulanz
Der häufigste Fehler ist die stillschweigende Annahme, mit dem Go-Live sei das Projekt „fertig". Ein produktiver Shop ist aber ein lebendes System: Shopware veröffentlicht regelmäßig neue Versionen, Drittanbieter-Plugins ziehen nach, Zahlungsdienstleister ändern APIs, und das Warenwirtschaftssystem des Kunden bekommt sein eigenes Update. Nichts davon steht im ursprünglichen Angebot, und trotzdem landet es früher oder später auf dem Tisch. Wenn die Betriebsphase nicht als eigene, bezahlte Leistung definiert ist, passiert eines von zwei Dingen: Entweder arbeitet der Freelancer unbezahlt, um den Kunden der Agentur nicht zu verärgern — oder Sicherheitslücken bleiben offen, weil sich niemand zuständig fühlt. Beide Ergebnisse sind schlecht. Der saubere Weg ist, die Wartung schon im ersten Angebot als separaten Block auszuweisen, damit klar ist, dass „Support" nicht gleichbedeutend mit „gratis für immer" ist.
2. Was Shopware-Wartung technisch wirklich umfasst
Der wichtigste Treiber ist die Update-Politik von Shopware selbst. Laut der offiziellen Release Policy erscheint pro Jahr ein neues Major-Release, dazu monatlich ein Minor-Release (jeweils am ersten Montag) und Patches nach Bedarf. Aktiv mit Bug- und Sicherheitsfixes unterstützt wird immer nur die jeweils neueste Minor-Version; ältere Stände fallen in „Extended Support" und danach in „Security Fixes only", die dann nur noch über das Security-Plugin nachgeliefert werden. Für die Praxis heißt das: Ein Shop, den niemand pflegt, verliert innerhalb weniger Monate den Anschluss an die aktiv gewartete Version. Zur Wartung gehören deshalb konkret: das Einspielen von Security-Updates, das Nachziehen der eingesetzten Plugins auf kompatible Stände, das kontrollierte Anheben der shopware/core-Version über Composer, sowie regelmäßige Backups und ein Monitoring, das meldet, bevor der Kunde anruft. Das ist kein „Wenn was ist"-Geschäft, sondern planbare, wiederkehrende Arbeit.
3. Retainer oder On-Demand: die zwei tragfähigen Modelle
Für die Abrechnung haben sich zwei Modelle bewährt, und beide sind sauberer als das übliche „wir schreiben dann Stunden, wenn was ist". Der Retainer ist ein festes monatliches Stundenkontingent — etwa vier bis zwölf Stunden, je nach Shop-Größe —, das planbare Aufgaben wie Updates, kleine Anpassungen und Monitoring abdeckt. Der Vorteil liegt auf beiden Seiten: Der Kunde hat ein festes Budget, der Dienstleister eine planbare Grundauslastung, und nicht verbrauchte Stunden lassen sich für einen Monat mitnehmen, statt sie verfallen zu lassen. Das On-Demand-Modell mit vorab vereinbartem Stundensatz und kurzer Reaktionszeit passt für kleinere Shops, bei denen ein festes Kontingent überdimensioniert wäre. Der Haken beim On-Demand: Ohne definierte Reaktionszeit ist es kein Wartungsvertrag, sondern eine unverbindliche Absichtserklärung. Wie man den grundsätzlichen Zuschnitt — Festpreis, Stunden oder Kontingent — kalkuliert, habe ich im Detail unter Festpreis oder Stundensatz beschrieben.
4. Das SLA: Reaktionszeit ist nicht Lösungszeit
Der Begriff, an dem die meisten Wartungsverträge scheitern, ist das Service Level Agreement — und zwar weil zwei Dinge verwechselt werden. Die Reaktionszeit ist die Zeit, bis sich jemand des Tickets annimmt und eine erste Einschätzung gibt. Die Lösungszeit ist die Zeit bis zur Behebung. Ein Freelancer kann realistisch eine Reaktionszeit garantieren; eine feste Lösungszeit für jedes denkbare Problem kann er es nicht, weil manche Ursachen bei Drittanbietern oder beim Hosting liegen. Sinnvoll ist eine Staffelung nach Schweregrad: Ein Shop-Ausfall oder ein kaputter Checkout ist kritisch und braucht eine Reaktion innerhalb weniger Stunden am selben Werktag; ein optischer Fehler im Footer ist es nicht. Genauso wichtig sind die Rahmenbedingungen: Gelten die Zeiten nur zu Geschäftszeiten oder auch am Wochenende? Wer 24/7-Bereitschaft verspricht, muss sie auch leben können — für einen einzelnen Freelancer ist das selten realistisch und gehört ehrlich adressiert, nicht ins Kleingedruckte versteckt.
5. Die Rollenverteilung zwischen Agentur und Freelancer
In der Betriebsphase wird die Frage „Wer redet mit dem Kunden?" plötzlich entscheidend. In den meisten Konstellationen hält die Agentur den Kundenkontakt, der Freelancer arbeitet im Hintergrund. Das funktioniert nur, wenn der Meldeweg eindeutig ist: Ein Ticket-System oder ein geteilter Kanal, in dem Anfragen landen, statt dass Bugs per Zuruf zwischen drei WhatsApp-Chats verloren gehen. Kritisch ist die Eskalationskette — wer entscheidet bei einem Notfall am Sonntag, ob sofort gehandelt wird, und wer trägt die Kosten dafür? Das gehört vor den ersten Vorfall geklärt, nicht danach. Ebenso praktisch, aber oft vergessen: Zugänge. Der Freelancer braucht dauerhaften, dokumentierten Zugriff auf Repository, Staging, Deployment und Server — sonst beginnt jeder Wartungseinsatz mit einer halben Stunde Passwortsuche. Wer als Agentur einen zuverlässigen Wartungspartner sucht, findet in den Kriterien für einen Shopware-Plugin-Entwickler die gleichen Signale, die auch für den Dauerbetrieb zählen.
6. Werkzeuge und Prozess: Updates ohne Bauchschmerzen
Der Unterschied zwischen entspannter und nervenaufreibender Wartung liegt im Prozess, nicht im Können. Kein Shopware-Update wandert direkt auf die Produktivumgebung. Der Standardablauf lautet: Update auf einem Staging-System einspielen, das eine echte Kopie der Produktivdaten ist, dort die kritischen Pfade prüfen — Checkout, Zahlung, Kundenkonto, die individuell gebauten Funktionen — und erst nach bestandener Prüfung produktiv gehen. Bei composer-verwalteten Shops ist das planbar: Der Versionssprung passiert kontrolliert über die composer.json, nicht per Klick im Backend, und lässt sich im Zweifel per Git zurückrollen. Dazu gehören ein automatisiertes Backup vor jedem Update, ein Monitoring, das Ausfälle und Fehlerraten meldet, und eine kurze Kompatibilitätsmatrix der eingesetzten Plugins, damit man vor dem Update weiß, welches Plugin auf der Zielversion noch nicht freigegeben ist. Genau diese Matrix erspart die böse Überraschung, dass ein Kern-Update den halben Shop lahmlegt, weil ein einziges Drittanbieter-Plugin noch nicht nachgezogen hat.
7. Fazit: Betrieb ist der Teil, der Vertrauen aufbaut
Ein Shop wird nicht im Projekt bewertet, sondern im Betrieb. Genau dort entscheidet sich, ob eine Agentur den Freelancer beim nächsten Projekt wieder holt und ob der Endkunde bleibt. Wartung ist deshalb kein lästiger Anhang, sondern die längste und beziehungsprägendste Phase eines Shopware-Projekts. Wer sie vorher definiert — als eigene Leistung, mit klarem Modell, ehrlichem SLA und dokumentiertem Update-Prozess —, spart sich die immer gleichen Konflikte und liefert nebenbei einen Shop, der auch in zwei Jahren noch sicher und aktuell läuft. Das Kunststück liegt nicht in der Technik des Updates, sondern darin, den Betrieb vom ersten Angebot an mitzudenken, statt ihn zu verdrängen, bis die erste Ticket-Mail kommt.
Du brauchst einen verlässlichen Wartungspartner für Shopware 6?
Lass uns in 30 Minuten klären, wie ein Wartungsmodell aussieht, das zu deinem Shop und deiner Agentur passt — Retainer oder On-Demand, mit ehrlichem SLA. Kein Sales-Call.