Wartungsvertrag: was reingehört und was nicht

Ein Wartungsvertrag ist die Versicherung für deine Software nach dem Launch, und die meisten sind entweder zu vage oder voll mit Dingen, die gar keine Wartung sind. Wir zeigen dir, was wirklich reingehört: Verfügbarkeit, Reaktionszeiten, Updates, Sicherheit, Backups. Und wir ziehen die Linie zwischen Pflege und neuer Entwicklung, damit du nicht für Features zahlst, die als Bugfix getarnt sind. Am Ende weisst du, welche Klauseln nicht fehlen dürfen und wann ein fixer Vertrag der falsche Weg ist.

Jan-Hendrik Heuing

Warum Handschlag nicht reicht

Die Zusammenarbeit mit einer Agentur kann hervorragend funktionieren, solange alle Beteiligten wissen, was gemeint ist. Doch wir kümmern uns um die Wartung bedeutet für jede Seite etwas anderes. Der Kunde denkt an schnelle Hilfe bei jedem Problem. Die Agentur meint vielleicht Sicherheitsupdates und monatliche Backups. Dazwischen liegt ein Missverständnis, das meist erst auffällt, wenn die Anwendung ausfällt.

Ein Wartungsvertrag übersetzt Erwartungen in überprüfbare Leistungen. Er schafft Klarheit darüber, wer was tut, wie schnell reagiert wird und was es kostet. Das schützt beide Seiten. Der Kunde weiss, worauf er sich verlassen kann. Die Agentur kann planen und muss nicht bei jedem Vorfall neu verhandeln.

Der kritische Moment kommt oft am Freitagabend: Ein Zertifikat läuft ab, die Anwendung zeigt Fehler oder die Datenbank ist voll. Wer reagiert? Wie schnell? Zu welchem Preis? Ob zu diesem Zeitpunkt jemand eingreifen muss, ist keine technische Selbstverständlichkeit, sondern eine vertraglich vereinbarte Leistung. Wenn diese Fragen nicht vorher beantwortet sind, beginnt die Diskussion genau dann, wenn niemand Zeit dafür hat.

Verfügbarkeit: Was muss tatsächlich laufen?

Die Anwendung muss immer verfügbar sein klingt vernünftig, ist aber als Vertragsklausel unbrauchbar. Technisch gesehen gibt es keine hundertprozentige Verfügbarkeit. Wartungsfenster, Updates und unvorhersehbare Störungen gehören zum Betrieb.

Verfügbarkeit wird als Prozentsatz über einen Zeitraum definiert. 99,5 Prozent Verfügbarkeit pro Monat erlauben rund 3 Stunden und 36 Minuten Ausfall. 99,9 Prozent erlauben etwa 43 Minuten. Der Unterschied klingt klein, erfordert aber deutlich mehr technische und organisatorische Absicherung.

Der Vertrag sollte festlegen:

  • Welche Komponenten umfasst die Verfügbarkeit? Nur die Anwendung oder auch externe Dienste?
  • Wie wird gemessen? Vom Server aus oder aus Sicht der Nutzerinnen und Nutzer?
  • Welche Ausfälle zählen nicht? Geplante Wartungsfenster, höhere Gewalt oder Störungen bei Drittanbietern?
  • Über welchen Zeitraum wird gerechnet? Monatlich, quartalsweise oder jährlich?

Für viele KMU-Anwendungen reicht eine realistische Verfügbarkeitszusage mit klar definierten Wartungsfenstern. Höhere Garantien treiben die Kosten, ohne immer einen entsprechenden Geschäftsnutzen zu bringen.

Reaktionszeit ist nicht Lösungszeit

Diese beiden Begriffe werden häufig verwechselt. Die Reaktionszeit beschreibt, wie schnell die Agentur einen Vorfall bestätigt und mit der Analyse beginnt. Die Lösungszeit beschreibt, wann das Problem behoben ist.

Eine garantierte Lösungszeit ist bei komplexen Fehlern oft unseriös. Niemand kann vor der Analyse wissen, ob ein Bug in zehn Minuten oder zwei Tagen behoben ist. Sinnvoller sind verbindliche Reaktionszeiten und eine Pflicht zur regelmässigen Statusmeldung.

