Supportenden im IT-Portfolio brauchen ein Radar statt Einzellösungen

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 Kollaborationsplattform bekommt ein End-of-Life-Datum, und jedes Team startet sein eigenes Projekt. Genau dieses Muster wird teuer, weil sich heute mehrere Fristen gleichzeitig überlagern: quer durch Workplace, Infrastruktur, Fachanwendungen und Serviceplattformen.

Die Ausgangslage ist nicht theoretisch. Microsoft hat für Windows 10 Home und Pro den 14. Oktober 2025 als Supportende gesetzt. SAP nennt für die Kernanwendungen der Business Suite 7 Mainstream Maintenance bis Ende 2027 und optional Extended Maintenance bis Ende 2030. Atlassian hat 2026 den Übergang seiner Data-Center-Produkte in Richtung Cloud mit klaren Fristen beschrieben, inklusive End-of-Life am 28. März 2029. Gleichzeitig bewertet CISA unsupported oder end-of-life Software ausdrücklich als gefährliche Praxis und fordert in ihrer aktuellen Richtlinie zu End-of-Support-Edge-Geräten belastbare Lifecycle-Planung, Migration und zügige Ablösung.

Für IT-Management heißt das: Supportenden sind kein Randthema für Admin-Teams mehr. Sie sind ein Steuerungsthema für Portfolio, Budget, Risiko, Servicequalität und Kommunikation. Wer sie weiter produktweise nebenher behandelt, reagiert fast zwangsläufig zu spät.

Ein Radar schafft aus Herstellerterminen ein Managementbild

Der wichtigste Schritt ist eine zentrale Sicht auf auslaufende Produkte und Plattformen. Viele Häuser haben zwar 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 Felder: Produkt und Version, offizielles Supportende, mögliche Übergangsmodelle wie ESU oder Extended Maintenance, technischer Owner, kaufmännischer Owner, betroffene Services, regulatorische Relevanz und grober Migrationspfad. Wichtig ist dabei die Breite. In dieses Radar gehören nicht nur Server und Clients, sondern auch Identity-nahe Systeme, Edge-Geräte, Middleware, Kollaborationsplattformen, Netzkomponenten 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 erst spät merken, dass mehrere Herstellerentscheidungen gleichzeitig Investitionen, Projektteams und Change-Fenster binden.

Priorisierung muss Geschäftsrelevanz und Betriebsabhängigkeit verbinden

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 geführt werden.

Sinnvoll ist eine Priorisierung entlang von vier Fragen: Welche Geschäftsprozesse hängen daran? Wie tief ist die technische Einbettung in andere Kernsysteme? Wie hoch ist das Sicherheits- und Compliance-Risiko nach dem Supportende? Und wie aufwendig ist ein realistischer Migrationspfad? Bei Windows 10 ist das Problem nicht nur ein fehlendes Update, sondern der Verlust einer normalen Supportbasis im Endpoint-Betrieb. Bei SAP Business Suite 7 geht es zusätzlich um langlaufende Transformationspfade, Wartungskosten und die Verzahnung mit Fachbereichen. Bei Atlassian Data Center ist relevant, ob das System nur Teamorganisation unterstützt oder tief in Entwicklungs-, Freigabe- und ITSM-Abläufe 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.

Extended Support ist eine Brücke, kein 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 für Windows 10 klar, dass Extended Security Updates nur eine befristete Übergangsoption sind. SAP verknüpft verlängerte Wartung für Business Suite 7 mit einem Aufpreis und längeren Konversionsphasen. Auch Atlassian beschreibt für Sonderfälle nur eine Ausnahme-Logik nach dem Data-Center-Ende, nicht den Fortbestand als reguläres Zielmodell. Die eigentliche Botschaft aller drei Beispiele ist dieselbe: Wer Übergänge nutzt, braucht einen glaubwürdigen Exit-Pfad.

Praktisch sollte jede Ausnahme in ein zentrales Register mit festen Pflichtfeldern: benannter Owner, geschäftlicher Grund, Kostenaufschlag, Enddatum, Kompensationsmaßnahmen 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.

Budget und Umsetzungskapazität müssen vor der Frist gesichert sein

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 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 robustes Muster ist dreistufig: früh Zielbild und Größenordnung festlegen, dann Abhängigkeiten und Migrationspfad schärfen, anschließend Umsetzungsfenster mit Fachbereichen, Security und Betrieb verbindlich blocken.

Gerade bei ERP, ITSM-Suiten, Edge-Infrastruktur oder selbst betriebenen Kollaborationssystemen ist das entscheidend. Dort geht es nicht nur um Softwaretausch, sondern um Schnittstellen, Rollenmodelle, Berechtigungen, Betriebsprozesse und Datenbestände. Ohne rechtzeitige Ressourcensteuerung wird aus einer planbaren Modernisierung schnell eine hektische Notfallmigration.

Governance und Betriebskommunikation entscheiden über die letzte Meile

Am Ende entscheidet nicht die Liste im PMO, sondern die Führungsroutine. Supportenden gehören 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? Welche Nutzer- oder Fachbereichskommunikation muss vorbereitet werden? CISA macht bei unsupported Systemen deutlich, dass gerade internetnahe und 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 kein Nebengeräusch 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 Übergangsmodellen, früh reservierte Migrationsmittel und eine feste Governance-Routine machen aus Herstellerdeadlines ein steuerbares Managementthema.

Genau darin liegt der Unterschied zwischen bloßem Nachziehen und vorausschauender IT-Steuerung. Die Hersteller liefern das Datum. Ob daraus hektische Sonderprojekte oder ein sauber geführtes Portfolio-Thema wird, entscheidet die Organisation selbst.

Quellen

• Microsoft Learn: Windows 10 Home and Pro Lifecycle
• Microsoft: End of support for Windows 10
• SAP: Maintenance 2040 / SAP Business Suite 7
• Atlassian: Ascend to the cloud – The next chapter for Atlassian and our customers
• CISA: Bad Practices
• CISA: BOD 26-02 – Mitigating Risk From End-of-Support Edge Devices