Wartungsvertrag für Individualsoftware: Strategie, Inhalte und Praxis

Individualsoftware ist kein Standardprodukt — und ihr Wartungsvertrag sollte es auch nicht sein. Während Hersteller-Wartungsverträge für Standardsoftware klare Grenzen haben, eröffnet die Wartung von Eigenentwicklungen ganz andere Fragen: Wer kennt den Code? Was passiert beim Teamwechsel? Wie bleibt die Architektur zukunftsfähig? Dieser Leitfaden zeigt, worauf es ankommt.
Zwei Geschätfsleute sitzen vor einem Notebook und schütteln sich die Hände. Sie haben gerade einen Wartungsvertrag für Individualsoftware unterschrieben.
© Grady Reese/peopleimages.com

Warum Individualsoftware einen eigenen Wartungsvertrag braucht

Wer Standardsoftware einsetzt, kauft ein fertiges Produkt mit einem fertigen Wartungskonzept. Der Hersteller liefert Patches, schließt Sicherheitslücken und stellt eine Hotline bereit. Fällt der Support aus, gibt es Alternativen am Markt. Bei Individualsoftware sieht das grundlegend anders aus.

Eine maßgeschneiderte Anwendung entsteht für einen konkreten Geschäftsprozess. Es gibt keinen Hersteller-Support, keine automatischen Updates, kein standardisiertes Patch-Management. Der Quellcode existiert in genau einer Version, und das Wissen über seine Architektur liegt bei den Entwicklern, die ihn geschrieben haben. Verlässt dieses Wissen das Projekt — etwa durch einen Personalwechsel oder das Ende einer Agenturbeziehung — steht das Unternehmen vor einem ernsthaften Problem.

Genau deshalb braucht Individualsoftware einen Wartungsvertrag, der über die üblichen Standardklauseln hinausgeht. Er muss nicht nur regeln, wer Fehler behebt und Sicherheitsupdates einspielt, sondern auch, wie Code-Wissen erhalten bleibt, wie Abhängigkeiten aktuell gehalten werden und wie die Software langfristig weiterentwicklungsfähig bleibt. Ein allgemeiner Wartungsvertrag für Software deckt die Grundlagen ab. Für Eigenentwicklungen reicht das nicht.

Was einen guten Wartungsvertrag für Eigenentwicklungen ausmacht

Der entscheidende Unterschied liegt in der Tiefe. Ein Wartungsvertrag für Individualsoftware muss Themen adressieren, die bei Standardsoftware schlicht nicht existieren.

Code-Dokumentation als Vertragsbestandteil. Bei einer Eigenentwicklung ist der Quellcode das zentrale Asset. Der Wartungsvertrag sollte festlegen, dass die Dokumentation der Architektur, der Datenbankstrukturen und der Deployment-Prozesse kontinuierlich gepflegt wird — nicht als nachträgliche Pflichtübung, sondern als laufende Leistung. Ohne aktuelle Dokumentation wird jeder Dienstleisterwechsel zum Risiko.

Wissenstransfer und Redundanz. Was passiert, wenn der einzige Entwickler, der die Kernlogik kennt, das Team verlässt? Ein belastbarer Wartungsvertrag regelt, dass mindestens zwei Personen auf Seiten des Dienstleisters mit dem System vertraut sind. Regelmäßige Code-Reviews und Pair-Programming-Sessions sichern dieses Wissen ab.

Abhängigkeitsmanagement. Individualsoftware basiert auf Frameworks, Libraries und Drittkomponenten. Diese Abhängigkeiten veralten — oft schneller als erwartet. Ein Laravel-Projekt von 2022 läuft auf einem Framework, das 2026 nicht mehr mit Sicherheitsupdates versorgt wird. Der Wartungsvertrag sollte definieren, wer für die Aktualisierung dieser Abhängigkeiten verantwortlich ist, in welchem Rhythmus geprüft wird und wie mit End-of-Life-Komponenten umgegangen wird.

Architektur-Reviews. Software, die über Jahre gewartet wird, akkumuliert technische Schulden. Funktionen werden ergänzt, Workarounds eingebaut, Anforderungen ändern sich. Ein guter Wartungsvertrag enthält deshalb regelmäßige Architektur-Reviews — etwa halbjährlich —, die den Zustand der Software bewerten und Handlungsempfehlungen liefern, bevor aus technischen Schulden ein strukturelles Problem wird.

Kostenmodelle im Vergleich

Neben den gängigen Abrechnungsmodellen — Pauschale, Kontingent und Time & Material — gelten für Individualsoftware besondere Überlegungen:

Die 15-25%-Faustregel

