Bildquelle: extern
Ein alter IT-Dienst verschwindet selten von selbst. Er bleibt in Kostenstellen, Monitoringlisten, Berechtigungen, Supportnotizen und Verträgen stehen, auch wenn kaum noch jemand über seinen Nutzen spricht. Genau dort entsteht das Problem: Solange niemand das Ende verantwortet, trägt der Betrieb die Altlast weiter. Abschalten wird dann nicht zur geplanten Portfolioentscheidung, sondern zur riskanten Suche nach dem letzten unbekannten Nutzer.
Ein IT-Dienst ist hier mehr als eine Anwendung oder ein Server. Gemeint ist die Leistung, die für Fachbereiche oder interne Nutzer bereitsteht, zum Beispiel ein Berichtssystem, eine Schnittstelle, ein Portal, ein Datenexport oder ein altes Supportverfahren. Für ITSM-Generalisten ist das Ende eines Dienstes keine reine Technikfrage. Es betrifft Kosten, Zuständigkeiten, Supportversprechen, Datenaufbewahrung, Sicherheitsrisiken und die Frage, wer eine saubere Ablösung bestätigt.
Unsichtbare Nutzung ist kein Freibrief zum Abschalten
Der erste Fehler beginnt oft mit der Formulierung: Das System wird nicht mehr genutzt. Diese Aussage klingt entlastend, ist aber selten belastbar genug. Ein Dienst kann im Alltag unsichtbar geworden sein und trotzdem einmal im Monat einen Bericht liefern, eine Schnittstelle bedienen oder in einem Notfallprozess als Referenz stehen. Wer abschalten will, braucht deshalb eine klare Nutzungsspur. Dazu gehören Login- und Abrufdaten, bekannte Abhängigkeiten, Schnittstellen, Service-Desk-Tickets, Fachbereichsrückfragen und die Frage, ob es bereits einen Nachfolgedienst gibt.
Genauso wichtig ist die Eigentümerfrage. Ein Service Owner kann entscheiden, ob ein Dienst fachlich noch gebraucht wird. Der technische Owner kann bewerten, wie Abschaltung, Archivierung und Rückbau funktionieren. Der Einkauf oder das Providermanagement sieht Laufzeiten, Kündigungsfristen und externe Abhängigkeiten. Datenschutz und Sicherheit prüfen Daten, Aufbewahrung, Rechte und alte Zugänge. Fehlt eine dieser Rollen, wird der Rückbau zur grauen Zone. Dann sagt jeder, dass der Dienst alt ist, aber niemand setzt den letzten Schritt auf die Tagesordnung.
Ohne Owner bleibt der Rückbau in der Grauzone
Alte Dienste kosten nicht nur Lizenz- oder Cloudgeld. Sie binden Aufmerksamkeit. Monitoring muss gepflegt werden, Backups laufen weiter, Sicherheitsupdates werden diskutiert, Zugänge bleiben offen, Dokumentation muss erklärt werden. Noch gefährlicher ist der Vertrauenseffekt: Wenn ein Dienst offiziell im Portfolio steht, erwarten Nutzer im Zweifel Unterstützung. Der Service Desk gerät dann in die Lage, ein System erklären zu müssen, das fachlich längst keiner mehr verteidigt.
Ein guter Retirement-Prozess beginnt daher nicht mit dem Abschalttermin, sondern mit einem kleinen Dossier. Darin steht, was der Dienst leistet, wer ihn zuletzt genutzt hat, welche Daten enthalten sind, welche Schnittstellen bestehen, welcher Ersatz vorgesehen ist und welche Risiken beim Abschalten bleiben. Dieses Dossier muss nicht bürokratisch sein. Es muss aber reichen, damit Führung, Fachbereich und Betrieb dieselbe Entscheidung sehen: weiter betreiben, ersetzen, einfrieren oder geordnet beenden.
Ein kleines Dossier macht die Entscheidung belastbar
Kommunikation entscheidet dabei über Akzeptanz. Nutzer brauchen keine technische Migrationsgeschichte, sondern eine klare Ansage: Was endet, warum endet es, welcher Ersatz gilt, bis wann müssen sie reagieren und an wen wenden sie sich bei begründeten Einwänden? Eine stille Abschaltung wirkt effizient, bis der erste Fachbereich einen vergessenen Monatslauf vermisst. Eine offene Ankündigung mit Einspruchsfrist macht den Rückbau langsamer, aber belastbarer.
Auch nach dem Abschalten ist der Dienst nicht sofort erledigt. Alte Berechtigungen müssen entfernt, Schnittstellen deaktiviert, Monitoring und Backupregeln bereinigt, Dokumentation angepasst und Kostenstellen geschlossen werden. Daten brauchen eine Entscheidung zwischen Löschung, Archivierung und rechtlicher Aufbewahrung. Erst wenn diese Punkte erledigt sind, ist aus dem technischen Stopp eine echte Portfolio-Bereinigung geworden.
Nach dem Abschalten beginnt die eigentliche Bereinigung
Für das IT-Management ist die wichtigste Kennzahl deshalb nicht nur, wie viele neue Dienste bereitgestellt wurden. Entscheidend ist auch, welche Dienste bewusst beendet wurden und mit welchem Nachweis. Ein Portfolio, das nur wächst, wird irgendwann unübersichtlich, teuer und schwer sicher zu halten. Ein Portfolio, das auch Enden sauber führt, zeigt dagegen Reife: Nutzen wird geprüft, Verantwortung wird sichtbar, und der Betrieb muss alte Entscheidungen nicht dauerhaft mittragen.
Das Ende eines alten IT-Dienstes gehört daher in eine feste Governance-Routine. Nicht jede Anwendung braucht ein großes Projekt. Aber jeder Dienst braucht jemanden, der die letzte Frage beantwortet: Bleibt dieser Dienst aus einem guten Grund aktiv, oder halten wir ihn nur noch am Leben, weil niemand den Rückbau besitzt?
Quellen und Stand
- IBM Think, Application portfolio management, abgerufen am 10.07.2026: Application portfolio management
- Atlassian, IT Asset Management, abgerufen am 10.07.2026: IT Asset Management
- IBM Think, IT asset management, abgerufen am 10.07.2026: IT asset management
- AWS Prescriptive Guidance, Application portfolio assessment guide, abgerufen am 10.07.2026: Application portfolio assessment guide
