Technische Schuld in der IT-Infrastruktur: Was sie wirklich kostet

Der Begriff "technische Schuld" kommt aus der Software-Entwicklung. Ward Cunningham hat das Bild 1992 eingeführt, als er erklären wollte, warum sein Team langsamer wurde: Wer schnell eine Lösung zusammensteckt, nimmt einen Kredit auf. Der Kredit ist in Ordnung, solange man ihn bald zurückzahlt. Zahlt man nicht zurück, wachsen die Zinsen. Irgendwann arbeitet das Team nur noch an den Zinsen.

Das Konzept funktioniert in der IT-Infrastruktur genauso, mit einem Unterschied in der Sichtbarkeit. Software-Schuld liegt wenigstens im Code, lesbar für jeden, der hinschaut. Ob sie irgendwo systematisch erfasst wird (in einem Issue-Tracker, einem Technical-Debt-Register, einem Backlog), hängt von der Disziplin des Teams ab, und ehrlich gesagt fehlt die auch in vielen Software-Projekten. In der Infrastruktur wird es noch dünner. Da ist die Schuld über zig Systeme, Räume und Köpfe verteilt und niemand merkt etwas, bis etwas kippt.

In unserer Praxis bei RockLogic sehen wir das laufend. Ein Kunde ruft an, weil der Fileserver langsam wird. Beim Hinschauen stellt sich heraus, dass das System seit fünf Jahren auf einem Hyper-V-Host läuft, der schon drei Upgrades überfällig ist, auf einer Storage, deren Controller-Firmware aus 2019 ist, in einem VLAN, das nie sauber segmentiert wurde, mit einem Backup, das seit zwei Jahren nicht mehr getestet wurde. Das Symptom ist Langsamkeit. Die Krankheit ist aufgeschobene Arbeit aus einer Dekade.

Warum Infrastruktur-Schuld anders ist als Software-Schuld

Software-Schuld hat wenigstens einen physischen Ort, das Repository. Auch wenn niemand sie sauber im Ticket-System dokumentiert, ein grep TODO oder ein git log zeigt die Narben. Infrastruktur-Schuld lebt dagegen in Rack-Schränken, Konfigurationsdateien auf 15 verschiedenen Systemen, handschriftlichen Notizen im Serverraum und im Kopf eines Mitarbeiters, der letztes Jahr in Pension gegangen ist.

Drei Eigenschaften machen Infrastruktur-Schuld besonders gefährlich:

Sie ist unsichtbar, solange sie funktioniert. Ein Switch, der seit acht Jahren läuft, ist erst ein Problem, wenn er nicht mehr läuft. Dann ist er auch keine technische Schuld mehr, sondern ein Ausfall.

Sie kaskadiert. In Software ist schlechter Code in einem Modul unangenehm. In der Infrastruktur bringt eine falsche Firewall-Regel den gesamten Mailverkehr zum Erliegen. Ein nicht gepatchter Domain Controller wird zum Einfallstor für Ransomware im ganzen Netz.

Sie altert nicht linear. Ein Server, der drei Jahre alt ist, kostet wenig Wartung. Einer, der acht Jahre alt ist, hat keine Ersatzteile mehr, keine Firmware-Updates, kein Support-Ticket-Recht beim Hersteller. Die Kostenkurve steigt irgendwann steil an.

Die sechs häufigsten Formen

Hardware-Schuld

Geräte, die am End-of-Life vorbei sind. Server, deren Garantie abgelaufen ist und die niemand mehr ersetzen darf, weil die Budgetrunde vor drei Jahren das falsche Thema ausgemacht hat. USV-Anlagen mit Batterien, die längst unter der nutzbaren Kapazität sind. Firewalls, die der Hersteller seit zwei Jahren nicht mehr mit Sicherheits-Updates versorgt. Warum genau das kein Randthema ist, haben wir in Firmware-Update vergessen? Angreifer nicht. behandelt.

Software- und OS-Schuld

