Wartungsvertrag für Symfony-Anwendungen: Was Reaktionszeit, Wiederherstellungszeit und Patch-Takt wirklich regeln müssen

Inhalt

1. Ausgangslage: Was ein Wartungsvertrag eigentlich absichern soll
2. Drei Vertragsmodelle im Vergleich
3. Die Klauseln, an denen Sie einen tragfähigen Vertrag erkennen
4. Aus der Praxis
5. Was Sie jetzt prüfen sollten

Ein Montagmorgen, der Checkout im Kundenportal wirft Fehler. Die Störung wird gemeldet, nach einer Stunde kommt die Antwort des Dienstleisters: Man schaue sich das an. Vertraglich ist damit alles erfüllt. Die vereinbarte Reaktionszeit wurde eingehalten. Wann die Anwendung wieder läuft, steht in keiner Klausel.

Genau hier liegt die häufigste Lücke in Wartungsverträgen. Der Vergabeblog weist darauf hin, dass Reaktionszeit und Wiederherstellzeit in SLAs oft verwechselt werden und in vielen Verträgen nur die Reaktionszeit vereinbart ist. Für eine Symfony-Anwendung kommt eine zweite Lücke dazu: Es fehlt ein verbindlicher Takt, in dem PHP, Symfony und die Abhängigkeiten aktualisiert werden. Beides fällt im Alltag nicht auf. Es fällt auf, wenn etwas kaputtgeht oder wenn ein Supportende erreicht ist.

Dieser Artikel zeigt, welche Klauseln einen Wartungsvertrag für Symfony-Anwendungen tragfähig machen. Er setzt dort an, wo Themen wie Projektübernahme oder Rewrite oder Refactoring aufhören: beim Dauerbetrieb nach dem Wechsel.

Ausgangslage: Was ein Wartungsvertrag eigentlich absichern soll

Eine Symfony-Anwendung bleibt nicht stabil, nur weil niemand etwas an ihr ändert. Die Plattform darunter bewegt sich ständig. Ein Blick auf die nächsten Monate zeigt den Takt:

Wer auf einer Version ohne Langzeitsupport arbeitet, muss also regelmäßig auf die nächste Minor-Version wechseln, um weiter Korrekturen zu bekommen. Wer auf Symfony 7.4 LTS setzt, hat mehr Ruhe bei den Versionswechseln. Patch-Releases und Updates der Abhängigkeiten fallen trotzdem an. Welche Strategie zu Ihrem Projekt passt, beschreibt der Artikel Symfony LTS oder aktuelle Version.

Ein Wartungsvertrag muss deshalb zwei Dinge absichern. Erstens: Was passiert, wenn etwas ausfällt? Zweitens: Wer sorgt dafür, dass die Anwendung mit diesem Takt Schritt hält? Die IT-Recht-Kanzlei ordnet das SLA als eigenes Regelwerk für Leistungsstörungen ein, unabhängig davon, wie der Grundvertrag rechtlich typisiert ist. Das macht deutlich, warum die Formulierungen dort so genau sein müssen. Was nicht drinsteht, lässt sich im Störungsfall schwer einfordern.

Drei Vertragsmodelle im Vergleich

Modell 1: Stundenkontingent auf Abruf

Sie kaufen ein Kontingent und rufen bei Bedarf ab. Das ist flexibel und für kleine Anwendungen mit wenig Änderungen oft ausreichend.

Die Schwäche zeigt sich bei der Planung. Updates passieren nur, wenn jemand sie anstößt. In der Praxis werden sie aufgeschoben, solange nichts brennt. Nach einem Jahr ohne Updates ist der Schritt auf die nächste Version deutlich größer als zwölf kleine Schritte. Die Kosten fallen dann gebündelt an, meist zu einem Zeitpunkt, den ein Supportende vorgibt und nicht Sie.

Modell 2: Wartungsvertrag mit Reaktionszeit

Das verbreitete Modell. Der Dienstleister verpflichtet sich, innerhalb einer festen Zeit auf Störungen zu reagieren. Oft sind regelmäßige Updates pauschal enthalten, ohne Takt und ohne Umfang.

Das wirkt abgesichert. Tatsächlich ist nur die erste Antwort vereinbart. Ob eine Störung nach zwei Stunden oder nach drei Tagen behoben ist, bleibt offen. Und „regelmäßige Updates“ ohne Definition lassen offen, ob damit Patch-Releases, Minor-Wechsel oder auch das nächste Major-Upgrade gemeint sind. Genau darüber entsteht später Streit.

Modell 3: Betriebsvertrag mit Wiederherstellungszeit und Patch-Takt

Hier sind Störungen nach Schwere eingeteilt, jeweils mit Reaktions- und Wiederherstellungszeit. Dazu kommt ein fester Rhythmus für Updates und eine klare Regel, wie Versionswechsel vor einem Supportende geplant werden.

