Shopware-Wartung
Shopware-Wartung heißt bei der Sharpness Solutions GmbH in Oldenburg: Jemand liest die Logs Ihres Shops, bevor Sie anrufen. Patch-Releases der laufenden 6.7-Linie werden auf einer Staging-Kopie getestet und dann deployed — aktueller Stand der Linie ist 6.7.13.0 vom 5. August 2026 —, die Plugin-Landschaft wird gegen jeden Stand nachgehalten, Datenbank, Caches, Message Queue und Suchindex stehen unter Beobachtung. Verbindlich wird das über eine Service-Level-Vereinbarung mit 24, 8, 4 oder 2 Stunden Reaktionszeit, als Monatspauschale netto je Shop. Wir übernehmen auch Shops, die jemand anders gebaut hat — nach dem Blick in Code und Hosting, nicht davor. Stand: 17. August 2026.
Anfragen zur Shopware-Wartung beginnen selten mit einem Ausfall. Sie beginnen damit, dass jemand nachrechnet: Das letzte Update liegt anderthalb Jahre zurück, die Composer-Datei kennt niemand mehr im Haus, und der nächtliche ERP-Import läuft — vermutlich. Der Shop verkauft dabei die ganze Zeit weiter. Genau das ist das Problem: Ein Shop meldet sich nicht, wenn er ungepflegt ist. Er meldet sich, wenn der Checkout bricht, und dann ist die Ursache Monate alt. Diese vier Punkte decken den größten Teil dessen ab, womit Betreiber hier ankommen.
Unter var/log/ stehen Fehler, die niemand ansieht: fehlgeschlagene Zahlungs-Callbacks, abgebrochene Imports, Nachrichten, die es in die Dead-Letter-Ablage der Message Queue geschafft haben, Scheduled Tasks, die seit einem Deployment nicht mehr laufen. Der Shop wirkt in Ordnung, weil die Startseite lädt. Ein Fehler, den niemand liest, ist trotzdem da — er wartet nur darauf, dass ihn der Kunde findet.
Ohne Staging-System und ohne dokumentierten Rollback ist jedes Update ein Sprung ohne Netz, also wird es verschoben. Damit wächst der Abstand zum aktuellen Stand, und mit ihm die Zahl der Arbeitsschritte, die ein Update nachholen muss: Composer-Konflikte, Plugins ohne passende Fassung, eine PHP-Version, die nicht mehr reicht. Aus einem Wartungsfenster wird irgendwann ein Projekt mit Angebot und Budgetfreigabe.
Zwanzig Erweiterungen im Shop, und für die Hälfte weiß niemand, ob sie noch benutzt wird, wer sie pflegt und wofür sie einmal gekauft wurde. Mit Shopware 6.7 ist diese Frage nicht mehr aufschiebbar: Vue 3 statt Vue 2, Vite statt Webpack, Pinia statt Vuex — jedes Plugin und jedes Custom-Theme braucht dafür eine Anpassung. Wer eine Erweiterung für 6.6 und 6.7 pflegt, braucht getrennte Releases.
Solange nichts passiert, fällt das nicht auf. Am Tag, an dem der Checkout steht, ist es die einzige relevante Frage. Ohne Vereinbarung gilt bei uns die Bearbeitung in Eingangsreihenfolge innerhalb von 48 Stunden zu den Geschäftszeiten Mo–Fr 9:00–16:00 Uhr — ehrlich, aber für einen Shop mit laufendem Bestellvolumen zu langsam. Genau dafür gibt es die Service-Level-Staffel weiter unten.
Shopware-Wartung besteht aus vier Arbeiten, die technisch wenig miteinander zu tun haben. Die erste sind Sicherheits- und Bugfix-Releases innerhalb der laufenden Linie: prüfen, ob die Installation betroffen ist, auf Staging einspielen, Backend, Checkout, Zahlarten, Mailversand und Bestelldokumente durchgehen, dann deployen. Nicht am Erscheinungstag und nicht blind — ein x.x.x.0-Release wandert bei uns nicht direkt in den Livebetrieb, weil Shopware einzelne davon nach der Veröffentlichung wieder gesperrt hat — zuletzt 6.7.12.0 vom 7. Juli 2026, nicht installierbar wegen einer Inkompatibilität mit Twig 3.28, ersetzt durch 6.7.12.1. Wir warten auf einen belastbaren Patch-Stand und ziehen ihn dann nach, statt eine Version zu überspringen und den Abstand wachsen zu lassen. Updates fahren wir über die Kommandozeile, nicht über den grafischen Updater, weil nur so nachvollziehbar bleibt, was passiert ist.
Die zweite Arbeit ist die Plugin-Kompatibilität, und sie ist die undankbarste. Zu jedem Update gehört die Frage, welche Erweiterung eine passende Fassung hat, welche noch einen Betreuer hat und welche im Shop steht, ohne benutzt zu werden. Store-Plugins, gekaufte Erweiterungen und eigener Code haben dabei drei verschiedene Lebenszyklen. Wir halten den Composer-Stand sauber statt Versionen zu pinnen, bis nichts mehr auflösbar ist, und wir führen eine Liste, die sagt: Diese Erweiterung wird gepflegt, diese wird beim nächsten Major ersetzt, diese wird deinstalliert. Eigene Plugins bauen wir gegen die Extension-Punkte von Shopware, nicht in den Core hinein — Core-Hacks sind der häufigste Grund, warum ein Shop mehrere Versionen hinterherhängt.
Die dritte Arbeit ist der Unterbau, die vierte das Hinsehen. Zum Unterbau gehören PHP- und Datenbankversion, Objekt-Cache in Redis oder Valkey, HTTP-Cache, Suchindex, Message Queue, Cronjobs, Zertifikate, Deployment-Weg und Backups mit einem Rücksicherungstest, der auch wirklich gelaufen ist. Ein Backup, das nie zurückgespielt wurde, ist eine Vermutung. Zum Hinsehen gehören die Logs, der Rückstau in der Queue, die Laufzeit des nächtlichen Imports, die Fehlerrate im Checkout und das Wachstum der Tabellen, die still größer werden. Deprecation-Meldungen lesen wir mit, weil sie die Bruchstellen des nächsten Majors ankündigen, während noch Zeit ist. Am Ende steht ein Protokoll der durchgeführten Arbeiten — vorlegbar, ohne dass jemand erst suchen muss.
Ein Shopware-Shop, den zwei Jahre niemand angefasst hat, funktioniert. Er nimmt Bestellungen an, verschickt Rechnungen, zeigt Bestände — bis er es nicht mehr tut. Der Unterschied zwischen „es läuft“ und „es ist gepflegt“ ist kein Zustand des Shops, sondern die Länge des Weges zurück auf den aktuellen Stand. Bei einem gepflegten Shop ist das nächste Update ein Wartungsfenster. Bei einem ungepflegten ist es eine Kette: Core-Sprung, Plugins ohne Nachfolger, PHP-Version, Datenbank, dazwischen individueller Code, den niemand dokumentiert hat. Jeder Schritt hängt am vorherigen, und der Termin richtet sich nicht nach Ihrem Kalender, sondern nach dem, was zuerst bricht.
Shopware 6.7 ist dafür das aktuelle Lehrstück. Der Wechsel von 6.6 auf 6.7 ist der größte technische Umbau seit dem Start von Shopware 6 — Vue 3, Vite, Pinia in der Administration —, und der Aufwand entspricht deshalb eher einem Major-Sprung als einem Punkt-Release. Wer seinen Shop laufend gepflegt hat, hatte zu diesem Zeitpunkt eine überschaubare Liste eigener Anpassungen und eine geklärte Plugin-Landschaft; für die großen Store-Plugins liegen seit Anfang 2026 kompatible Fassungen vor, anders als in den ersten Monaten nach dem Release von 6.7 im Juni 2025. Wer nicht gepflegt hat, hat dieselbe Arbeit zusätzlich zu allem, was in der Zwischenzeit angefallen ist. Shopware 6.8 wird für 2027 erwartet. Der nächste Termin steht damit schon fest, auch wenn das Datum fehlt.
Was ein Wartungsvertrag nicht kann: einen Einbruch verhindern oder Verfügbarkeit garantieren. Er verkürzt das Fenster zwischen einem veröffentlichten Fehler und dem eingespielten Patch, hält den Unterbau auf einem unterstützten Stand, macht Störungen früher sichtbar und belegt, wann gehandelt wurde. Prozentzahlen zur Verfügbarkeit nennen wir nicht, weil sie in einem selbst gehosteten Shop von Dingen abhängen, die wir nicht alle in der Hand haben. Und wenn eine Monatspauschale sich für Ihren Shop nicht rechnet — kleines Sortiment, vier Erweiterungen, kein ERP —, sagen wir das und schlagen stattdessen geplante Update-Aufträge in festem Rhythmus vor. Ein Vertrag, der mehr kostet als er verhindert, ist für beide Seiten ein schlechtes Geschäft.
Bei einer Website ist ein Fehler ein Darstellungsproblem. Bei einem Shop ist er eine geschlossene Kasse, und zwar meist eine, die von außen nicht zu sehen ist: Der Shop lädt, der Katalog funktioniert, nur die Bestellung geht seit heute Morgen nicht durch. Deshalb gehören in das Monitoring eines Shops andere Werte als in das einer Website — nicht nur Erreichbarkeit und Zertifikat, sondern die Zahl der eingegangenen Bestellungen im Verhältnis zum üblichen Tagesverlauf, die Fehlerrate im Bestellprozess, der Zustand der Queue und die Laufzeit der Indexierung. Ein Shop, der eine Stunde keine Bestellung annimmt, hat entweder Feiertag oder ein Problem.
Der zweite Unterschied sind die Zahlungsanbieter. Ein Shop hängt an Dritten, die ihre Schnittstellen nach ihrem eigenen Kalender ändern: neue API-Version, geänderte Webhook-Nutzlast, auslaufende Zertifikate, angepasster Ablauf bei der Kundenauthentifizierung, abgekündigte Endpunkte mit Frist. Diese Änderungen kommen unabhängig davon, ob Sie gerade ein Projekt haben, und sie treffen genau die Stelle, an der Geld fließt. Shopware 6.7 hat obendrein die Zahlungs-Handler auf die einheitliche Basisklasse AbstractPaymentHandler umgestellt — Zahlungserweiterungen sind an diesem Punkt also von zwei Seiten in Bewegung. Wartung heißt hier: die Ankündigungen der Anbieter mitlesen und die Zahlart nach jedem Update gegen einen echten Testkauf fahren, nicht gegen einen Blick auf die Startseite.
Der dritte Unterschied ist die Warenwirtschaft. Eine ERP-Anbindung bricht bei Updates auf beiden Seiten, und die Updates auf der ERP-Seite kündigt Ihnen niemand über den Shop an. Dazu kommen die Fragen, die keine technischen sind: Welches System besitzt den Preis, welches den Bestand, welches die Beschreibung? Was passiert, wenn der Import mitten im Lauf abbricht — bleibt der halbe Stand stehen? Darf derselbe Datensatz zweimal geschrieben werden, ohne Schaden anzurichten? Und wer liest das Fehlerprotokoll? Seit Shopware 6.6 ist der Bestand ein Echtzeitwert: product.stock wird über die Bestell-Events fortgeschrieben, der frühere verfügbare Bestand ist nur noch ein schreibgeschützter Spiegel desselben Feldes. Abweichungen zum ERP sind deshalb fast immer ein Synchronisations- oder Reservierungsproblem. Solche Abweichungen fallen ohne laufende Kontrolle erst auf, wenn ein Kunde etwas kauft, das nicht mehr da ist.
Der häufigste Anlass für eine Wartungsanfrage ist ein Shop, den jemand anders gebaut hat. Wir übernehmen solche Shops, aber nicht ungesehen. Vor der Zusage steht eine Bestandsaufnahme, und die Liste ist immer dieselbe: Shopware-Version und Patch-Stand, Composer-Setup oder dessen Fehlen, Plugin-Liste mit Herkunft und Lizenzlage, Umfang und Zustand des eigenen Codes, Eingriffe in den Core, Theme und Twig-Anpassungen, Schnittstellen zu ERP, PIM, Versand und Zahlung. Dazu das Hosting: PHP- und Datenbankversion, Cache- und Suchdienste, Deployment-Weg, ob ein Staging existiert, wie die Backups aussehen und ob schon einmal eines zurückgespielt wurde. Gebraucht werden Shell- und Datenbankzugang, das Repository, der Shopware-Account und die Administratorrechte im Shop. Ohne SSH lässt sich ein Shopware-Projekt nicht sinnvoll betreuen.
Zur Bestandsaufnahme gehört die Auftragsverarbeitung, weil in einem Shop personenbezogene Daten liegen: Auftragsverarbeitungsvertrag nach Artikel 28 DSGVO, die Kette der Unterauftragnehmer, Serverstandort, Aufbewahrung der Backups, wer welche Zugänge hat und welche Konten längst gesperrt gehören. Bei Übernahmen finden wir dort regelmäßig offene Punkte: kein Vertrag mit dem bisherigen Dienstleister, Plugins auf den Namen der alten Agentur lizenziert, der Shopware-Account nicht auf Ihr Unternehmen ausgestellt, Zugänge, die noch bei Personen liegen, die dort nicht mehr arbeiten. Den vorgefundenen Zustand dokumentieren wir und lassen ihn schriftlich bestätigen, damit später unterscheidbar bleibt, was wir vorgefunden und was wir verursacht haben.
Und wir sagen ab. Nicht oft, aber es kommt vor: Änderungen quer durch den Core, die jedes Update zu einer Neuentwicklung machen; zentrale Individualentwicklung, die ohne Quellcode ausgeliefert wurde; ein Bestellprozess, dessen Verhalten niemand mehr erklären kann; Spuren einer Kompromittierung im Dateisystem oder in den Administratorkonten. Dann ist das kein Wartungsfall, sondern eine Sanierung oder ein Neuaufbau mit eigenem Angebot — und wir sagen das vor dem Vertrag, nicht im dritten Monat. Für einen Zustand, für den wir nicht geradestehen können, unterschreiben wir keine Reaktionszeit. Eine zugesagte Frist auf einem Shop, den man nicht versteht, ist eine Zusage, die im Ernstfall nicht hält.
Die Reaktionszeiten sind bei uns gestaffelt, und zwar in vier Stufen je Shop: BASIC mit 24 Stunden für Systeme, bei denen ein Ausfall Arbeit verschiebt, aber keinen Umsatz kostet. STANDARD mit 8 Stunden für Shops, die im Tagesgeschäft gebraucht werden. ADVANCED mit 4 Stunden für Shops mit laufendem Bestellvolumen und angebundenen Systemen. PREMIUM mit 2 Stunden für Systeme, bei denen jede Stunde Stillstand unmittelbar Geld kostet. Abgerechnet wird als Monatspauschale netto je Shop. Die Reaktionszeit sagt, wann jemand mit der Bearbeitung beginnt — nicht, wann das System wieder läuft; diese beiden Werte halten wir im Vertrag getrennt. Ohne Vereinbarung gilt weiterhin: Bearbeitung in Eingangsreihenfolge innerhalb von 48 Stunden zu den Geschäftszeiten Mo–Fr 9:00–16:00 Uhr.
Die Stufe wählt man nicht danach, welche Zahl beruhigend klingt, sondern über eine Rechnung, die Sie selbst aufmachen können: Was kostet eine Stunde Stillstand? Umsatz geteilt durch die Stunden, in denen er entsteht, ist der Anfang. Dazu die Bestellungen, die nicht nachgeholt werden, weil der Kunde beim Wettbewerber kauft, die Servicelast am Telefon, die Verzögerung in Lager und Versand, bei angebundener Warenwirtschaft der Aufräumaufwand für halb übertragene Daten. Wer diese Summe kennt, ordnet sich meist von selbst richtig ein. Zwei Dinge sind unabhängig von der Stufe: Außerhalb von Mo–Fr 9:00–16:00 Uhr geht hier niemand ans Telefon, wenn keine Rufbereitschaft vereinbart ist — und die kostet auch in den Monaten, in denen nichts passiert. Die Monatspauschale nennen wir nach der Bestandsaufnahme, nicht am Telefon: Sie hängt an der Zahl der Erweiterungen, am Umfang des eigenen Codes, an den Schnittstellen und an der gewählten Stufe.
Zum Betriebsmodell gehören zwei gleichwertige Wege. Entweder läuft der Shop auf unseren eigenen Servern in Deutschland, auf Proxmox-PVE-Clustern, mit passender PHP-Version, Objekt-Cache und Suchindex — dann liegen Betrieb und Wartung in einer Hand und die Verantwortungsgrenze entfällt. Oder wir betreuen ihn auf Ihrem bisherigen Hosting; dafür brauchen wir SSH-Zugang, einen sauberen Deployment-Weg, ein Staging-System und ausreichende PHP- und Datenbankversionen. Fehlt das, richten wir es dort ein oder rechnen den Umzug gegen, statt jede Wartung teurer zu machen als sie sein muss. Wo Hosting und Anwendung getrennt sind, halten wir die Verantwortungsgrenze vor dem Start schriftlich fest, damit im Störungsfall niemand erst sucht, wer zuständig ist. Und wir richten die Betreuung so ein, dass Sie sie beenden können: Quellcode in Ihrem Repository, Lizenzen und Zugänge auf Ihr Unternehmen, Domains auf Ihren Namen, Installation dokumentiert.
Ablauf
Wenn die Antwort „niemand“ oder „das weiß ich nicht“ lautet, sind Sie hier richtig. Schicken Sie uns die Domain und, wenn vorhanden, einen Zugang. Die Ersteinschätzung zu Version, Patch-Stand, Plugin-Landschaft und Hosting ist kostenfrei; der ausführliche Befundbericht ist ein abgegrenztes Erstprodukt zum Festpreis, den wir vorher schriftlich nennen — und er gehört Ihnen, auch wenn Sie danach woanders beauftragen. Sharpness Solutions GmbH, Edewechter Landstraße 161, 26131 Oldenburg. Telefon 0441 21 21 63 0, Mo–Fr 9:00–16:00 Uhr, info@sharpness.de. Betreut wird bundesweit remote, Termine in Oldenburg und im Nordwesten nach Absprache.
Sie schildern die Lage: welche Shopware-Version läuft, wer den Shop gebaut hat, was zuletzt geändert wurde, wo das Hosting liegt. Wir sagen, welche Zugänge wir für die Bestandsaufnahme brauchen — Shell, Datenbank, Repository, Shopware-Account, Admin. Reagiert der bisherige Dienstleister nicht, fordern wir die Zugänge selbst an.
Die Ersteinschätzung nach Domain und Zugang ist kostenfrei. Der ausführliche Befundbericht ist ein abgegrenztes Erstprodukt zum Festpreis, den wir vorher schriftlich nennen: Wir sehen in Code, Plugin-Liste, Logs, Hosting und Backups und schreiben auf, was läuft, was offen ist, was zuerst passieren muss, was teuer wird. Erst danach reden wir über einen Vertrag. Eine Zusage vor dem Blick in den Code wäre geraten, und Raten ist bei fremdem Code keine Methode.
Fehlt ein Staging-System, richten wir zuerst eines ein. Dort läuft der erste vollständige Update-Durchlauf samt Plugin-Prüfung und Testkauf über jede aktive Zahlart. Hier zeigt sich auch, ob das vorhandene Backup zurückspielbar ist. Was bricht, bricht auf einer Kopie.
Sie wählen die Stufe — BASIC 24, STANDARD 8, ADVANCED 4 oder PREMIUM 2 Stunden Reaktionszeit — anhand der Frage, was eine Stunde Stillstand kostet. Dazu Erreichbarkeit, Eskalationsweg, Rufbereitschaft falls nötig, Verantwortungsgrenze zum Hosting und der Auftragsverarbeitungsvertrag. Alles schriftlich, nichts mündlich.
Wir ziehen den Patch-Stand nach, räumen Erweiterungen ohne Betreuer auf, setzen Monitoring und Backup-Kette auf unsere Prozesse und dokumentieren den Stand. Am Ende steht ein Protokoll, das Sie der Geschäftsführung oder dem Datenschutzbeauftragten vorlegen können.
Danach der Regelbetrieb: Releases bewerten und in vereinbarten Fenstern einspielen, Plugin-Kompatibilität nachhalten, Logs und Queue im Blick, Backups prüfen, Fragen aus Ihrem Team beantworten. Einmal im Quartal sehen wir voraus, was auf den Shop zukommt — der nächste Major 6.8 wird für 2027 erwartet. Sie schreiben dabei an dieselbe Adresse wie im Erstgespräch, nicht an ein Verteilerpostfach.
Projekte auf diesem System
Ein Auszug — nicht die vollständige Kundenliste.
Enthalten sind Sicherheits- und Bugfix-Releases der laufenden Shopware-Linie nach Test auf Staging, Plugin-Pflege, Pflege von PHP, Datenbank, Cache- und Suchdiensten, Backups mit Rücksicherungstest, Monitoring von Erreichbarkeit, Logs, Queue und Fehlerrate im Bestellprozess, dazu ein Protokoll der durchgeführten Arbeiten und die vereinbarte Reaktionszeit. Nicht enthalten sind der Sprung auf einen neuen Major, neue Funktionen, Redesigns und die Entwicklung zusätzlicher Erweiterungen. Das sind eigene Projekte mit eigener Planung und eigenem Angebot.
Die Wartung läuft als Monatspauschale netto je Shop, gestaffelt nach der vereinbarten Reaktionszeit; alles darüber hinaus nach Aufwand. Eine Preisliste veröffentlichen wir nicht, weil der Preis an nachprüfbaren Größen hängt: Zahl und Herkunft der Erweiterungen, Umfang des eigenen Codes, Schnittstellen, gewählte Service-Level-Stufe und ob der Betrieb dazugehört. Wer ohne Blick in den Shop einen Monatspreis nennt, kalkuliert einen Durchschnitt, den Sie mitbezahlen. Die Ersteinschätzung nach Domain und Zugang ist kostenfrei; der ausführliche Befundbericht ist ein abgegrenztes Erstprodukt zum Festpreis, den wir vorher schriftlich nennen. Das Angebot für die laufende Wartung folgt daraus.
Es gibt vier Stufen je Shop: BASIC mit 24 Stunden Reaktionszeit, STANDARD mit 8, ADVANCED mit 4 und PREMIUM mit 2 Stunden. Die Entscheidung fällt über eine Rechnung, nicht über ein Gefühl: Was kostet eine Stunde Stillstand? Umsatz geteilt durch die Stunden, in denen er entsteht, plus die Bestellungen, die nicht nachgeholt werden, plus Servicelast und Aufräumaufwand bei angebundener Warenwirtschaft. Ein Shop mit laufendem Bestellvolumen und ERP-Kopplung liegt damit meist bei ADVANCED oder PREMIUM, ein Katalog mit Anfrageformular bei BASIC.
Verbindliche Reaktionszeiten gelten nur mit abgeschlossener Vereinbarung. Ohne SLA bearbeiten wir Meldungen in Eingangsreihenfolge innerhalb von 48 Stunden zu den Geschäftszeiten Mo–Fr 9:00–16:00 Uhr. Das ist keine Verhandlungstaktik, sondern die Bedingung, unter der die gestaffelten Zeiten überhaupt haltbar sind: Wer 2 Stunden zusagt, muss Kapazität dafür freihalten, und die ist nicht mehrfach vergeben. Abends, am Wochenende und an Feiertagen geht ohne vereinbarte Rufbereitschaft niemand ans Telefon.
Nein. Ein Major-Sprung bringt Breaking Changes mit, verlangt die Prüfung jeder Erweiterung, Anpassungen an Theme und eigenem Code und einen eigenen Testdurchlauf — das ist ein Projekt mit Angebot, nicht ein Wartungsfenster. Der Wechsel von 6.6 auf 6.7 zeigt die Größenordnung: Vue 3, Vite und Pinia in der Administration bedeuten für jedes Plugin und jedes Custom-Theme eine Anpassung. Shopware 6.8 wird für 2027 erwartet; der Extended Support für 6.6 verlängert sich entsprechend bis zum Erscheinen von 6.8, in der 6.6-Linie erschien zuletzt 6.6.10.22 am 5. August 2026. Updates innerhalb der laufenden Linie gehören dagegen zur Wartung. Die Begleitung eines Versionssprungs von 6.6 auf 6.7 beschreiben wir unter /shopware-hilfe.
Der Takt richtet sich nach den Releases, nicht nach einem Kalendereintrag: Shopware veröffentlicht innerhalb der laufenden Linie etwa monatlich ein Patch-Release — 6.7.12.0 am 7. Juli 2026, 6.7.13.0 am 5. August 2026 —, und jedes davon wird bewertet: betrifft es die Installation, was ändert es an aktiven Erweiterungen, wie dringend ist es. Ein neues x.x.x.0-Release spielen wir nicht am Erscheinungstag ein, weil Shopware einzelne davon nach der Veröffentlichung wieder gesperrt hat; 6.7.12.0 war nicht installierbar, nutzbar wurden die Fixes erst mit 6.7.12.1. Wir warten deshalb auf einen belastbaren Patch-Stand. Übersprungen wird nichts, weil jeder übersprungene Stand den nächsten Sprung größer macht.
Nein. Wir betreuen Shops auch auf fremdem Hosting, solange die Grundlagen stimmen: SSH-Zugang, ein sauberer Deployment-Weg, ein Staging-System und ausreichende PHP- und Datenbankversionen. Fehlt eines davon, richten wir es dort ein oder rechnen den Umzug dagegen — ohne Shell-Zugriff ist jede Wartung teurer als der Wechsel. Alternativ läuft der Shop auf unseren eigenen Servern in Deutschland, auf Proxmox-PVE-Clustern; dann liegen Betrieb und Wartung in einer Hand. Bei getrennter Zuständigkeit halten wir die Verantwortungsgrenze vor dem Start schriftlich fest.
Ja, das ist der häufigste Anlass für eine Wartungsanfrage. Wir sehen vor der Zusage in Code, Plugin-Liste, Logs, Hosting und Backups und geben einen schriftlichen Befund ab; erst danach entsteht ein Vertrag. Gebraucht werden Shell- und Datenbankzugang, das Repository, der Shopware-Account und Administratorrechte im Shop. Fehlende Dokumentation ist kein Ausschlusskriterium — undokumentierter Code ist der Normalfall. Reagiert der bisherige Dienstleister nicht, fordern wir die Zugänge selbst an.
Ja. Wenn Änderungen quer durch den Core gehen und jedes Update zur Neuentwicklung machen, wenn zentrale Individualentwicklung ohne Quellcode ausgeliefert wurde, wenn niemand mehr erklären kann, was im Bestellprozess passiert, oder wenn wir Spuren einer Kompromittierung finden, ist das kein Wartungsfall. Dann steht eine Sanierung oder ein Neuaufbau an, mit eigenem Angebot, und wir sagen das vor dem Vertrag statt im dritten Monat. Eine zugesagte Reaktionszeit auf einem Shop, den man nicht versteht, hält im Ernstfall nicht.
Erweiterungen gehören zur Wartung, weil ein aktueller Core allein nichts nützt: Die Fehler sitzen meist in Drittanbieter-Plugins und in individuellem Code, und genau die deckt der Herstellersupport nicht ab. Zu jedem Update prüfen wir, welche Erweiterung eine passende Fassung hat, welche noch einen Betreuer hat und welche ungenutzt im Shop steht. Wer ein Plugin für zwei Linien pflegt, braucht getrennte Releases für 6.6 und 6.7 — dasselbe gilt für Ihre eigenen Plugins, und deshalb gehört diese Liste in die Wartung und nicht in eine Tabelle, die niemand fortschreibt.
Im Regelfall nicht. Getestet wird auf einer Staging-Kopie, deployed wird in ein vereinbartes Fenster, üblicherweise außerhalb Ihrer Hauptverkaufszeiten. Was dabei kurz spürbar sein kann, ist das Leeren und Vorwärmen der Caches nach dem Deployment; bei größeren Datenbankmigrationen planen wir ein Fenster mit Wartungsseite ein und sagen es vorher an. Vor jedem Eingriff steht ein Backup, und der Rückweg auf den alten Stand ist dokumentiert, nicht improvisiert.
Über einen Auftragsverarbeitungsvertrag nach Artikel 28 DSGVO, mit benannten Unterauftragnehmern und dokumentierter Aufbewahrung der Backups. Gehört der Betrieb dazu, läuft der Shop auf eigenen Servern in Deutschland. Bei Übernahmen prüfen wir diesen Punkt mit, weil dort regelmäßig etwas fehlt: kein Vertrag mit dem bisherigen Dienstleister, Zugänge bei Personen, die längst nicht mehr im Unternehmen sind, Plugins auf den Namen der alten Agentur lizenziert. Das Update-Protokoll bekommen Sie in einer Form, die Sie dem Datenschutzbeauftragten vorlegen können.
Gerade dann. Ein Shop, an dem niemand arbeitet, verändert sich trotzdem von außen: Zahlungsanbieter ändern Schnittstellen und kündigen Endpunkte ab, das ERP wird auf der anderen Seite aktualisiert, Browser ändern ihr Verhalten bei Cookies, Sicherheitslücken werden öffentlich beschrieben, und die eingesetzte PHP-Version läuft irgendwann aus. Der Shop funktioniert dabei weiter — bis er es nicht mehr tut, und dann ist die Ursache Monate alt. Ohne Änderungen am Shop wird die Wartung kleiner, nicht gegenstandslos.
Nur eingeschränkt. Die hier beschriebenen Arbeiten setzen einen selbst gehosteten Shop voraus: Logs unter var/log/, bin/console, eigenes Staging, Zugriff auf Datenbank, Cache und Suchindex. In Shopware Cloud übernimmt der Hersteller Updates und Infrastruktur; dort bleibt für uns die Pflege von Konfiguration, Apps nach Shopware-Standard und Schnittstellen über Admin API und Store API. Welche Variante Sie betreiben, klären wir im ersten Gespräch — davon hängt ab, was ein Wartungsvertrag überhaupt abdecken kann.
Anfrage
Beschreiben Sie kurz, wie der Shop gerade betreut wird — oder dass er es nicht wird. Wir sehen in Code, Plugin-Liste und Hosting und sagen, was zuerst passieren muss, bevor über einen Vertrag gesprochen wird.