Windows Server 2012 R2 läuft seit Oktober 2023 ohne Security-Updates, wenn man ESU nicht bezahlt. Exchange on-premises, das zuletzt 2022 einen CU bekommen hat (zur Mail-Client-Seite derselben Geschichte haben wir einen Vergleich von Outlook Classic, Outlook New und eM Client geschrieben). VMware ESXi 6.x in einer Umgebung, in der Broadcom gerade die Lizenzbedingungen neu erfunden hat. Wie eine saubere Ablöse im Virtualisierungsbereich aussieht, zeigt unser Artikel VMware war gestern. Was tun, wenn die Rechnung kommt? und die Übersicht zum Thema Virtualisierung.

Architektur-Schuld

Flache Netze ohne VLAN-Segmentierung, in denen der Drucker auf demselben Broadcast-Segment hängt wie der Domain Controller. Dienste, die auf einem alten Desktop-PC unter dem Schreibtisch der Buchhaltung laufen, weil es "damals schnell gehen musste". Eine Datenbank, die seit Jahren von drei Applikationen parallel benutzt wird, obwohl sie dafür nie entworfen wurde. Wer gerade über Neubau oder Ablöse nachdenkt, findet in Cloud oder eigene Hardware eine Einordnung, die bei der Architekturfrage hilft. Mehr dazu auch unter Netzwerk-Infrastruktur.

Dokumentations-Schuld

Netzpläne, die zuletzt jemand 2018 angefasst hat. Credentials in einer Excel-Datei auf einer Freigabe. IP-Adressen auf Post-its neben dem Monitor. Ein Mitarbeiter kündigt und nimmt das gesamte Wissen über die Firewall-Regeln mit.

Prozess-Schuld

Backups, die automatisch laufen, aber nie durch eine Wiederherstellung geprüft wurden. Kein Monitoring oder Monitoring, das so viele False Positives produziert, dass niemand mehr hinschaut. Keine Change-Protokolle. Kein Patch-Management, sondern gelegentliche Reboot-Abende.

Sicherheits-Schuld

Default-Credentials, die nie geändert wurden. MFA, das für interne Dienste "später kommt". Firewall-Regeln, die jemand vor Jahren "temporär" auf any-any gestellt hat, weil gerade etwas dringend war. Berechtigungen, die mit jedem Rollenwechsel wachsen und nie entzogen werden.

Die Zinsen

Die offensichtliche Rechnung ist einfach. Eine Firewall, die vor drei Jahren hätte ausgetauscht werden sollen, kostet heute dasselbe im Einkauf. Also kein Schaden, oder?

Die weniger offensichtliche Rechnung sieht anders aus.

Ausfallkosten. Wenn der acht Jahre alte Storage-Controller stirbt, sind die Ersatzteile nicht mehr lagernd. Der Hersteller braucht drei bis fünf Werktage, im besten Fall. In dieser Zeit steht die Produktion. Bei einem KMU mit 80 Mitarbeitern liegt der Tagesausfall schnell im fünfstelligen Bereich.

Sicherheitsvorfälle. Die meisten Ransomware-Fälle, die wir zu sehen bekommen, hängen nicht an raffinierten Zero-Days. Sie hängen an nicht gepatchten Systemen, flachen Netzen und schwachen Admin-Passwörtern, also an abgearbeiteter Hausaufgabenliste, die jahrelang ignoriert wurde.

Compliance-Druck. Ab 1. Oktober 2026 gilt in Österreich das NISG 2026, also die nationale Umsetzung der NIS2-Richtlinie. Rund 4.000 Unternehmen fallen darunter. Die Anforderungen (Asset-Management, Risikobehandlung, Incident-Handling, Patch- und Schwachstellenmanagement) sind für Unternehmen, die ihre technische Schuld im Griff haben, Routine. Für alle anderen werden es anstrengende Monate. Wir haben das Gesetz und seine Auswirkungen auf KMUs in NIS2 in Österreich: Was das NISG 2026 für KMUs bedeutet im Detail beschrieben, und einen Überblick zu Rahmenwerken gibt es auf unserer Seite zu Konformität und Zertifizierungen.

Opportunitätskosten. Das sind die Kosten, die man auf keiner Rechnung findet und die oft am höchsten sind. Ein IT-Team, das 70 Prozent seiner Zeit damit verbringt, alte Systeme am Leben zu halten, hat keine 70 Prozent mehr für das, wofür es eigentlich angestellt ist.