Dieses Modell ist aufwendiger zu verhandeln und bindet den Dienstleister stärker. Dafür wissen beide Seiten, was im Ernstfall gilt. Es lohnt sich für Anwendungen, bei denen ein Ausfall Umsatz kostet oder Kunden direkt betrifft.

Wer das falsche Modell wählt, merkt es selten sofort. Die Folgen kommen verzögert: ein Ausfall, der sich über Tage zieht, weil niemand zur Wiederherstellung verpflichtet war, oder ein Versionswechsel, der unter Zeitdruck nachgeholt werden muss. Wie sich solche aufgeschobenen Kosten gegenüber der Geschäftsführung beziffern lassen, steht im Artikel Technische Schulden quantifizieren.

Die Klauseln, an denen Sie einen tragfähigen Vertrag erkennen

Störungsklassen mit Reaktions- und Wiederherstellungszeit

Ein Fehler in einer selten genutzten Exportfunktion ist etwas anderes als ein ausgefallener Checkout. Ein tragfähiger Vertrag teilt Störungen nach Schwere ein und definiert für jede Klasse beide Zeiten. Wichtig ist eine Formulierung, die festlegt, was „wiederhergestellt“ bedeutet. Das kann die vollständige Behebung sein oder ein Workaround, der den Betrieb vorläufig sichert. Beides ist legitim, solange es im Vertrag steht.

Ein fester Patch-Takt

Symfony veröffentlicht für unterstützte Versionen regelmäßig Patch-Releases, Sicherheitskorrekturen auch außer der Reihe. Der Vertrag sollte einen Grundtakt für Updates festlegen und gesondert regeln, wie schnell sicherheitsrelevante Fixes eingespielt werden. Benennen Sie dabei, was dazugehört: PHP, Symfony, die übrigen Composer-Abhängigkeiten und bei Bedarf die Frontend-Pakete. Ein Update-Bericht nach jedem Durchlauf macht den Takt nachprüfbar.

Eine Regel für Versionswechsel

Patch-Updates sind Routine. Der Wechsel auf eine neue Minor- oder Major-Version ist ein kleines Projekt. Der Vertrag sollte festlegen, wer Supportenden im Blick behält, mit welchem Vorlauf ein Wechsel geplant wird und ob er im Wartungsumfang enthalten ist oder gesondert beauftragt wird. Ohne diese Regel landet der Wechsel im Graubereich und wird aufgeschoben.

Vertretung und Dokumentation

Eine Wiederherstellungszeit ist nur so belastbar wie die Person, die sie einhalten soll. Gerade bei kleinen Dienstleistern gehört eine Vertretungsregelung in den Vertrag. Die Artikel zum Bus-Faktor und zu Vertretungsregelungen in der Praxis beschreiben, worauf es dabei ankommt. Eine Dokumentationspflicht für Deployment, Infrastruktur und Zugänge macht die Vertretung erst möglich.

Wenn Ihr Vertrag diese vier Punkte abdeckt, sichert er den Betrieb ab. Fehlen die Wiederherstellungszeit oder der Patch-Takt, sichert er im Wesentlichen ab, dass jemand ans Telefon geht.

Aus der Praxis

Für Kundenprojekte setze ich standardmäßig auf Symfony 7.4 LTS, sofern der Kunde nichts anderes wünscht. Lotse CMS, mein eigenes Symfony-CMS, läuft auf derselben Basis. Der Grund ist der Wartungstakt: Auf einer LTS-Version bleiben die regelmäßigen Updates Patch-Releases, die sich in einem festen Rhythmus einspielen lassen. Größere Versionswechsel lassen sich mit langem Vorlauf planen, statt alle paar Monate eine neue Minor-Version nachziehen zu müssen. Für einen Wartungsvertrag heißt das: Der vereinbarte Takt ist realistisch einhaltbar und der Aufwand bleibt planbar.

Was Sie jetzt prüfen sollten

Nehmen Sie Ihren aktuellen Wartungsvertrag und suchen Sie zwei Stellen: die vereinbarte Wiederherstellungszeit und den Takt, in dem PHP, Symfony und Abhängigkeiten aktualisiert werden. Finden Sie beides, ist die Grundlage tragfähig. Fehlt eines davon, lohnt sich ein Gespräch mit Ihrem Dienstleister, bevor die nächste Störung oder das nächste Supportende es erzwingt. Die Termine bis Januar 2027 sind ein guter Anlass. Wer dafür einen Partner sucht, findet auf der Seite zum Symfony-Entwickler für Wartung und Betrieb den Einstieg. Die rechtliche Ausgestaltung des Vertrags gehört in die Hände Ihrer Rechtsberatung, die technischen Werte darin sollten aber aus dem Betrieb kommen.