Der Vertrag sollte Störungen nach Priorität einteilen. Ein mögliches Modell:

  • Priorität 1: Die Anwendung ist nicht erreichbar oder zentrale Geschäftsprozesse stehen still.
  • Priorität 2: Eine wichtige Funktion ist beeinträchtigt, aber es gibt einen Workaround.
  • Priorität 3: Eine Funktion ist fehlerhaft, der Betrieb läuft weiter.
  • Priorität 4: Kosmetische Fehler oder Verbesserungswünsche.

Zu jeder Priorität gehört eine Reaktionszeit. Diese gilt innerhalb eines ausdrücklich vereinbarten Servicefensters. Bei Wertstifter ist der Standard Montag bis Freitag, 08:00 bis 17:00 Uhr. Eine Reaktion nachts oder am Wochenende ist damit nicht zugesagt. Wenn dein Geschäft auch ausserhalb dieses Fensters Unterstützung braucht, muss das als separate Anforderung mit Bereitschaft und gegebenenfalls einem Partner-Setup vereinbart werden. Ein Online-Shop mit relevantem Wochenendgeschäft braucht also eine andere vertragliche Abdeckung als ein internes Tool, das nur werktags genutzt wird.

Eskalation: Wenn die erste Reaktion nicht reicht

Ein Eskalationsweg verhindert, dass kritische Vorfälle zwischen E-Mails und Ticketsystem verschwinden. Der Vertrag sollte beschreiben, wer wann informiert wird.

Ein einfacher Eskalationsprozess kann so aussehen:

  1. Der Vorfall wird über den definierten Kanal gemeldet.
  2. Die Agentur bestätigt den Eingang innerhalb der vereinbarten Reaktionszeit.
  3. Bei Priorität 1 wird zusätzlich eine verantwortliche Person telefonisch informiert.
  4. Wenn keine Reaktion erfolgt, geht die Meldung an die nächste Eskalationsstufe.
  5. Nach der Lösung folgt ein kurzer Bericht mit Ursache und Massnahmen.

Wichtig ist der Meldekanal. Eine Nachricht an eine persönliche E-Mail-Adresse ist kein verlässlicher Prozess. Nutze ein Ticketsystem oder eine zentrale Support-Adresse, die überwacht wird. Für kritische Fälle braucht es zusätzlich eine Telefonnummer.

Definiere auch die Ansprechpartner auf deiner Seite. Die Agentur muss wissen, wer Entscheidungen treffen darf, wenn eine schnelle Freigabe nötig ist.

Wartungsfenster und Betriebszeiten

Updates müssen installiert werden. Manche davon erfordern einen Neustart oder eine kurze Unterbrechung. Ohne vereinbarte Wartungsfenster wird jede geplante Arbeit zum Konflikt.

Ein Wartungsfenster legt fest, wann die Agentur Arbeiten durchführen darf, die den Betrieb beeinträchtigen können. Zum Beispiel jeden zweiten Dienstag zwischen 19 und 21 Uhr. Dabei sollte geregelt sein:

  • Wie früh wird das Wartungsfenster angekündigt?
  • Wie lange darf die Unterbrechung dauern?
  • Was passiert, wenn das Fenster verschoben werden muss?
  • Gibt es Zeiten, in denen keine Wartung stattfinden darf, etwa während wichtiger Geschäftsperioden?

Unterscheide zwischen geplanter Wartung und Notfallwartung. Kritische Sicherheitslücken können nicht bis zum nächsten regulären Fenster warten. Für solche Fälle braucht es eine Klausel, die kurzfristige Eingriffe erlaubt und die Kommunikation regelt.

Die Betriebszeiten der Anwendung und die Servicezeiten der Agentur sind nicht dasselbe. Eine Anwendung kann rund um die Uhr verfügbar sein, während Support und garantierte Reaktionszeiten nur zu Geschäftszeiten gelten. Diese Unterscheidung gehört ausdrücklich in den Vertrag.

Backups: Mehr als ein Häkchen

