Wartungsvertrag: was reingehört und was nicht

Was ein Wartungsvertrag wirklich regelt

Ein Wartungsvertrag ist der Teil deines Software-Projekts, den niemand liest, bis etwas kaputt ist. Dann liest ihn plötzlich jeder, meistens am Freitagabend, und stellt fest, dass die entscheidende Frage gar nicht drinsteht: Wer kümmert sich jetzt, wie schnell, und wer zahlt dafür. Genau dieser Moment entscheidet, ob die Investition in deine Software etwas wert war oder ob du ab Tag eins ein Risiko betreibst, das dir keiner abnimmt.

Wartung klingt nach Putzen. Tatsächlich geht es um etwas Grösseres: Dein Produkt läuft in einer Welt, die sich bewegt. Browser bekommen Updates, Sicherheitslücken werden bekannt, eine Schnittstelle bei deinem Zahlungsanbieter ändert sich, die Nutzerzahl steigt. Eine Software, die heute sauber läuft, ist ohne Pflege in zwölf Monaten ein Sanierungsfall. Der Wartungsvertrag ist die Vereinbarung darüber, wer diese Bewegung mitmacht und unter welchen Bedingungen. Wer das ernst nimmt, regelt sieben Dinge sauber. Gehen wir sie durch.

Verfügbarkeit: was läuft konkret bedeutet

Der erste Satz, der reingehört, beantwortet die simpelste Frage: Wann muss die Software erreichbar sein, und was passiert, wenn sie es nicht ist. In der Praxis steht hier eine Verfügbarkeitszusage, oft als Prozentwert über den Monat gerechnet. 99 Prozent klingt viel, lässt aber rund sieben Stunden Ausfall pro Monat zu. 99,9 Prozent sind keine ganze Stunde. Welcher Wert für dich passt, hängt davon ab, was die Software tut. Ein internes Reporting-Tool darf nachts mal kurz weg sein. Eine Buchungsstrecke, über die dein Umsatz läuft, nicht.

Wichtig ist die Kleingedruckte daneben. Wartungsfenster, in denen geplant Updates eingespielt werden, zählen üblicherweise nicht als Ausfall, und das ist fair, solange sie angekündigt und ausserhalb der Hauptnutzungszeit liegen. Ein Vertrag, der eine Verfügbarkeit verspricht, aber kein Wartungsfenster definiert, ist entweder naiv oder so formuliert, dass er nie einzuhalten ist. Beides solltest du klären, bevor du unterschreibst.

Reaktionszeiten: wie schnell sich jemand meldet

Verfügbarkeit sagt, wie oft etwas läuft. Reaktionszeit sagt, wie schnell jemand reagiert, wenn es das nicht tut. Diese beiden werden ständig verwechselt, und der Unterschied kostet Geld. Eine seriöse Klausel trennt drei Stufen. Wie schnell wird ein gemeldetes Problem überhaupt bestätigt und in Bearbeitung genommen (Reaktionszeit). Wie schnell gibt es eine Umgehung, damit der Betrieb weiterläuft (Workaround). Und wie schnell ist die eigentliche Ursache behoben (Lösung).

Dazu kommt eine Einteilung nach Schwere. Ein kompletter Ausfall ist nicht dasselbe wie ein schief sitzendes Icon. Gute Verträge definieren zwei bis drei Prioritätsstufen mit jeweils eigenen Zeiten, etwa: kritischer Ausfall innerhalb von zwei Stunden in Bearbeitung, kleinere Fehler innerhalb eines Werktags. Achte auf die Servicezeiten. Innerhalb von vier Stunden bedeutet wenig, wenn die vier Stunden nur Montag bis Freitag von neun bis siebzehn Uhr zählen und dein Webshop am Sonntag steht. Wenn dein Geschäft am Wochenende läuft, muss das im Vertrag stehen.

Updates und Abhängigkeiten: das stille Risiko

Hier wird es technisch, aber bleib dran, denn dieser Punkt frisst die meisten Budgets im Stillen. Deine Software besteht nicht nur aus dem Code, den jemand für dich geschrieben hat. Sie steht auf einem Stapel fremder Bausteine: Frameworks, Bibliotheken, die Laufzeitumgebung, das Betriebssystem des Servers. Diese Bausteine werden laufend aktualisiert, und ältere Versionen verlieren irgendwann ihren Sicherheits-Support. Wenn niemand diese Abhängigkeiten pflegt, sammelt sich über Monate ein Berg an veralteten Komponenten an, bis ein notwendiges Update plötzlich ein kleines Projekt ist statt einer Routine.

