Bildquelle: extern
Supportenden im IT-Portfolio: Welche 5 Steuerungsroutinen IT-Management 2026 zentral aufsetzen sollte
Viele IT-Organisationen behandeln Supportenden noch immer wie isolierte Herstellertermine. Ein Client-Betriebssystem läuft aus, ein ERP-System geht in die verlängerte Wartung, eine Self-Managed-Plattform bekommt ein End-of-Life-Datum, und jedes Team startet sein eigenes Projekt. Genau dieses Muster wird 2026 teuer. Denn in der Praxis überlagern sich inzwischen mehrere Fristen gleichzeitig, oft quer durch Workplace, Infrastruktur, Fachanwendungen und Serviceplattformen.
Die Ausgangslage ist alles andere als theoretisch. Microsoft hat das reguläre Supportende für Windows 10 auf den 14. Oktober 2025 festgelegt und bietet Extended Security Updates nur als befristete Übergangsoption an. SAP nennt für SAP Business Suite 7 das Ende der Mainstream Maintenance Ende 2027, mit optionaler Extended Maintenance bis Ende 2030. Atlassian hat angekündigt, dass Data-Center-Produkte am 28. März 2029 ihr End of Life erreichen. Gleichzeitig bewertet CISA den Einsatz von Unsupported- oder End-of-Life-Software ausdrücklich als gefährliche Praxis und fordert 2026 in ihrer Richtlinie zu End-of-Support-Edge-Devices belastbare Lifecycle-Planung, Migrationsvorbereitung und zügige Ablösung.
Für IT-Management heißt das: Supportenden sind kein Randthema für Admin-Teams, sondern ein Steuerungsthema für Portfolio, Budget, Risiko und Servicequalität. Fünf Routinen sollten deshalb verbindlich werden.
1. Ein zentrales End-of-Support-Radar aufbauen, nicht nur verstreute Herstellerlisten pflegen
Der wichtigste Schritt ist eine zentrale Sicht auf auslaufende Produkte und Plattformen. Viele Häuser haben zwar irgendwo Lifecycle-Tabellen, Vertragsordner oder Herstellernewsletter, aber keinen zusammenhängenden Steuerungsblick. Das rächt sich, sobald mehrere Fristen parallel laufen oder Abhängigkeiten zwischen Systemen sichtbar werden.
Ein belastbares Radar braucht pro relevanter Komponente mindestens diese Informationen: Produkt und Version, offizielles Supportende, mögliche Übergangsmodelle wie ESU oder Extended Maintenance, technischer Owner, kaufmännischer Owner, betroffene Services und grober Migrationspfad. Wichtig ist dabei die Breite. In das Radar gehören nicht nur Server und Clients, sondern auch Kollaborationsplattformen, Identity-nahe Systeme, Fachanwendungen, Edge-Geräte, Middleware und Betriebswerkzeuge.
Erst mit dieser Sicht wird erkennbar, ob das Haus in zwölf bis 36 Monaten auf eine einzelne Deadline zuläuft oder auf eine ganze Welle. Genau diese Transparenz fehlt oft, wenn Vorstände oder Bereichsleitungen zu spät merken, dass mehrere Herstellerentscheidungen gleichzeitig Investitionen, Projektteams und Change-Fenster binden.
2. Supportenden nach Geschäftsrelevanz und Betriebsabhängigkeit priorisieren
Nicht jedes Supportende hat dasselbe Gewicht. Ein auslaufendes Nischentool im Backoffice ist etwas anderes als ein nicht mehr unterstützter Client-Standard, ein ERP-Kernsystem oder eine Plattform, auf der Service-, Entwicklungs- oder Wissensprozesse hängen. Deshalb sollte das Radar nie als bloße Terminliste betrieben werden.
Sinnvoll ist eine Priorisierung entlang von drei Fragen: Welche Geschäftsprozesse hängen daran, wie stark ist die technische Einbettung in andere Kernsysteme, und wie problematisch wird der Betrieb nach dem Supportende wirklich? Bei Windows 10 ist das Risiko nicht nur ein fehlendes Update, sondern auch der Verlust einer normalen Supportbasis. Bei SAP Business Suite 7 geht es zusätzlich um langlaufende Transformationspfade, Lizenz- und Wartungskosten sowie die Verzahnung mit Fachbereichen. Bei Atlassian Data Center ist relevant, ob das System nur ein Teamtool ist oder tief in Entwicklungs-, Freigabe- und Serviceprozesse eingebunden bleibt.
Für das IT-Management ist diese Priorisierung entscheidend, weil sie Investitionslogik schafft. Statt alles gleichzeitig anzufassen, lassen sich jene Produkte zuerst behandeln, bei denen Betriebsrisiko, Abhängigkeitsdichte und Migrationsaufwand zusammen besonders hoch sind.
3. Extended Support nur als Brücke führen, niemals als stilles Zielbild
Ein häufiger Managementfehler ist die psychologische Entlastung durch verlängerte Supportmodelle. Sobald ein Hersteller ESU, Extended Maintenance oder ähnliche Übergänge anbietet, sinkt intern oft der Druck. Das ist verständlich, aber riskant. Denn solche Modelle kaufen vor allem Zeit, nicht Zukunftsfähigkeit.
Microsoft formuliert das bei Windows 10 klar: Extended Security Updates halten Geräte befristet mit wichtigen Sicherheitsupdates am Leben, ersetzen aber keinen normalen Lebenszyklus. SAP verlangt für verlängerte Wartung zusätzliche Kosten. Und auch dort ist die eigentliche Botschaft nicht, dass man sich entspannt zurücklehnen kann, sondern dass Transformationspfade sauber geplant werden müssen.
Praktisch sollte jede Ausnahme in ein zentrales Register mit fünf Pflichtfeldern: benannter Owner, geschäftlicher Grund, Kostenaufschlag, Enddatum und dokumentierter Exit-Pfad. Fehlt eines dieser Elemente, ist es keine Übergangssteuerung, sondern das Fortschreiben technischer Schulden. Gerade im IT-Management lohnt sich hier Härte, weil verlängerte Wartung sonst von Quartal zu Quartal als bequemste Option durchrutscht.
4. Migrationsbudget und Umsetzungsressourcen deutlich vor der Frist reservieren
Supportenden scheitern selten am fehlenden Problembewusstsein. Sie scheitern an konkurrierenden Prioritäten, zu spät gesichertem Budget und an überbuchten Teams. Wer erst zwölf Monate vor dem Stichtag ernsthaft mit Planung beginnt, ist bei komplexeren Plattformen oft schon zu spät dran. Das gilt besonders, wenn nicht nur ein technisches Upgrade, sondern Architekturentscheidungen, Datenmigration, Vertragswechsel, Testzyklen oder Schulungen dazugehören.
Deshalb sollte das End-of-Support-Radar direkt an Budget- und Portfoliosteuerung gekoppelt sein. Große Fristen brauchen reservierte Mittel, grobe Zielarchitekturen und klar benannte Programmverantwortung lange bevor das Thema im Betrieb schmerzt. Ein gutes Muster ist eine dreistufige Planung: frühzeitig Zielbild und Größenordnung festlegen, anschließend Migrationspfad und Abhängigkeiten schärfen, dann Umsetzungsfenster mit Fachbereichen und Betrieb verbindlich blocken.
Gerade bei Plattformen wie ERP, ITSM-Suiten oder selbst betriebenen Kollaborationssystemen ist das wichtig. Dort geht es nicht nur um Softwaretausch, sondern oft um Schnittstellen, Rollenmodelle, Betriebsprozesse und Datenbestände. Ohne rechtzeitige Ressourcensteuerung wird aus einer planbaren Modernisierung schnell eine hektische Notfallmigration.
5. Ausnahmen, Risiken und Kommunikation in eine feste Governance-Routine ziehen
Am Ende entscheidet nicht die Liste im PMO, sondern die Führungsroutine. Supportenden gehören 2026 in ein festes Governance-Format, idealerweise monatlich oder mindestens quartalsweise. Dort sollten IT-Leitung, Architektur, Informationssicherheit, Service Management, Einkauf und betroffene Produktverantwortliche gemeinsam auf die Lage schauen.
In dieses Gremium gehören keine PowerPoint-Sammlungen, sondern konkrete Entscheidungen: Welche Produkte gehen in ein Migrationsprogramm, welche bleiben befristet in der Ausnahme, welche Kompensationsmaßnahmen gelten für nicht ablösbare Altstände, und welche Nutzer- oder Fachbereichskommunikation muss vorbereitet werden? Gerade CISA macht deutlich, dass unsupported Systeme, insbesondere internetnahe oder stark integrierte Komponenten, ein unverhältnismäßiges Risiko erzeugen können. Dieser Punkt muss sich in der Governance spiegeln.
Ebenso wichtig ist die Kommunikation in den Betrieb. Service Desk, Field Support und Application Owner müssen wissen, welche Aussagen gegenüber Fachbereichen gelten, welche Eskalationswege existieren und ab wann ein Altprodukt nicht mehr als normaler Standard behandelt wird. Sonst bleiben Managemententscheidungen formal korrekt, landen aber nie sauber im Tagesgeschäft.
Fazit
Supportenden im IT-Portfolio sind 2026 keine Einzelfälle mehr, sondern ein wiederkehrendes Steuerungsmuster. Wer Fristen nur produktweise verfolgt, reagiert zu spät und verteilt Risiken unsichtbar über das gesamte Portfolio. Ein zentrales End-of-Support-Radar, harte Priorisierung, disziplinierter Umgang mit Extended Support, früh reservierte Migrationsmittel und eine feste Governance-Routine machen aus Herstellerdeadlines ein steuerbares Managementthema. Genau das trennt bloßes Nachziehen von vorausschauender IT-Steuerung.