Tägliche Backups sagt wenig aus. Ein brauchbarer Vertrag beantwortet detailliertere Fragen:

  • Welche Daten werden gesichert? Datenbank, hochgeladene Dateien, Konfiguration, Quellcode?
  • Wie häufig werden Backups erstellt?
  • Wie lange werden sie aufbewahrt?
  • Wo liegen sie? Beim gleichen Anbieter oder geografisch getrennt?
  • Sind die Backups verschlüsselt?
  • Wer hat Zugriff?
  • Wie oft wird die Wiederherstellung getestet?

Ein Backup, das nie zurückgespielt wurde, ist nur eine Vermutung. Der Vertrag sollte regelmässige Wiederherstellungstests vorsehen. Mindestens einmal pro Jahr, bei kritischen Systemen häufiger.

Zwei Kennzahlen helfen bei der Planung. Das Recovery Point Objective (RPO) beschreibt, wie viel Datenverlust akzeptabel ist. Bei täglichen Backups können im schlimmsten Fall Daten von 24 Stunden verloren gehen. Das Recovery Time Objective (RTO) beschreibt, wie lange die Wiederherstellung dauern darf.

Diese Werte hängen vom Geschäft ab. Ein Buchungssystem braucht andere Ziele als eine Informationswebsite. Je kleiner RPO und RTO, desto aufwendiger und teurer die Infrastruktur.

Mehr zu den technischen Grundlagen liest du in Monitoring, Backups und Alerting: das Minimum.

Sicherheitsupdates: Wer beobachtet was?

Sicherheitslücken werden ständig entdeckt. Frameworks, Bibliotheken, Betriebssysteme und Datenbanken brauchen regelmässige Updates. Der Wartungsvertrag muss klären, wer diese Abhängigkeiten beobachtet und wie schnell kritische Updates eingespielt werden.

Eine sinnvolle Regelung unterscheidet nach Schweregrad:

  • Kritische Sicherheitslücken mit aktiver Ausnutzung: sofortige Prüfung und schnellstmögliches Update.
  • Hohe Risiken: Update innerhalb weniger Tage.
  • Mittlere und niedrige Risiken: Bündelung im regulären Wartungszyklus.

Dabei geht es nicht nur um das Einspielen von Updates. Änderungen müssen getestet werden, damit sie keine neuen Fehler verursachen. Der Vertrag sollte deshalb einen Prozess vorsehen: Update in einer Testumgebung, automatisierte Tests, dann kontrollierte Veröffentlichung.

Auch die Reaktion auf Sicherheitsvorfälle gehört geregelt. Wer informiert betroffene Personen? Wer dokumentiert den Vorfall? Wer entscheidet über externe Kommunikation? Diese Fragen überschneiden sich mit Datenschutzpflichten und sollten mit einer Fachperson geklärt werden.

Kostenmodell: Pauschale, Kontingent oder Aufwand

Wartungsverträge nutzen meist eines von drei Modellen.

Monatliche Pauschale: Du zahlst einen festen Betrag für definierte Leistungen. Das schafft Planbarkeit, erfordert aber klare Grenzen. Was ist enthalten? Wie viele Stunden? Was kostet zusätzlicher Aufwand?

Stundenkontingent: Du kaufst ein monatliches oder jährliches Zeitbudget. Nicht genutzte Stunden verfallen oder werden übertragen. Das ist flexibel, kann aber zu Diskussionen über die Verwendung führen.

Abrechnung nach Aufwand: Du zahlst nur, was tatsächlich anfällt. Das klingt günstig, bietet aber keine garantierte Verfügbarkeit. Die Agentur kann ausgelastet sein, wenn du sie brauchst.

In der Praxis funktioniert oft eine Kombination: Eine Grundpauschale deckt Monitoring, Updates und eine definierte Bereitschaft. Zusätzliche Arbeiten werden nach Aufwand abgerechnet. Wichtig ist, dass der Vertrag Beispiele nennt, was zur Pauschale gehört und was nicht.

Achte auf versteckte Kosten. Fallen Zuschläge ausserhalb der Geschäftszeiten an? Werden externe Lizenzen separat verrechnet? Kostet die Wiederherstellung aus einem Backup zusätzlich? Je konkreter der Vertrag, desto weniger Überraschungen.

Laufzeit und Kündigung

Ein Wartungsvertrag bindet beide Seiten. Die Laufzeit sollte lang genug sein, damit die Agentur Ressourcen planen kann, aber nicht so lang, dass du in einer unpassenden Beziehung feststeckst.

