Software-Wartung und Support: Was du nach dem Launch brauchst

Der Launch ist nicht das Ziel, sondern der Anfang. Genau das wird bei vielen Projekten unterschätzt. Software, die produktiv läuft, kostet Geld. Sie braucht Updates, Bugfixes, Security-Patches und irgendwann auch neue Features. Wer nach dem Go-Live keine Antwort auf die Frage hat, wer sich darum kümmert, hat sich gerade die nächste Baustelle gebaut.

Dieser Beitrag zeigt dir, was nach dem Launch wirklich passiert, welche Wartungsmodelle es gibt und worauf du im Vertrag achten musst.

Was nach dem Launch wirklich passiert

Nach dem Go-Live laufen mehrere Dinge gleichzeitig auf dich zu, die im Pflichtenheft selten klar benannt wurden.

Bugs, die im Live-Betrieb sichtbar werden. Tests fangen vieles ab, aber nicht alles. Sobald echte Nutzer mit echten Daten arbeiten, kommen Edge Cases hoch, die niemand vorhergesehen hat. Faustregel: In den ersten drei Monaten nach Launch entstehen die meisten Tickets, danach beruhigt es sich auf einem niedrigeren Niveau.

Sicherheitsupdates für Dependencies. Jede moderne Anwendung nutzt dutzende fremde Bibliotheken. Bei einer typischen Web-Applikation auf Node.js oder PHP kommen pro Monat mehrere Security-Advisories rein. Wer die ignoriert, hat irgendwann eine Lücke offen, die jemand schon ausnutzt.

Framework- und Sprach-Updates. PHP, Node.js, Python und alle großen Frameworks haben feste Support-Zyklen. PHP 8.2 zum Beispiel erhält nach offizieller Roadmap nur bis Ende 2026 Security-Fixes. Wer nicht regelmäßig hochzieht, landet auf einer unsicheren Version und kann irgendwann nicht mehr deployen.

Browser- und Geräte-Updates. Frontend-Code, der heute überall sauber läuft, kann nach einem Chrome- oder Safari-Update plötzlich Layout-Bugs zeigen. Das passiert nicht oft, aber es passiert.

Anforderungen, die sich durch Nutzung verschieben. Sobald Mitarbeiter oder Kunden mit der Software arbeiten, entstehen neue Wünsche. Manche sind sinnvoll, manche nicht. Beides braucht jemanden, der Prioritäten setzt und umsetzt.

Wartungsmodelle im Vergleich

Drei Modelle sind im Markt verbreitet. Welches passt, hängt davon ab, wie kritisch die Software für dein Tagesgeschäft ist und wie viel Vorhersagbarkeit du brauchst.

Stundenkontingent. Du kaufst pro Monat oder Quartal eine bestimmte Anzahl Stunden, zum Beispiel zehn Stunden im Monat. Was nicht verbraucht wird, verfällt oder wird auf den nächsten Monat übertragen. Geeignet für Software, die stabil läuft und nur gelegentlich Anpassungen braucht.

Monatliche Pauschale. Ein fester Betrag pro Monat deckt definierte Leistungen ab: Monitoring, Security-Updates, eine festgelegte Reaktionszeit, eine bestimmte Anzahl Bugfixes. Größere Änderungen werden zusätzlich abgerechnet. Geeignet für geschäftskritische Systeme, bei denen du Sicherheit über die Verfügbarkeit brauchst.

Mischmodell. Pauschale für Basis-Wartung plus Stundenkontingent für Weiterentwicklung. In der Praxis ist das die häufigste Variante, weil sie beides verbindet: Verlässlichkeit für den Betrieb und Flexibilität für neue Features.

Bei vielen Anbietern liegen die monatlichen Wartungskosten laut Webrunners typischerweise bei 15 bis 20 Prozent der ursprünglichen Projektkosten pro Jahr. Eine Software, die 60.000 Euro gekostet hat, kostet im Betrieb also realistisch zwischen 9.000 und 12.000 Euro im Jahr. Das überrascht viele, ist aber der Marktstandard.

SLA-Stufen und was sie wirklich bedeuten

Service Level Agreements regeln, wie schnell der Dienstleister reagiert und welche Verfügbarkeit garantiert wird. Drei Stufen sind üblich.

Basic. Reaktion innerhalb von 48 Stunden während normaler Geschäftszeiten, keine Verfügbarkeitsgarantie. Passt für interne Tools, die einen Ausfall von einem oder zwei Werktagen vertragen.