Als Orientierung gilt: Die jährlichen Wartungskosten für Individualsoftware liegen bei 15 bis 25 Prozent der ursprünglichen Entwicklungskosten. Eine Software, die 200.000 Euro in der Entwicklung gekostet hat, verursacht also zwischen 30.000 und 50.000 Euro Wartungskosten pro Jahr — oder 2.500 bis 4.200 Euro monatlich. Die Spanne ergibt sich aus dem gewünschten Leistungsumfang: Basiswartung mit Monitoring und Sicherheitsupdates liegt am unteren Ende, umfassende Betreuung mit garantierten Reaktionszeiten, proaktiver Optimierung und regelmäßigen Architektur-Reviews am oberen.

Wann ein Kontingent-Modell sinnvoller ist

Bei Individualsoftware schwankt der Wartungsbedarf typischerweise stärker als bei Standardlösungen. Nach einem größeren Release fallen mehr Anpassungen an, in stabilen Phasen weniger. Ein Kontingent-Modell mit Übertragbarkeit nicht genutzter Stunden bildet diese Realität besser ab als eine starre Pauschale.

Wann Managed Service die bessere Wahl ist.

Wenn intern kein technisches Know-how für die Steuerung der Wartung vorhanden ist, lohnt sich ein Managed-Service-Ansatz. Der Dienstleister übernimmt dabei die vollständige Verantwortung — vom Monitoring über das Incident Management bis zur proaktiven Weiterentwicklung. Mehr dazu bietet unser Leitfaden zum Application Management.

SLA-Bausteine für Individualsoftware

Die grundlegenden Bestandteile eines Service Level Agreements — Verfügbarkeit, Reaktionszeiten, Eskalationsstufen — gelten universell. Bei Individualsoftware kommen jedoch Parameter hinzu, die in Standard-SLAs fehlen.

Deployment-Frequenz und Release-Management. Wie oft werden Updates eingespielt? Gibt es feste Release-Zyklen oder wird bei Bedarf deployt? Wie wird sichergestellt, dass ein Deployment die Produktion nicht beeinträchtigt? Bei Eigenentwicklungen ohne automatisierte CI/CD-Pipeline ist dieser Punkt besonders kritisch.

Hotfix-Zeiten vs. Feature-Zeiten. Ein SLA für Individualsoftware sollte klar zwischen der Behebung von Produktionsfehlern und der Umsetzung von Änderungswünschen unterscheiden. Für kritische Fehler gelten enge Zeitfenster — etwa vier Stunden Reaktionszeit bei einem Totalausfall. Für Feature-Requests hingegen ist ein anderer Prozess sinnvoll, der über ein Ticket-System und priorisierte Backlogs gesteuert wird.

Testabdeckung als KPI. Ein ungewöhnlicher, aber wirkungsvoller SLA-Baustein: Die Vereinbarung einer Mindest-Testabdeckung. Liegt die Testabdeckung bei Übernahme bei 30 Prozent, kann vertraglich festgelegt werden, dass sie innerhalb von zwölf Monaten auf 60 Prozent steigt. Das senkt langfristig die Fehlerquote und die Wartungskosten.

Code-Qualitäts-Metriken. Ähnlich wie die Testabdeckung lassen sich auch andere Qualitätsindikatoren vertraglich verankern: zyklomatische Komplexität, Anzahl bekannter Sicherheitslücken in Abhängigkeiten, technische Schulden-Quote. Diese Metriken machen die Qualität der Wartung messbar — und schaffen Transparenz für beide Seiten.

Sicherheitsanforderungen im Wartungsvertrag: ISO 27001 und NIS-2

Software, die personenbezogene oder geschäftskritische Daten verarbeitet, braucht einen Wartungsvertrag, der Sicherheit nicht dem Zufall überlässt. Seit dem Inkrafttreten des NIS-2-Umsetzungsgesetzes gilt das verschärft: Betroffene Unternehmen müssen nachweisen, dass auch ihre Dienstleister angemessene Sicherheitsstandards einhalten — einschließlich der Wartungspartner.

Dokumentiertes Change Management. Jede Änderung am Produktivsystem — ob Bugfix, Konfigurationsanpassung oder Framework-Update — wird dokumentiert, geprüft und freigegeben. ISO 27001 verlangt diesen Prozess über Control 8.32 (Change Management). Im Wartungsvertrag übersetzt sich das in klare Regeln: Wer darf Änderungen genehmigen? Wie werden sie getestet? Wie wird der Auftraggeber informiert?

Zugriffskontrollen für die Produktionsumgebung. Der Wartungsvertrag definiert, wer auf welche Systeme zugreifen darf — und dokumentiert das. Zugänge werden nach dem Least-Privilege-Prinzip vergeben und regelmäßig überprüft. Wenn ein Mitarbeiter das Wartungsteam verlässt, wird sein Zugang umgehend entzogen.

Patch-Management-Pflichten. Der Vertrag legt fest, innerhalb welcher Fristen Sicherheitsupdates eingespielt werden. Kritische Patches — etwa bei aktiv ausgenutzten Schwachstellen — innerhalb von 24 bis 48 Stunden. Reguläre Updates im vereinbarten Rhythmus, typischerweise monatlich.