Ein guter Wartungsvertrag regelt deshalb, dass Sicherheits- und Versionsupdates der eingesetzten Komponenten regelmässig eingespielt werden, nicht erst, wenn es brennt. Das ist unsichtbare Arbeit, sie produziert keine neue Funktion, und genau deshalb wird sie gern wegverhandelt. Tu das nicht. Diese Pflege ist der Unterschied zwischen einer Software, die in drei Jahren noch wartbar ist, und einer, die du dann neu bauen lässt. Wir haben das Thema warum Software nach dem Launch teuer wird ausführlicher aufgeschrieben, falls dich der Mechanismus dahinter interessiert.

Sicherheit: Lücken schliessen, bevor sie genutzt werden

Sicherheit überschneidet sich mit Updates, ist aber eigen genug für einen eigenen Punkt. Es geht um zwei Dinge. Erstens das Reagieren auf bekannt gewordene Schwachstellen: Wird eine kritische Lücke in einer verwendeten Komponente publik, muss klar sein, wer sie wie schnell schliesst. Solche Lücken werden öffentlich dokumentiert, Angreifer scannen das Netz systematisch danach ab, und der Zeitraum zwischen Bekanntwerden und Ausnutzung ist oft kurz. Eine Klausel, die für kritische Sicherheitsupdates eine eigene, schnelle Reaktionszeit festlegt, ist hier mehr wert als jede Beteuerung.

Zweitens das Verwalten von Zugängen und Geheimnissen. Wer hat Zugriff auf den Server, auf die Datenbank, auf die Schlüssel zu externen Diensten. Was passiert mit diesen Zugängen, wenn jemand aus dem Team geht. Ein Wartungsvertrag, der Sicherheit nur als wir achten darauf erwähnt, ist ein Platzhalter. Lass dir aufschreiben, was konkret getan wird. Beim Thema Anmeldung, Abrechnung und Compliance hängen oft besondere Pflichten dran, dazu haben wir Auth, Billing und Compliance im SaaS separat erklärt.

Backups: der Test zählt, nicht das Versprechen

Fast jeder Vertrag erwähnt Backups. Fast keiner erwähnt das Einzige, was zählt: ob sie sich zurückspielen lassen. Ein Backup, das nie getestet wurde, ist eine Hoffnung, kein Schutz. Wir haben mehr als einmal gesehen, dass Sicherungen jahrelang brav liefen und im Ernstfall unbrauchbar waren, weil ein Teil der Daten gar nicht erfasst wurde oder das Wiederherstellen nie geübt war.

In den Vertrag gehören drei Angaben. Wie oft wird gesichert (täglich ist meist das Minimum). Wie lange werden die Sicherungen aufbewahrt. Und, der entscheidende Punkt, wie schnell und mit welchem maximalen Datenverlust kann im Ernstfall wiederhergestellt werden. Diese letzte Zahl, wie viel Arbeit du im schlimmsten Fall verlierst, sagt mehr über die Qualität des Betriebs als jede Marketing-Aussage. Was an Monitoring, Backups und Alarmierung das absolute Minimum ist, findest du in unserem Text zum Minimum aus Monitoring, Backups und Alerting.

Die Linie zwischen Wartung und neuer Entwicklung

Jetzt zum Teil, der die meisten Streitgespräche auslöst. Wartung hält den vereinbarten Zustand. Entwicklung verändert ihn. Das ist die Linie, und sie ist schärfer, als sie im Alltag wirkt.

Ein Beispiel. Deine Software zeigt eine Liste von Bestellungen. Sie ist bei der Abnahme korrekt durchgegangen. Drei Monate später sortiert sie unter bestimmten Umständen falsch. Das ist ein Fehler, die Funktion tut nicht, was vereinbart war, und das Beheben ist Wartung. Jetzt willst du, dass die Liste zusätzlich nach Lieferdatum gefiltert werden kann. Diese Filterfunktion gab es vorher nicht, sie war nie vereinbart, sie ist neue Entwicklung. Auch wenn beides nur ein bisschen an der Bestellliste ist.

