Nach dem Launch einer Plattform stellt sich beim ersten ernsten Vorfall erneut die Frage: „Wer ist dafür verantwortlich?“ Wartung funktioniert, wenn vorher klar ist, wer reagiert, was Vorrang hat und was geschieht, wenn Checkout, Zahlungen oder eine Integration zur Bestellübertragung betroffen sind.
Wir übernehmen die laufende Wartung und Weiterentwicklung von Magento-Plattformen. Wir verantworten Betriebskontinuität und Störungsbehebung, erledigen die tägliche Entwicklungsarbeit oder unterstützen das vorhandene Kundenteam dort, wo vertiefte Magento-Kenntnisse gefragt sind.
Im ersten Gespräch lernen wir Ihre Magento-Plattform, das aktuelle Supportmodell und ihre Bedeutung für das Unternehmen kennen. Darauf aufbauend bestimmen wir einen sinnvollen Verantwortungsumfang und ein passendes Modell der Zusammenarbeit.
Verantwortung
Eine Banneränderung und ein kritischer Sicherheitspatch sollten nicht in derselben Warteschlange liegen. Ebenso wenig darf ein Fehler auf einer einzelnen Produktseite dieselbe Priorität haben wie ein ausgefallener Checkout, B2B-Kunden ohne Anmeldemöglichkeit oder Bestellungen, die das ERP nicht mehr erreichen.
Deshalb bedeutet Plattformwartung für uns mehr, als ein Ticket nach dem anderen abzuarbeiten.
Das erste Ziel ist ein klarer Ablauf für den Störungsfall. Das zweite ist, solche Situationen schrittweise zu reduzieren: durch Updates, Monitoring, Verbesserungen in besonders riskanten Bereichen und den bewussten Umgang mit technischen Altlasten.
Eine gut gewartete Magento-Plattform wird mit der Zeit berechenbarer, statt das Unternehmen an ständige Notfalleinsätze zu gewöhnen.
Betriebsbudget
In einer laufenden Zusammenarbeit unterscheiden wir zwei Arten von Arbeit. Beide laufen parallel, verfolgen aber unterschiedliche Ziele und folgen unterschiedlichen Nutzungsregeln.
Dazu gehören die Verfügbarkeit des Teams, die Bearbeitung von Störungen, Patch- und Sicherheitsupdates sowie die Arbeiten, die den Normalbetrieb der Plattform wiederherstellen.
Es dient geplanten Änderungen: Konfiguration, Entwicklung, technischer Beratung, Verbesserungen und weiteren Aufgaben der Roadmap.
Wir trennen diese Bereiche aus einem praktischen Grund: Ein Vorfall verbraucht nicht das Budget, das für die Weiterentwicklung vorgesehen ist.
Je nach gewähltem Supportpaket können ungenutzte Stunden bis zu drei Monate in Folgemonate übertragen werden. Ist das Kontingent ausgeschöpft, informieren wir Sie vor Beginn zusätzlicher Arbeiten. Monatlich erhalten Sie eine Übersicht der Tickets, der jeweils aufgewendeten Zeit und des verbleibenden Guthabens.
Größere Modernisierungen sind nicht automatisch im Monatspaket enthalten. Ein umfangreiches Magento-Upgrade, ein neues Frontend oder eine neue Integration wird als separates Projekt geplant.
Ticket-Einstufung
Wir stufen jedes Ticket nach seinen Auswirkungen auf die Plattform ein.
Der Shop oder ein zentraler Vertriebsprozess ist nicht verfügbar: Kunden können nicht bestellen oder bezahlen, ein flächendeckender Fehler verhindert die Nutzung oder es besteht der Verdacht auf einen Sicherheitsvorfall.
Eine wichtige Funktion arbeitet fehlerhaft, der Vertrieb läuft jedoch weiter. Dazu zählen erhebliche Performanceeinbußen oder Probleme, die viele Kunden oder einen wichtigen Verwaltungsprozess betreffen.
Nicht kritische Fehler, Einzelfälle, Probleme mit verfügbarer Umgehungslösung und Mängel, die den Verkauf nicht verhindern.
Neue Funktionen, Verbesserungen, Konfiguration und geplante Entwicklungsarbeiten.
Die Priorität richtet sich nach den tatsächlichen Auswirkungen auf Vertrieb und Verfügbarkeit. In unklaren Fällen stimmen wir die Einstufung mit dem Kunden ab, damit wirklich kritische Meldungen Vorrang behalten.
SLA
Sie legt fest, wie schnell wir nach der Registrierung mit der Bearbeitung eines Tickets beginnen: Wir antworten inhaltlich, nennen Priorität und nächste Schritte und nehmen die Arbeit tatsächlich auf. Eine automatische Eingangsbestätigung ist keine Reaktion.
Sie betrifft die Wiederherstellung eines zentralen Prozesses oder die Bereitstellung einer sicheren Zwischenlösung. Eine vollständige Behebung kann länger dauern, wenn Codeänderungen, Regressionstests und die Auslieferung in einer späteren Version nötig sind.
Wir versprechen keine einheitliche „Lösungszeit“ für jeden Vorfall. Wir definieren eine garantierte Reaktion und das Vorgehen des Teams abhängig von der Störungsklasse.
So messen wir das SLA
Wir messen die Reaktionszeit ab der Registrierung im Ticketsystem. Die Zeitmessung kann pausieren, wenn zur Lösung Informationen oder Maßnahmen des Kunden benötigt werden oder die Ursache bei einem externen Dienst außerhalb unseres Einflusses liegt.
Die genauen Zeitregeln, die erforderlichen Ticketangaben und die SLA-Ausnahmen werden vertraglich festgelegt.
Technische Wartung
Magento bleibt nicht über Jahre unverändert. Sicherheitspatches, neue Magento- und PHP-Versionen sowie Änderungen an Bibliotheken, Modulen und externen Diensten kommen laufend hinzu.
Regelmäßiges Patch-Management und Sicherheitsupdates gehören zur Wartung. Einen offiziellen Herstellerpatch behandeln wir als kritisch, wenn er als kritisch eingestuft ist, einen CVSS-Wert ab 9,0 besitzt oder den Status Priority 1 hat. Die messbaren Fristen für kritische und andere Patches werden vertraglich vereinbart.
Größere Magento-Upgrades planen wir separat, da sie die Prüfung individuellen Codes, der Modulkompatibilität und Regressionstests erfordern.
Wir wollen verhindern, dass der Shop jahrelang auf einem veralteten Technologie-Stack bleibt und jedes folgende Update dadurch zu einem großen, riskanten Projekt wird.
Ein erheblicher Teil der Magento-Sicherheitsvorfälle nutzt bekannte Schwachstellen, für die bereits ein Patch verfügbar war. Bei Plattformen mit höherem Schutzbedarf ergänzen wir die Wartung um aktives Sicherheitsmonitoring.
Einige Werkzeuge erfordern eine separate Lizenz auf Kundenseite. Darauf weisen wir bereits im Angebot hin.
Das Gesamtsystem
Ein Nutzer meldet eine sehr langsam ladende Kategorie. Die Ursache kann im Magento-Code liegen, ebenso aber in der Datenbank, der Indexierung oder der Art des Datenimports.
Ein Produkt erscheint nicht im Shop. Manchmal liegt das Problem in der Synchronisierung mit ERP oder PIM.
Ein Kunde sieht den aktuellen Bestellstatus nicht. Das Frontend arbeitet korrekt, doch der Datenaustausch steckt in einer Warteschlange fest.
Bei der Wartung komplexer Plattformen betrachten wir deshalb das Gesamtsystem und nicht nur den Shop-Code. Wir arbeiten mit MySQL und MariaDB, Redis, Varnish, OpenSearch und Elasticsearch, RabbitMQ sowie Integrationen zu ERP, PIM, CRM und individuellen Systemen.
Wir arbeiten mit den Administratoren oder dem Infrastrukturanbieter des Kunden zusammen. Ist Unterstützung durch uns nötig, helfen wir bei Diagnose, Konfiguration und Optimierung der Umgebung.
Übernahme der Wartung
Sie müssen kein Implementierungskunde von uns sein, um uns Ihre Magento-Wartung anzuvertrauen.
Bevor wir die Plattform unter ein SLA stellen, lernen wir Code, individuelle Module, Integrationen, Umgebungen, Deployment-Prozess und die Aufgabenverteilung zwischen den Systemen kennen. Das soll kein monatelanges Audit sein. Es stellt lediglich sicher, dass wir keine Reaktionszeiten für ein System zusagen, dessen Zustand wir noch nicht kennen.
Ist die Plattform instabil, kehren Fehler immer wieder und lässt sich der technische Zustand schwer einschätzen, ist der bessere erste Schritt die Rettung und Übernahme des Magento-Projekts . Nach der Stabilisierung geht das Projekt in ein reguläres Wartungsmodell über.
Eignung
In einem normalen Wartungsmodell würde vor allem ein Vorfall nach dem anderen bearbeitet. Diagnose, Übernahme und Stabilisierung sind der bessere Einstieg.
Magento-Projektrettung →Wenn die Shopfunktionen arbeiten, aber TTFB, Core Web Vitals, Datenbank, Cache oder Indexierung Schwierigkeiten bereiten, ist ein gezieltes Optimierungsprojekt der richtige Einstieg.
Magento-Performanceoptimierung →Reinen Serverplatz bieten wir nicht als Supportdienstleistung an. Wir arbeiten mit Ihrem Infrastrukturanbieter zusammen oder helfen, die Magento-Umgebung zu konzipieren und zu optimieren.
Fragen
Ja. Bevor ein reguläres SLA beginnt, machen wir uns mit Code, Integrationen, Umgebungen und Deployment-Prozess vertraut. Benötigt das Projekt eine umfassendere Stabilisierung, ist Rescue die erste Phase.
Wartung umfasst Betriebskontinuität, Störungen und operative Arbeiten. Das Stundenpaket dient geplanten Änderungen und Weiterentwicklung. Beide Modelle laufen parallel, damit Störungen das Entwicklungsbudget nicht aufbrauchen.
Das hängt vom gewählten Paket ab. Wir bieten Pakete an, bei denen Stunden bis zu drei Monate übertragen werden können. Monatlich erhalten Sie eine Übersicht der erledigten Arbeiten und des verbleibenden Guthabens.
Für kritische Vorfälle bieten wir einen Notfallweg außerhalb der regulären Supportzeiten. Benötigt die Plattform ein garantiertes 24/7-SLA, muss dafür ein separates Supportmodell vereinbart werden.
Die abschließende Einstufung nehmen wir vor, in begründeten Fällen nach Rücksprache mit dem Kunden. Entscheidend sind die Auswirkungen auf Vertrieb und Verfügbarkeit.
Regelmäßige Patches und Sicherheitsupdates gehören zur Wartung. Größere Versionsupgrades planen wir separat, da sie Regressionstests, Modulprüfungen und häufig Anpassungen individuellen Codes erfordern.
Ja. Wir bieten fachliche Unterstützung bei schwierigen Problemen, Integrationen, Performance, Updates und Architekturentscheidungen. Dafür muss nicht in jedem Fall der bisherige Anbieter ersetzt werden.
Wir unterstützen Diagnose, Konfiguration und Optimierung der Magento-Umgebung oder arbeiten mit Ihren Administratoren zusammen. Die genaue Aufgabenverteilung legen wir zu Beginn der Zusammenarbeit fest.
Erzählen Sie uns von Ihrem aktuellen Supportmodell, kritischen Prozessen und den häufigsten Problemen.
Wir melden uns innerhalb von 12 Stunden nach dem Absenden bei Ihnen.