Incident-Response-Zeiten. Neben den klassischen SLA-Reaktionszeiten für Fehlerbehebung definiert ein sicherheitsbewusster Wartungsvertrag auch Reaktionszeiten für Sicherheitsvorfälle: Wie schnell wird der Auftraggeber informiert? Wer koordiniert die Sofortmaßnahmen? Wie wird die Kommunikation gegenüber Aufsichtsbehörden unterstützt?

Audit-Trails und Nachweisfähigkeit. Alle sicherheitsrelevanten Aktivitäten im Rahmen der Wartung werden protokolliert: Zugriffe, Änderungen, Deployments, Vorfälle. Diese Audit-Trails ermöglichen es dem Auftraggeber, bei internen oder externen Prüfungen lückenlose Nachweise vorzulegen.

Vendor Lock-in vermeiden: Übergabe und Dokumentation

Einer der häufigsten Fehler bei Wartungsverträgen für Individualsoftware: Es wird nicht geregelt, was passiert, wenn die Zusammenarbeit endet. Das Ergebnis ist ein Vendor Lock-in — eine Abhängigkeit vom Dienstleister, die den Wechsel praktisch unmöglich macht. Strategien zur Vermeidung finden sich im Leitfaden Vendor Lock-in vermeiden.

Code-Ownership klar regeln.

Der Quellcode gehört dem Auftraggeber. Das klingt selbstverständlich, ist es aber nicht immer. Der Wartungsvertrag sollte explizit festhalten, dass sämtlicher Code, der im Rahmen der Wartung entsteht oder verändert wird, im Eigentum des Auftraggebers liegt. Gleiches gilt für Dokumentation, Konfigurationen und Deployment-Skripte.

Exit-Strategie als Vertragsbestandteil.

Ein professioneller Wartungsvertrag enthält eine Übergabeklausel. Sie regelt: Wie wird der Code übergeben? In welchem Zeitraum? Welche Dokumentation muss vorliegen? Gibt es eine Einarbeitungsphase für den neuen Dienstleister? Diese Regelung schützt nicht nur den Auftraggeber — sie signalisiert auch, dass der Dienstleister von der Qualität seiner Arbeit überzeugt ist.

Laufende Dokumentationspflicht.

Übergabedokumentation, die erst bei Vertragsende erstellt wird, ist in der Praxis oft lückenhaft. Besser: Die Dokumentation wird als Teil der laufenden Wartung gepflegt und ist jederzeit aktuell. Das reduziert das Risiko bei einem Wechsel erheblich — und kommt auch dem laufenden Betrieb zugute, weil neue Teammitglieder schneller eingearbeitet werden.

Wartungsvertrag für verschiedene Technologie-Stacks

Nicht jede Individualsoftware stellt dieselben Anforderungen an die Wartung. Der Technologie-Stack beeinflusst, welche Schwerpunkte der Vertrag setzen sollte.

Der Weg zum passenden Wartungsvertrag

Ist-Analyse: Wo steht die Software heute?

Bevor ein Wartungsvertrag verhandelt wird, braucht es ein ehrliches Bild des aktuellen Zustands. Wie alt ist der Code? Welche Abhängigkeiten sind veraltet? Gibt es automatisierte Tests? Wie ist die Dokumentation? Eine solche Ist-Analyse — idealerweise durch den künftigen Wartungspartner durchgeführt — bildet die Grundlage für den Leistungsumfang und die Kalkulation.

Anforderungen definieren: Was soll der Vertrag leisten?

Die Anforderungen ergeben sich aus dem Geschäftskontext. Ein Onlineshop mit 24/7-Betrieb braucht andere Reaktionszeiten als ein internes Verwaltungstool, das nur werktags genutzt wird. Die SLA-Parameter, der gewünschte Leistungsumfang und das Budget sollten vor der Anbieterauswahl feststehen.

Anbieter auswählen: Kompetenz vor Preis

Ein günstiger Wartungsvertrag, der im Ernstfall nicht greift, ist teurer als ein angemessen kalkulierter. Entscheidend ist, ob der Dienstleister Erfahrung mit dem jeweiligen Technologie-Stack hat, ob er die nötige Teamstärke mitbringt und ob Zertifizierungen wie ISO 27001 vorliegen. Für Softwarewartung in Berlin stehen mehrere Anbieter zur Verfügung — ein lokaler Partner bietet Vorteile bei persönlichem Austausch und schnellen Vor-Ort-Einsätzen.

Onboarding: Der Start der Zusammenarbeit

Die ersten Wochen nach Vertragsabschluss sind entscheidend. Der Dienstleister muss sich in den Code einarbeiten, Zugänge erhalten, Monitoring einrichten und Ansprechpartner auf beiden Seiten benennen. Ein strukturiertes Onboarding mit definierten Meilensteinen stellt sicher, dass die Wartung vom ersten Tag an funktioniert — und nicht erst nach Monaten des Einarbeitens.

Weiterführende Informationen