Technische Schulden in der Verwaltung: Woran man erkennt, was wirklich gefährlich wird
Nicht jede alte Plattform ist automatisch ein Notfall. Kritisch wird technische Schuld dort, wo Wissen, Wiederherstellung, Support oder sichere Änderungen nicht mehr belastbar funktionieren.
Praxisnotiz · von Christian Hoberg · veröffentlicht 23.09.2026 · 10 Min. Lesezeit
LifecycleTechnische SchuldenRecoveryBetrieb
FrageWelche Altlasten sind nur unschön – und welche werden zum echten Betriebsrisiko?
ProblemAlte Systeme werden häufig pauschal als kritisch markiert. Dadurch konkurrieren kosmetische Modernisierung und echte Single Points of Failure um dieselben Ressourcen.
Erster SchrittFür die wichtigsten Services jeweils Supportstatus, Owner, Restore-Nachweis, Monitoring und dokumentierten Änderungsweg erfassen.
ZielEine belastbare Ablöseliste nach Betriebsrisiko statt nach Baujahr.
Alter allein ist kein ausreichendes Kriterium
Ein älteres System kann vertretbar sein, wenn es unterstützt, dokumentiert, gesichert und wiederherstellbar betrieben wird. Umgekehrt kann eine neue Plattform problematisch sein, wenn nur eine Person sie versteht oder ein Restore nie praktisch getestet wurde.
Fünf Warnzeichen für gefährliche technische Schuld
Besonders kritisch sind Kombinationen aus fehlendem Hersteller- oder Community-Support, unbekannten Abhängigkeiten, nicht getesteter Wiederherstellung, Einzelpersonenwissen und Änderungen ohne sauberen Rückfallweg.
Support oder Sicherheitsupdates fehlen
Restore wurde nie praktisch abgenommen
Abhängigkeiten sind nicht dokumentiert
Nur eine Person kann die Plattform betreiben
Änderungen haben keinen getesteten Rollback
Ablösen oder zuerst stabilisieren
Nicht jede kritische Altlast lässt sich sofort ersetzen. Häufig ist ein zweistufiger Weg realistischer: zuerst Backup, Monitoring, Dokumentation und Zugänge stabilisieren; danach die eigentliche Migration mit weniger Risiko planen.
Technische Schulden gehören in die Projektplanung
Eine Lifecycle-Liste wird erst nützlich, wenn aus ihr ein begrenzter Arbeitsvorrat entsteht. Für jedes kritische System braucht es einen nächsten Schritt: akzeptieren, absichern, modernisieren oder ablösen.
In vier Wochen entsteht kein perfektes CMDB-Projekt, aber eine belastbare Sicht auf kritische Services, Systeme, Owner, Abhängigkeiten, Backup/Restore, Monitoring und die wichtigsten offenen Risiken.
Statt noch mehr Hostchecks aufzubauen, werden zehn wichtige Verwaltungsservices mit Abhängigkeiten, Nutzerwirkung, Alarmweg und einem echten Fehlerfall als End-to-End-Monitoring modelliert.
Wenn Security, Lifecycle, Fachverfahren, Support und neue Projekte gleichzeitig drängen, braucht es keine weitere Wunschliste, sondern eine einfache Reihenfolge nach Risiko, Wirkung und Betriebsfähigkeit.
Backups allein machen eine Kommune noch nicht handlungsfähig. Entscheidend ist, welche Verwaltungsleistungen zuerst zurückkommen, wie Teams ohne Standard-IT kommunizieren und wer den Wiederanlauf steuert.