Die Verwechslung ist selten böse Absicht. Aus Nutzersicht fühlt sich beides gleich an: Ich melde etwas, jemand programmiert. Aber für die Kalkulation ist der Unterschied gross. Wartung ist planbar und sollte zum Pauschalpreis laufen. Entwicklung ist ein neues, abgegrenztes Stück Arbeit mit eigenem Aufwand. Ein guter Vertrag schreibt diese Grenze auf, idealerweise mit Beispielen aus deinem Produkt, und beschreibt den Weg, wie aus einem Änderungswunsch ein bezifferter Auftrag wird. Wer das vermischt, zahlt am Ende entweder zu viel Pauschale für Wünsche, die noch keiner kennt, oder streitet jeden Monat neu. Wenn du tiefer einsteigen willst, wie man so einen Vertrag wählt, hilft unser Vergleich von Festpreis und Time-and-Material.

Und ja, Weiterentwicklung gehört trotzdem in die Gesamtvereinbarung, nur eben als eigener Posten. Software, die nie weiterentwickelt wird, stirbt langsam an Bedeutungslosigkeit. Sinnvoll ist ein kleines monatliches Kontingent für Verbesserungen plus ein vereinbarter Stundensatz oder ein leichtes Verfahren für grössere Vorhaben. So bleibt klar, was Pflege ist und was Wachstum.

Kündigung und Übergabe: der Vertrag endet eines Tages

Der letzte Punkt ist der, an den beim Unterschreiben niemand denken will. Jeder Wartungsvertrag endet irgendwann, und wie er endet, entscheidet, ob du frei bist oder gefangen. Achte auf drei Dinge. Wie lange ist die Kündigungsfrist und bindet dich der Vertrag über Jahre. Was passiert mit deinen Daten und mit dem Zugang zur Infrastruktur, wenn Schluss ist. Und, am wichtigsten, ist eine geordnete Übergabe Teil der Vereinbarung.

Eine saubere Übergabe heisst: Du bekommst den Quellcode, die Dokumentation, die Zugänge und eine Einweisung, mit der ein anderes Team weitermachen kann. Wenn ein Wartungsvertrag dich so an einen Anbieter bindet, dass ein Wechsel praktisch unmöglich ist, ist das kein Service, das ist eine Abhängigkeit mit Rechnung. Wir haben dazu zwei eigene Texte, wem der Code gehört und wie eine Übergabe aussieht sowie wie du Vendor-Lock-in vermeidest.

Wann ein fixer Wartungsvertrag der falsche Weg ist

Wir verkaufen Wartung, also sollten wir auch sagen, wann sie nicht passt. Ein durchdefinierter Wartungsvertrag mit Verfügbarkeitszusagen und festen Reaktionszeiten lohnt sich, wenn deine Software geschäftskritisch ist und ein Ausfall echtes Geld oder Vertrauen kostet. Bei einem kleinen internen Werkzeug, das ein paar Leute gelegentlich nutzen, ist das oft überdimensioniert. Da reicht ein leichtes Modell: gesicherter Betrieb plus Aufwand nach Bedarf, ohne teure Garantien für eine Verfügbarkeit, die niemand braucht.

Es gibt einen zweiten Fall. Wenn deine Software gerade erst live ist und sich in den nächsten Monaten noch stark verändern wird, ist die Grenze zwischen Wartung und Entwicklung naturgemäss unscharf. In dieser Phase ist ein laufendes Entwicklungsmodell passender als ein starrer Wartungsvertrag, der ständig nachverhandelt wird. Der Wartungsvertrag im engeren Sinn kommt, wenn das Produkt steht und der Fokus von Bauen auf Betreiben kippt.

Dass wir diese Grenze so genau ziehen können, liegt daran, dass wir nicht nur für andere bauen. Wir betreiben unsere eigenen Produkte, Wortfreunde und Reazon, und sind damit unser eigener Wartungskunde. Jedes Backup, das wir versprechen, müssen wir selbst zurückspielen können, wenn unser eigenes System klemmt. Jede Reaktionszeit, die im Vertrag steht, halten wir nachts ein, weil sonst unser Produkt steht, nicht das eines Kunden. Das ist der Unterschied zu einer Agentur, die nach dem Launch das Projekt schliesst: Für uns hört die Arbeit beim Live-Gang nicht auf, sie fängt da an. Wie der laufende Betrieb sauber organisiert wird, ist Kern unseres Leistungsbereichs Produkt-Betrieb.

Nimm aus diesem Text vor allem eine Frage mit ins nächste Angebotsgespräch: Steht für jeden der sieben Punkte etwas Konkretes drin, oder nur eine wohlklingende Absichtserklärung. Ein Wartungsvertrag, der Zahlen, Zeiten und eine klare Übergabe nennt, schützt dich. Einer, der nur Vertrauen verspricht, schützt vor allem den, der ihn geschrieben hat.