Üblich sind Laufzeiten von drei bis zwölf Monaten mit automatischer Verlängerung. Entscheidend sind die Kündigungsfristen und die Regelung beim Vertragsende.

Der Vertrag sollte festlegen, was bei der Kündigung passiert:

  • Übergabe aller Zugangsdaten und Dokumentationen.
  • Export der Daten in einem nutzbaren Format.
  • Übergabe des aktuellen Quellcodes.
  • Unterstützung bei der Migration zu einem neuen Anbieter.
  • Löschung von Kopien nach bestätigter Übergabe.
  • Abrechnung offener Leistungen.

Eine Exit-Regelung ist keine Misstrauenserklärung. Sie gehört zu einem professionellen Vertrag. Beide Seiten wissen, wie eine saubere Trennung funktioniert, und können sich während der Zusammenarbeit auf das Produkt konzentrieren.

Wenn der Quellcode und die Zugänge unklar sind, wird der Wechsel unnötig schwierig. Unser Artikel Wem gehört der Code? behandelt dieses Thema ausführlich.

Was nicht in den Wartungsvertrag gehört

Ein Wartungsvertrag ist kein Entwicklungsvertrag. Neue Funktionen, grössere Umbauten und strategische Beratung sollten separat beauftragt werden. Sonst wird die Wartungspauschale zum unbegrenzten Entwicklungstopf.

Definiere die Grenze zwischen Fehlerbehebung und Weiterentwicklung. Ein Fehler liegt vor, wenn eine vereinbarte Funktion nicht wie beschrieben arbeitet. Eine Änderung liegt vor, wenn die Funktion anders arbeiten soll als bisher.

Beispiel: Wenn der Export keine Datei erzeugt, ist das ein Fehler. Wenn der Export zusätzlich ein neues Format unterstützen soll, ist das eine Weiterentwicklung.

Kleine Anpassungen können über ein Stundenkontingent abgedeckt werden. Grössere Vorhaben brauchen eine eigene Schätzung und Freigabe. Diese Trennung hält den Vertrag verständlich und die Kosten nachvollziehbar.

Die Checkliste für deinen Vertrag

Bevor du einen Wartungsvertrag unterschreibst, prüfe diese Punkte:

  1. Sind die betreuten Systeme und Komponenten vollständig aufgelistet?
  2. Ist die Verfügbarkeit messbar definiert?
  3. Gibt es klare Prioritätsstufen mit Reaktionszeiten?
  4. Sind Servicezeiten und Meldekanäle festgelegt?
  5. Gibt es einen dokumentierten Eskalationsweg?
  6. Sind Wartungsfenster vereinbart?
  7. Sind Backup-Umfang, Aufbewahrung und Restore-Tests geregelt?
  8. Gibt es Fristen für Sicherheitsupdates?
  9. Ist das Kostenmodell mit Ein- und Ausschlüssen verständlich?
  10. Sind Laufzeit, Kündigung und Übergabe geregelt?
  11. Ist die Grenze zwischen Wartung und Weiterentwicklung klar?
  12. Sind Verantwortlichkeiten auf beiden Seiten benannt?

Wenn mehrere dieser Punkte fehlen, ist der Vertrag wahrscheinlich zu vage. Das muss keine Absicht sein. Oft wurden die Fragen einfach nie gestellt. Jetzt hast du die Grundlage, sie zu stellen.

Was ein guter Vertrag leistet

Ein guter Wartungsvertrag verhindert nicht jeden Ausfall. Er sorgt dafür, dass im Ernstfall alle wissen, was zu tun ist. Er macht Kosten planbar, schützt vor Missverständnissen und schafft eine belastbare Grundlage für die Zusammenarbeit.

Die Details hängen von deinem Produkt ab. Eine öffentliche Plattform mit vielen Nutzern braucht andere Garantien als ein internes Werkzeug. Entscheidend ist, dass die Vereinbarung zu deinem tatsächlichen Risiko passt.

Wenn du Unterstützung bei der technischen Betreuung deiner Anwendung suchst, findest du auf unserer Seite zu Wartung und Support weitere Informationen. Für umfassenden laufenden Betrieb mit Monitoring und Infrastruktur lohnt sich ein Blick auf unsere Managed Services.