Standard. Reaktion innerhalb von 24 Stunden, erweiterte Geschäftszeiten, definierte Verfügbarkeit von zum Beispiel 99 Prozent im Monat. Die häufigste Stufe für mittelständische Anwendungen.

Premium. Reaktion innerhalb von vier Stunden, 24/7-Erreichbarkeit, Verfügbarkeit von 99,5 oder 99,9 Prozent. Passt für Systeme, deren Ausfall direkt Umsatz oder Produktion kostet, zum Beispiel ein Online-Shop in der Hauptsaison oder eine Anbindung an die Warenwirtschaft.

Ein Punkt wird in Verträgen oft zu schwammig formuliert: Reaktionszeit ist nicht Lösungszeit. Wenn dein SLA vier Stunden Reaktionszeit vorsieht, heißt das, dass jemand innerhalb von vier Stunden anfängt zu arbeiten. Wann das Problem gelöst ist, kann je nach Komplexität deutlich später sein. Lass dir, wenn das Problem geschäftskritisch ist, zusätzlich eine maximale Wiederherstellungszeit zusagen.

Was im Wartungsvertrag stehen muss

Ein guter Wartungsvertrag enthält ein paar Klauseln, die später Streit verhindern.

Klar abgegrenzter Leistungsumfang. Was ist Wartung, was Weiterentwicklung, was ist eine Störung. Diese Begriffe werden in der Praxis ständig verwechselt. Wer das im Vertrag schon trennt, spart sich Diskussionen.

Sourcecode-Übergabe und Zugang zu Repositories. Du brauchst jederzeit Zugriff auf den vollständigen Quellcode, auch wenn die Zusammenarbeit endet. Ohne Code keine Verhandlungsposition.

Dokumentation. Mindestanforderung: technische Architekturübersicht, Liste aller Dependencies, Deployment-Anleitung, Zugangsdaten in einem Passwort-Manager.

Eskalationsweg. Ein Name plus eine Mobilnummer, nicht nur eine zentrale Hotline.

Kündigungsfristen und Übergaberegelung. Drei Monate sind ein typischer Standard. Wichtig ist, dass eine geordnete Übergabe an einen anderen Dienstleister möglich ist und im Vertrag bezahlt wird.

Preisanpassung. Stundensätze steigen über die Jahre. Klär im Vertrag, in welchem Rhythmus angepasst werden darf und auf welcher Basis.

Häufige Fehler nach dem Launch

Drei Muster sehen wir in unseren Beratungsprojekten immer wieder.

Erstens: Wartung wird gar nicht beauftragt. Die Software läuft, also denkt niemand drüber nach. Sechs Monate später kommt ein Sicherheitsvorfall, und plötzlich braucht es eine Notfallintervention zu Notfallpreisen.

Zweitens: Die Wartung wird beim ursprünglichen Entwickler gebucht, ohne dass es einen schriftlichen Vertrag gibt. Solange es läuft, ist das egal. Wenn der Entwickler weg ist, krank wird oder die Preise drastisch erhöht, hast du keine Grundlage und keinen Plan B.

Drittens: Die monatliche Pauschale ist zu niedrig, um echte Arbeit zu finanzieren. Dann werden nur kleinste Sachen erledigt, der Backlog wächst, und nach zwei Jahren steht ein größeres Modernisierungsprojekt an, das deutlich teurer wird als eine ordentliche laufende Pflege.

Was du jetzt tun solltest

Wenn deine Software schon läuft und keinen klaren Wartungsvertrag hat, dann ist genau jetzt der richtige Moment. Drei Schritte reichen für den Anfang.

Erstens: Lass dir vom aktuellen Dienstleister oder einem unabhängigen Prüfer eine Bestandsaufnahme machen. Was läuft, welche Versionen sind im Einsatz, welche Lücken sind offen.

Zweitens: Definier ein Wartungsmodell, das zur tatsächlichen Kritikalität passt. Lieber eine ehrliche Standard-SLA als ein Premium-Versprechen, das im Ernstfall nicht eingehalten werden kann.

Drittens: Schreib das Ergebnis in einen Vertrag, der die oben genannten Punkte enthält. Eine E-Mail-Vereinbarung ist keine Grundlage.

Wenn du dir bei deiner aktuellen Situation unsicher bist oder einen unabhängigen Blick brauchst, schau dir unsere individuelle Softwareentwicklung an. Wir übernehmen sowohl Neuentwicklung als auch die Pflege bestehender Systeme, die wir nicht selbst gebaut haben.