Supportzeitraum planen: vom Enddatum rückwärts rechnen
Supportzeitraum planen, bevor beschafft wird
Das Enddatum steht Jahre im Voraus fest. Gehandelt wird trotzdem erst kurz davor. Als der Support für Windows 10 im Oktober 2025 auslief, erhielten 77 Prozent der kleinen Unternehmen keine Sicherheitsupdates mehr für ihr Office-Paket. Die Erhebung des Anbieters Intra2net umfasste 104 deutsche Unternehmen mit 10 bis 49 Beschäftigten. Das Enddatum war seit Jahren öffentlich bekannt, die Umstellung trotzdem nicht vorbereitet.
Der Supportzeitraum bezeichnet die Zeitspanne, in der ein Softwareprodukt vom Anbieter mit Sicherheitsupdates, Fehlerbehebungen und technischer Unterstützung versorgt wird. Er beginnt mit der Freigabe einer Version und endet zu einem festgelegten Datum. Nach diesem Datum bleibt die Software lauffähig, erhält aber keine Korrekturen mehr für neu entdeckte Schwachstellen.
Was der Supportzeitraum tatsächlich abdeckt
Der Begriff wird oft mit dem Wartungsvertrag gleichgesetzt. Das greift zu kurz, denn ein Vertrag regelt die Leistungstiefe und der Supportzeitraum die Zeitachse. Eine Anwendung kann einen umfassenden Vertrag haben und trotzdem auf einer Komponente laufen, deren Support in achtzehn Monaten endet. Die Einordnung dieser Zeitachse in die übrigen Phasen einer Systemlandschaft behandelt der Leitfaden zum IT Lifecycle Management.
Vier Leistungen bestimmen, ob ein Supportzeitraum trägt. Ihre Reihenfolge ist keine Wertung, sondern beschreibt, was zuerst wegfällt.
- Sicherheitsupdates für neu bekannt gewordene Schwachstellen
- Fehlerbehebungen für Störungen im laufenden Betrieb
- Kompatibilitätsanpassungen an neue Umgebungen und Schnittstellen
- Technische Unterstützung bei Störungen und Rückfragen
End of Support, End of Life und End of Sale
Drei Begriffe markieren unterschiedliche Punkte. End of Sale beendet den Verkauf, das Produkt bleibt im Support. End of Support beendet Updates und Unterstützung. End of Life bezeichnet das Ende des Lebenszyklus insgesamt. Verbreitet ist zusätzlich End of Service, das je nach Hersteller mit dem End of Support zusammenfällt. Für die Planung zählt allein das Ende des Herstellersupports, weil ab diesem Tag das Risiko steigt.
In der öffentlichen Verwaltung verschärft die Bindung an Haushaltsjahre die Lage. Ein Enddatum im März nützt wenig, wenn die Mittel erst im folgenden Haushalt bereitstehen. Bei Softwareprojekten für die öffentliche Hand muss der Ablösestichtag deshalb auf einen Haushaltszyklus fallen, nicht auf ein technisches Datum.
Woraus sich der Supporthorizont ergibt
Den Supportzeitraum planen lässt sich nur, wenn beide Hälften der Rechnung vorliegen. Die zugesicherte Vertragslaufzeit ist die eine. Die andere steckt in den Bestandteilen, aus denen die Anwendung gebaut ist. Jede Sprachversion, jedes Framework, jede Datenbank und jedes Betriebssystem trägt ein eigenes Enddatum.
Der Supportzeitraum für Individualsoftware
Bei Standardprodukten verkündet der Hersteller ein Datum. Der Supportzeitraum für Individualsoftware hat diesen Hersteller nicht, und genau das führt regelmäßig zu einer Fehleinschätzung. Individualsoftware veraltet nicht als Ganzes, sondern über ihre Bausteine. Der faktische Supporthorizont entspricht deshalb dem frühesten Enddatum unter allen eingesetzten Fremdkomponenten, nicht der Laufzeit des Pflegevertrags. Ob eine neu vorgesehene Komponente im eigenen Umfeld überhaupt trägt, zeigt vor der Beauftragung ein Proof of Concept.
Ein Beispiel macht das greifbar. Eine Fachanwendung mit Pflegevertrag über fünf Jahre läuft auf einer Sprachversion, deren Sicherheitsupdates in zwei Jahren enden. Der reale Supportzeitraum beträgt damit zwei Jahre. Welche Bestandteile überhaupt im Einsatz sind, klärt ein gepflegtes Software Asset Management.
Wie lassen sich Support-Enddaten überwachen?
Enddaten ändern sich. Hersteller verlängern Fristen, verkürzen sie oder ziehen Produkte früher zurück. Eine einmalige Erhebung veraltet deshalb schnell. Nötig ist ein Register, das mit jedem Release aktualisiert wird und dessen Pflege einer benannten Rolle zugeordnet ist, intern oder im Rahmen der laufenden Betreuung der Anwendung. Öffentliche Datenbanken zu Supportfristen und die Lifecycle-Seiten der Hersteller liefern die Rohdaten dafür. Übertragen werden müssen sie in den eigenen Bestand, weil erst die Zuordnung zur konkreten Anwendung zeigt, welches Datum überhaupt Wirkung entfaltet.
Was in ein Komponenten-Register gehört
Ein solches Register bleibt schlank. Es ersetzt keine Konfigurationsdatenbank, sondern nennt nur das Enddatum je Baustein.
- Bezeichnung und eingesetzte Version der Komponente
- Veröffentlichtes Datum für das End of Support
- Quelle des Datums und Zeitpunkt der letzten Prüfung
- Betroffene Anwendungen und deren Kritikalität
- Verantwortliche Rolle für die Nachverfolgung
Für Kommunen und Behörden kommt die Kostenseite hinzu, weil jede Verlängerung und jede Ablösung im Haushalt abgebildet werden muss. Wie sich Zeitachse und Kosten dort zusammenführen lassen, zeigt der Beitrag zum Lebenszyklusmanagement in Behörden.
Supportzeitraum planen und vertraglich sichern
Den Supportzeitraum zu planen genügt nicht, solange das Ergebnis nirgends geschrieben steht. Verbindlich wird er erst durch die Leistungsbeschreibung. Regulatorisch ist das Thema in Bewegung. Der Cyber Resilience Act der EU verpflichtet Hersteller von Produkten mit digitalen Elementen dazu, einen Unterstützungszeitraum festzulegen und anzugeben. Die Verordnung ist ab dem 11. Dezember 2027 in vollem Umfang anwendbar.
Supportzeitraum für Individualsoftware ausschreiben
In der Ausschreibung entscheidet sich, ob der Supportzeitraum später belastbar ist. Drei Angaben gehören dafür in die Leistungsbeschreibung. Erstens die Mindestdauer, für die Sicherheitsupdates zugesichert werden. Zweitens die Pflicht, Fremdkomponenten vor ihrem eigenen Support-Ende auf eine unterstützte Version zu heben. Drittens eine Informationspflicht, sobald ein Bestandteil abgekündigt wird.
Ohne die zweite Zusicherung bleibt die erste wertlos. Ein Anbieter kann fünf Jahre Support versprechen und die Anwendung dennoch auf einer Version stehen lassen, die vorher aus dem Support fällt. Die Kostenwirkung solcher Zusicherungen zeigt sich erst über die gesamte Nutzungsdauer, nicht im Angebotspreis.
Rückwärtsplanung bis zum Ablösestichtag
Die Planung läuft gegen die Zeitrichtung. Ausgangspunkt ist das früheste Support-Enddatum, von dort wird zurückgerechnet: Migration, Test, Beschaffung, Vergabeverfahren, Bedarfsermittlung. Der Startzeitpunkt ist ein Ergebnis dieser Rechnung, keine freie Entscheidung. Bei einem europaweiten Vergabeverfahren liegt er erfahrungsgemäß mehrere Haushaltsjahre vor dem Enddatum.
Woran die Rückwärtsplanung oft scheitert
Die Rechnung selbst ist einfach. Ihre Annahmen sind es nicht, und an genau diesen Annahmen bricht der Fahrplan.
❗ Das Support-Enddatum wird verschoben und der Fahrplan nicht nachgezogen
❗ Die Vergabedauer wird zu knapp angesetzt
❗ Der Parallelbetrieb beider Systeme ist nicht eingeplant
❗ Abhängige Fachverfahren tauchen erst im Test auf
❗ Die Mittel stehen im falschen Haushaltsjahr bereit
Wenn das End of Support näher rückt
Bleiben weniger als zwölf Monate, verengt sich alles auf zwei Wege. Entweder wird der Support gegen Aufpreis verlängert, oder die Ablösung wird beschleunigt. Beide Wege kosten mehr, als den Supportzeitraum rechtzeitig zu planen, und beide brauchen eine Entscheidung mit Namen darunter. Ein dritter Weg, das System ohne Updates weiterzubetreiben, ist in regulierten Bereichen keine Option und sonst eine Wette auf ausbleibende Angriffe.
Was verlängerter Support wirklich kostet
Verlängerte Supportprogramme, je nach Anbieter als Extended Support oder als erweiterte Sicherheitsupdates geführt, sind bewusst als Übergang gebaut und nicht als Dauerlösung. Ihre Preisgestaltung folgt darum meist demselben Muster.
- Abrechnung je Gerät oder je Instanz statt pauschal
- Jährlich steigende Gebühren über die Laufzeit
- Zeitliche Begrenzung auf wenige Jahre
- Beschränkung auf kritische Sicherheitsupdates ohne neue Funktionen
Die Verlängerung kauft Zeit, sie löst kein Problem. Sinnvoll ist sie, wenn die Ablösung bereits beauftragt ist und nur der Termin nicht hält. Wird sie ohne laufendes Ablöseprojekt gebucht, verschiebt sie dieselbe Entscheidung in ein teureres Jahr.
Wer das auslaufende Supportende verantwortet
Ein Supportzeitraum endet selten überraschend, aber oft ohne Zuständigen. Der Betrieb meldet das Datum, die Fachabteilung kennt den Bedarf, die Beschaffung braucht Vorlauf, und die Entscheidung fällt zwischen diese Stellen. Wirksam ist die Zuordnung erst dann, wenn eine benannte Rolle die Frist verantwortet und ihre Verlängerung begründen muss.
TenMedia entwickelt und betreibt Individualsoftware für Behörden, KRITIS-Betreiber und den Mittelstand und hält die eingesetzten Fremdkomponenten auf unterstützten Ständen. Für die Berliner Feuerwehr entstand ein Notfallhandbuch zur koordinierten Gefahrenabwehr. Welche Fristen dabei gelten, hängt vom zugesicherten Zeitraum ab und wird vor der Beauftragung festgelegt, nicht erst im Betrieb.