Was Software-Wartung pro Jahr wirklich kostet

Die meisten Unternehmer erfahren auf die harte Art, was Software-Wartung kostet: nachdem sie aufgehört haben, dafür zu zahlen, und etwas kaputtgegangen ist. Vorher ist Wartung meist ein Posten, den niemand genauer hinterfragt – eine Zahl, die ein Entwickler einmal genannt hat und die seitdem alle wiederholen, ohne zu prüfen, ob sie noch Sinn ergibt. Wer eine individuelle Anwendung, ein Kundenportal, ein internes Tool oder irgendetwas anderes gebaut hat, das den Geschäftsbetrieb täglich trägt, braucht eine echte Zahl – keine Schätzung – und muss wissen, was passiert, wenn man sich entscheidet, die Wartung auszusetzen.

Die Faustregel – und warum sie sich bewährt

Die in der Branche häufig zitierte Spanne für jährliche Software-Wartungskosten liegt bei 15 bis 25 Prozent der ursprünglichen Entwicklungskosten, und in der Praxis trifft diese Spanne für typische Business-Anwendungen gut zu, sobald man alles berücksichtigt, was Wartung tatsächlich abdeckt. Hat eine individuelle Anwendung 80.000 Euro in der Entwicklung gekostet, liegt ein realistisches jährliches Wartungsbudget zwischen 12.000 und 20.000 Euro, also etwa 1.000 bis 1.700 Euro im Monat. Für ein kleineres internes Tool, das für 25.000 Euro entwickelt wurde, sinkt das auf 3.750 bis 6.250 Euro im Jahr, also näher an 300 bis 500 Euro im Monat.

Diese Spannen sind bewusst weit gefasst, denn die Wartungskosten hängen von Faktoren ab, die nichts mit dem ursprünglichen Entwicklungspreis zu tun haben: wie viele Drittanbieter-Pakete die Anwendung nutzt, ob sie Zahlungs- oder personenbezogene Daten verarbeitet, wie oft das Unternehmen das Produkt verändern möchte, und wie viel technische Schulden bereits beim ursprünglichen Bau entstanden sind. Ein hastig umgesetztes MVP, das 40.000 Euro gekostet hat, kann durchaus mehr monatliche Wartung brauchen als eine sorgfältig gebaute 60.000-Euro-Anwendung, weil das hastige MVP schneller Probleme ansammelt.

Es gibt auch eine Obergrenze, die man kennen sollte. Oberhalb von etwa 30 bis 35 Prozent der ursprünglichen Entwicklungskosten pro Jahr hat man die Anwendung in der Regel nicht mehr nur gewartet, sondern beginnt, sie Stück für Stück neu zu bauen – und an diesem Punkt lohnt sich die Frage, ob ein Teil-Rebuild nicht tatsächlich günstiger wäre als ein weiteres Jahr des Flickens an denselben strukturellen Problemen.

Wofür der Monatsbetrag tatsächlich bezahlt

Ein Wartungsbudget ist keine einzelne Sache. Es deckt mindestens vier getrennte Kategorien ab, und ein Anbieter, der eine pauschale Zahl nennt, ohne diese aufzuschlüsseln, verschweigt meist, welche davon er auslässt.

Sicherheits-Patching ist die wichtigste Kategorie und wird am häufigsten ausgelassen. Wird eine Schwachstelle in einem Framework oder einem Paket bekannt, von dem die Anwendung abhängt, muss jemand den Fix anwenden, testen und ausliefern – oft innerhalb weniger Tage, statt auf den nächsten geplanten Update-Zyklus zu warten. Allein das kann 20 bis 30 Prozent eines typischen monatlichen Wartungsbudgets für eine Anwendung mit moderater Anzahl an Abhängigkeiten ausmachen.

Routinemäßige Dependency-Updates sind der planbare Teil: Laufzeitumgebung, Framework und Drittanbieter-Pakete aktuell halten, damit die Lücke zwischen der eigenen Version und der neuesten unterstützten Version nie so groß wird, dass sie zu einem eigenen Projekt wird. Das ist meist der größte Einzelposten, oft 40 Prozent oder mehr des monatlichen Gesamtbudgets, weil es wiederkehrende Arbeit ist – unabhängig davon, ob in der jeweiligen Woche etwas kaputt ist.

Bugfixes und kleine Anpassungen decken Probleme ab, die im normalen Betrieb auftauchen – Dinge, die eine Staging-Umgebung nicht erfasst hat, oder Randfälle, die echte Kunden finden und die eine Testsuite nicht vorhergesehen hat. Das Budget dafür variiert am stärksten je nach Anwendung, aber 20 bis 30 Prozent des monatlichen Gesamtbetrags sind typisch, und es tendiert in den Monaten direkt nach einem größeren Release nach oben.

