Altsystem ablösen: die Vorarbeit, die über den Ausgang entscheidet
Für: Verantwortliche für Altsysteme
Aktualisiert: 2026-09
Die Ablösung eines Altsystems scheitert meist an drei Dingen: undokumentierter Fachlogik, die niemand mehr kennt, Datenqualität die erst bei der Migration sichtbar wird, und einem fehlenden Abschaltzeitpunkt, wodurch beide Systeme dauerhaft parallel laufen.
Altsysteme sind selten deshalb ein Problem, weil sie alt sind. Sie werden zum Problem, weil das Wissen über sie verschwindet, während die Abhängigkeit von ihnen bleibt. Wer sie ablöst, kämpft weniger mit Technik als mit Archäologie.
Diese Liste betrifft die Vorarbeit vor dem Beginn der Entwicklung. Sie ist der Teil, der beim Sparen am ehesten wegfällt — und derjenige, dessen Fehlen Projekte am zuverlässigsten scheitern lässt.
Die Checkliste
- 01
Fachlogik aus dem System herausarbeiten
Die Regeln, nach denen das Altsystem arbeitet, sind meist nirgends dokumentiert und teilweise nur im Code oder in den Köpfen weniger Personen vorhanden. Sie zu rekonstruieren ist der aufwendigste und wichtigste Teil.
Erledigt, wenn: Die Fachregeln sind schriftlich festgehalten und von den Fachbereichen als vollständig bestätigt.
- 02
Tatsächliche Nutzung messen
Erheben, welche Funktionen wirklich benutzt werden. Regelmässig zeigt sich, dass ein erheblicher Teil des Funktionsumfangs seit Jahren niemand mehr anfasst — und nicht nachgebaut werden muss.
Erledigt, wenn: Es liegen Nutzungsdaten über mindestens ein Quartal vor, und nicht genutzte Funktionen sind als solche markiert.
- 03
Datenqualität vor der Migration prüfen
Alte Datenbestände enthalten Dubletten, unvollständige Sätze und Werte, die dem Schema widersprechen. Das kommt bei der Migration ans Licht — die Frage ist nur, ob geplant oder mitten im Umstieg.
Erledigt, wenn: Eine Stichprobe wurde gegen die Regeln des Zielsystems geprüft, und der Bereinigungsaufwand ist geschätzt.
- 04
Alle Schnittstellen erfassen
Auch die inoffiziellen: Datenexporte, die jemand monatlich manuell zieht, Tabellen die aus dem System gespeist werden, Berichte die anderswo weiterverarbeitet werden. Diese fehlen in jeder Systemdokumentation.
Erledigt, wenn: Die Liste enthält auch manuelle und inoffizielle Datenflüsse, bestätigt durch Befragung der Fachbereiche.
- 05
Umstellungsweg wählen
Auf einen Schlag, schrittweise nach Funktionsbereich oder parallel mit schrittweiser Umlenkung. Jeder Weg hat eigene Risiken; entscheidend ist, dass die Wahl bewusst und begründet erfolgt.
Erledigt, wenn: Der Weg ist gewählt, begründet und mit den Fachbereichen abgestimmt.
- 06
Abschaltzeitpunkt verbindlich festlegen
Ohne festgelegtes Datum laufen beide Systeme dauerhaft parallel — der teuerste aller möglichen Zustände. Der Zeitpunkt gehört von Beginn an in die Planung, nicht ans Ende.
Erledigt, wenn: Ein Abschaltdatum ist vereinbart, und die Bedingungen für eine Verschiebung sind vorab definiert.
- 07
Aufbewahrungspflichten klären
Für Altdaten bestehen oft gesetzliche Aufbewahrungsfristen, die eine Abschaltung nicht aufhebt. Ein Archivzugang muss geplant werden, bevor das System aus dem Betrieb geht.
Erledigt, wenn: Die Aufbewahrungsfristen sind bekannt, und der Archivzugang für die Restlaufzeit ist beschrieben.
Häufige Fehler
- —Das Neusystem baut den Funktionsumfang des Altsystems vollständig nach, obwohl ein grosser Teil davon seit Jahren ungenutzt ist.
- —Die Datenqualität wird erst beim ersten Migrationslauf geprüft. Der dann sichtbare Bereinigungsaufwand steht in keinem Plan.
- —Es gibt keinen verbindlichen Abschalttermin. Beide Systeme laufen weiter, die Kosten verdoppeln sich, und niemand ist zuständig.
- —Manuelle Datenexporte werden übersehen, weil sie in keiner Systemdokumentation stehen — und fallen erst nach der Abschaltung auf.
Was diese Checkliste nicht abdeckt
- —Diese Liste behandelt die Vorarbeit. Die Auswahl der Zielarchitektur und die Entwicklung selbst folgen einer eigenen Logik.
- —Aufwandsschätzungen für die Ablösung sind vor der Rekonstruktion der Fachlogik nicht belastbar. Wer vorher schätzt, schätzt die Unbekannte mit.
- —Bei Systemen, die regulatorischen Anforderungen unterliegen, kommen Nachweis- und Validierungspflichten hinzu, die hier nicht abgedeckt sind.
- —Die organisatorische Seite — Schulung, Widerstände, Prozessänderungen — ist ein eigener Arbeitsstrang und mindestens so entscheidend wie die technische.
Übergeordnete Leistung: Digitale Transformation
Passende Angebote
Legacy-Modernisierung
Legacy-Modernisierung macht gewachsene Software wieder wartbar und zukunftsfähig — schrittweise statt im riskanten Big-Bang. Ergebnis ist ein System, das sich weiterentwickeln lässt, ohne dass der laufende Betrieb dafür angehalten oder alles auf einmal neu gebaut werden muss.
IT-Strategie & Roadmap
Eine IT-Strategie beantwortet, welche technischen Investitionen die Geschäftsziele am stärksten voranbringen — und in welcher Reihenfolge. Ergebnis ist eine priorisierte Roadmap, die aus einer diffusen Wunschliste einen umsetzbaren Fahrplan mit klaren Handlungsfeldern und Meilensteinen macht.
Häufige Fragen
Lohnt sich eine schrittweise Ablösung?
Meist ja, weil sie das Risiko verteilt und früh Erkenntnisse liefert. Der Preis ist eine Phase mit zwei Systemen, die technisch und organisatorisch aufwendig ist und deshalb befristet sein muss.
Was, wenn niemand mehr die Fachlogik kennt?
Dann bleibt die Rekonstruktion aus Verhalten und Code, ergänzt durch Befragung der Fachbereiche. Das ist aufwendig, aber unumgänglich — ein Nachbau ohne verstandene Regeln erzeugt neue Fehler.
Kann man das Altsystem einfach weiterlaufen lassen?
Manchmal ist genau das die richtige Entscheidung. Sie sollte aber bewusst getroffen und mit einer Aussage zu Sicherheit, Wartbarkeit und Personenabhängigkeit begründet werden.
Weitere Checklisten
Softwarepartner auswählen: was vor der Beauftragung zu prüfen ist
Bei der Auswahl eines Softwarepartners entscheiden weniger die Referenzen als vier vertragliche Punkte: Wem gehört das Ergebnis, wer hat Zugang zu den Systemen, wie sieht eine Übergabe aus, und was passiert, wenn die Zusammenarbeit endet.
EU-AI-Act-Konformität: die Checkliste für den ersten Durchgang
Ein tragfähiger erster Durchgang durch den EU AI Act besteht aus sechs Schritten: wissen, welche KI im Haus läuft, die eigene Rolle je System bestimmen, nach Artikel 6 einstufen, Transparenzpflichten separat prüfen, KI-Kompetenz sicherstellen und alles so ablegen, dass es im Prüffall auffindbar ist.
Hochrisiko oder nicht: die Einstufung nach Anhang III sauber begründen
Die Hochrisiko-Einstufung folgt einer festen Reihenfolge: zuerst der Einsatzbereich nach Anhang III, dann die Frage, ob das System dort eine tragende Rolle für die Entscheidung spielt, dann die Ausnahme nach Artikel 6 Absatz 3. Jeder dieser Schritte muss begründet dokumentiert werden.