Warum Unternehmen trotzdem nicht aufräumen

Das klingt alles nach gesundem Menschenverstand. Trotzdem erleben wir immer wieder, dass Kunden Infrastruktur-Schuld bewusst in Kauf nehmen. Die Gründe sind erkennbar.

"Läuft ja noch" ist die häufigste Antwort. Ein Server, der seit zehn Jahren ohne Ausfall läuft, wirkt wie eine Erfolgsgeschichte. Statistisch ist er ein tickendes Risiko.

Die Buchhaltung hilft nicht. CapEx für neue Hardware fällt sofort ins Auge, OpEx für Wartungsverträge ebenfalls. Die Kosten aufgeschobener Erneuerung stehen auf keiner Position. Wer quartalsweise Ergebnisse reportet, hat wenig Anreiz, vor einer Board-Sitzung einen sechsstelligen Infrastruktur-Posten zu rechtfertigen.

Und ehrlich gesagt: Solange nichts passiert, fühlt sich jeder gut dabei. Das Problem ist nur, dass Infrastrukturen nicht gefühlt ausfallen, sondern messbar.

Wie man aus der Schuld rauskommt

Die Antwort ist unglamourös, aber sie funktioniert.

Inventur. Man kann nur verwalten, was man kennt. Eine aktuelle CMDB oder auch nur eine vernünftig gepflegte Tabelle mit Hardware, Software-Ständen, Supportverträgen und Ablaufdaten ist der Ausgangspunkt. Ohne das ist jede Priorisierung Raten.

Risiko-Bewertung. Nicht jede technische Schuld ist gleich kritisch. Ein End-of-Life-Switch im Testlabor ist etwas anderes als einer im Core. Die Kombination aus Kritikalität und Ausfallwahrscheinlichkeit ergibt eine nutzbare Rangfolge.

Roadmap in Quartalen. Ein einziger Masterplan ist selten umsetzbar. Was funktioniert, sind konkrete Maßnahmen pro Quartal, mit Budget, Verantwortlichkeit und messbarem Ergebnis. "Bis Q3 2026 sind alle Windows-Server-2016-Hosts migriert" ist ein Ziel. "Wir sollten mal die alten Server anschauen" ist keins.

Automatisierung und Standardisierung. Je mehr Konfiguration in Code statt in manuellen Änderungen steckt (Ansible, Terraform, GitOps), desto weniger Dokumentations-Schuld entsteht im laufenden Betrieb.

Kontinuierliches Monitoring. Schuld entsteht oft dort, wo niemand hinschaut. Ein sauberes Monitoring macht sichtbar, was sonst unsichtbar bleibt, vom ungewöhnlichen Patchstand bis zum auslaufenden Zertifikat.

Framework statt Stückwerk. ISO 27001 ist kein Selbstzweck, aber es zwingt die Organisation, alle genannten Punkte systematisch anzugehen. Wir haben uns im März 2026 selbst zertifiziert, nicht weil es auf einer Website gut aussieht, sondern weil es die Prozesse wirklich diszipliniert. Dasselbe gilt für die NIS2-Vorbereitung.

Das Einzige, was langfristig teurer ist als Aufräumen

Man muss technische Schuld nicht dämonisieren. Jeder Betrieb arbeitet mit einer gewissen Menge davon, und das ist okay, solange sie bewusst eingegangen und bewusst abgebaut wird. Problematisch wird es, wenn Schuld zum Normalzustand wird, weil niemand mehr darüber spricht.

Unsere Erfahrung aus zahlreichen Migrationen, Modernisierungen und manchmal auch Incident-Recoveries: Jeder Euro, den man in geordneten Abbau steckt, spart später zwischen drei und zehn Euro an Reaktionsarbeit. Das gilt für den Server genauso wie für die Netzwerk-Infrastruktur, und es gilt ganz besonders dort, wo Sicherheit und Compliance im Spiel sind.

Wer nicht weiß, wo er steht, kann eine strukturierte Bestandsaufnahme als ersten Schritt machen. Das ist weniger schmerzhaft, als später eine Woche Produktionsausfall zu erklären, und wer dabei einen externen Blick will, schreibt an office@rocklogic.at.