Monitoring und Reporting, der kleinste Posten, deckt Uptime-Checks, Fehler-Tracking und eine monatliche Zusammenfassung ab, die tatsächlich zeigt, was passiert ist, statt einer vagen Zusicherung, dass alles in Ordnung sei. Das ist oft das Erste, was aus einem Wartungsvertrag mit festem Budget gestrichen wird – und gleichzeitig der Teil, der zeigt, ob die anderen drei überhaupt gemacht werden. Ein Anbieter, der keinen einfachen Monatsbericht liefern kann, verfolgt die Arbeit wahrscheinlich auch nicht genau genug, um dafür einen fairen Preis zu berechnen.

Was zwei Jahre ausgesetzte Wartung kostet

Hier versteckt sich der eigentliche Preis. Ein Unternehmen, das die Wartung ein oder zwei Jahre aussetzt, spart die 15 bis 25 Prozent nicht ein – es verschiebt sie, und aufgeschobene Wartung summiert sich auf eine Weise, die schlimmer ist, als die meisten erwarten.

Nach einem Jahr ohne Updates ist die Lücke zwischen den Abhängigkeiten der Anwendung und den aktuell unterstützten Versionen meist so groß geworden, dass ein Routine-Update keine Routine mehr ist. Ein Framework-Upgrade, das im normalen Zyklus ein paar Stunden gedauert hätte, erfordert jetzt, nachzuvollziehen, was sich über ein Jahr an Releases verändert hat – weil niemand es laufend verfolgt hat.

Nach zwei Jahren treffen meist mehrere Dinge gleichzeitig zu. Die Laufzeitumgebung oder das Framework nähert sich wahrscheinlich dem eigenen End-of-Life-Datum oder hat es bereits überschritten, was bedeutet, dass Sicherheitspatches für die eingesetzte Version komplett eingestellt wurden. Mehrere Hauptversionen wichtiger Abhängigkeiten wurden übersprungen, sodass das Update kein einzelner Schritt mehr ist, sondern eine Migration mit eigenem Testaufwand und dem Risiko, dass sich brechende Änderungen übereinanderstapeln. Und weil niemand darauf geachtet hat, besteht eine reale Chance, dass eine bekannte Schwachstelle die ganze Zeit über in Produktion lag, einfach weil niemand hingeschaut hat.

Die entscheidende Zahl: Unternehmen, die die Wartung zwei Jahre lang aussetzen, zahlen beim Aufholen typischerweise das 2- bis 4-Fache der aufgeschobenen Wartungskosten, sobald man die Migrationsarbeit, den erweiterten Testaufwand, um sicherzustellen, dass nichts still kaputtgegangen ist, und die Zeit für die Recherche einbezieht, was sich über zwei Jahre unverfolgter Updates verändert hat. Ein Unternehmen, das über zwei Jahre hinweg 24.000 Euro für kontinuierliche Wartung ausgegeben hätte, zahlt am Ende oft 50.000 bis 90.000 Euro, um dieselbe Anwendung in einem einzigen Kraftakt auf den aktuellen Stand zu bringen – und das, bevor man Ausfallzeiten oder Datenprobleme mitzählt, die die aufgeschobenen Schwachstellen unterwegs verursacht haben.

Warum der Monatsbetrag günstiger ist, als er aussieht

Als jährlicher Prozentsatz dargestellt, klingt Software-Wartung nach Overhead. Im Vergleich zu den Nachholkosten nach zwei Jahren wirkt sie eher wie eine Versicherung mit planbarer Prämie. Die Unternehmen, die am Ende am meisten für Wartung zahlen, sind durchgängig die, die versucht haben, überhaupt nicht dafür zu zahlen – denn die Arbeit verschwindet nicht, nur weil man aufhört, jemanden dafür zu bezahlen. Sie verschiebt sich lediglich nach hinten, wird teurer und kommt in einem Moment an, den man sich nicht ausgesucht hat.

Wer herausfinden möchte, wie ein realistisches Budget für die eigene Anwendung aussieht, sollte zunächst wissen, was gebaut wurde und was es noch wert ist, auf diesem Niveau gewartet zu werden. Ein kurzes Codebase-Assessment zeigt, wo die eigenen Abhängigkeiten tatsächlich im Verhältnis zur 15-bis-25-Prozent-Spanne stehen, statt sich auf eine Zahl zu verlassen, die ein Anbieter einmal genannt und nie wieder überprüft hat. Für Anwendungen, die diesen Punkt bereits überschritten haben, kann ein laufendes Code-Qualitäts-Consulting-Engagement die Nachholarbeit in einen Plan einbinden, der zu einem nachhaltigen Monatsbetrag zurückführt statt zu einer einmaligen Notfallrechnung. Hat die Anwendung das Patchen vollständig hinter sich gelassen, ist Legacy-Code-Modernisierung das ehrlichere Gespräch, bevor ein weiteres Jahr Wartungsbudget in dieselben strukturellen Probleme fließt.

Wer eine zweite Meinung dazu möchte, was die eigene Wartungsvereinbarung kosten sollte, oder ob eine zweijährige Lücke im eigenen Stack bereits teurer ist, als sie aussieht, meldet sich unter hello@wolf-tech.io oder schaut vorbei auf wolf-tech.io.