Altsystem ablösen: Ablauf, Datenmigration und Cutover

Ein Altsystem abzulösen ist kein Entwicklungsprojekt mit einem Zusatzschritt, sondern ein eigener Projekttyp. Der Unterschied: Sie bauen nicht auf der grünen Wiese, sondern gegen einen laufenden Betrieb, einen gewachsenen Datenbestand und eine Fachlichkeit, die zu großen Teilen nirgends dokumentiert ist. Dieser Ratgeber beschreibt den Ablauf eines Ablöseprojekts von der Vorbereitung bis zur Abschaltung des Altsystems.

Vorausgesetzt wird, dass die Grundsatzentscheidung gefallen ist. Falls nicht: Ob Ablösen überhaupt die richtige Antwort ist – oder ob ein gezielter Eingriff genügt –, klärt der Ratgeber Legacy-System modernisieren. Dort stehen auch die sieben Strategien, aus denen die Ablösung nur eine ist.

Altsystem ablösen oder weiterbetreiben? Die Vorentscheidung in drei Fragen

Bevor Sie Aufwand investieren, prüfen Sie diese drei Punkte. Sie ersparen im besten Fall das ganze Projekt:

1. Erklärt ein einzelner Engpass das Problem? Wenn ja, tauschen Sie diesen Baustein und behalten den Rest. Eine Ablösung wegen einer unbrauchbaren Benutzeroberfläche ist wie ein Hausabriss wegen undichter Fenster.
2. Wird das System überhaupt noch genutzt? Messen Sie es, statt zu fragen. In gewachsenen Landschaften ist ein überraschend hoher Anteil an Funktionen faktisch tot – die dürfen ersatzlos entfallen.
3. Gibt es ein Standardprodukt, das den Prozess abdeckt? Bei Standardprozessen ist Kaufen fast immer günstiger als Bauen. Bei Prozessen, die Sie vom Wettbewerb unterscheiden, ist es umgekehrt (siehe Individualsoftware oder Standardsoftware?).

Die sieben Phasen einer Altsystem-Ablösung

Phase	Ergebnis	Typische Dauer	Wer trägt sie
1. Bestandsaufnahme	Schnittstellen, Datenmodell, Nutzung, Abhängigkeiten	2–6 Wochen	Dienstleister + IT
2. Fachlichkeit rekonstruieren	dokumentierte Regeln, Sonderfälle, Ausnahmen	3–8 Wochen	Fachbereich
3. Zielbild & Schnitt	Reihenfolge der Ablösung, Umfang je Schritt	2–4 Wochen	gemeinsam
4. Aufbau des Neusystems	lauffähige Teilfunktion je Schritt	Monate bis Jahre	Dienstleister
5. Datenmigration	bereinigte, geprüfte Daten im Zielsystem	parallel, eigener Strang	gemeinsam
6. Umstellung (Cutover)	produktive Nutzung des Neusystems	Tage bis Monate	gemeinsam
7. Abschaltung & Archivierung	Altsystem aus, Daten rechtssicher verfügbar	2–8 Wochen	IT + Fachbereich

Die Phasen 1 bis 3 machen zusammen oft nur zehn bis zwanzig Prozent des Budgets aus und entscheiden über den Ausgang des restlichen Projekts. Wer hier kürzt, bezahlt in Phase 4 das Mehrfache – dort schlägt jede unentdeckte Fachregel als Änderungsauftrag auf.

Fachlichkeit rekonstruieren, wenn niemand mehr weiß, was das System tut

Das ist der unterschätzteste Teil eines Ablöseprojekts. Ein System, das seit fünfzehn Jahren läuft, enthält Regeln, die niemand mehr erklären kann und die trotzdem gebraucht werden – Rabattlogiken für einzelne Kunden, Sonderfälle bei Jahreswechseln, historisch gewachsene Rundungsregeln. Diese Regeln stehen im Code oder in den Daten, nicht in einer Anleitung.

Vier Zugänge, die sich ergänzen:

• Verhalten beobachten: Ein- und Ausgaben des laufenden Systems für typische und untypische Fälle protokollieren. Das liefert die verlässlichste Wahrheit, weil es das tatsächliche Verhalten abbildet.
• Daten analysieren: Ausprägungen, Wertebereiche und Sonderfälle im Bestand zeigen, welche Regeln real vorkommen und welche nur theoretisch.
• Anwender begleiten: Eine halbe Stunde neben jemandem sitzen, der täglich damit arbeitet, bringt mehr als drei Workshops. Achten Sie besonders auf Umgehungslösungen in Tabellenkalkulationen – jede davon markiert eine Lücke.
• Code lesen, sofern vorhanden. Als Ergänzung, nicht als Hauptquelle: Der Code zeigt, was passiert, aber nicht, warum – und ob es noch gewollt ist.

Das Ergebnis ist kein vollständiges Pflichtenheft, sondern eine dokumentierte Liste fachlicher Regeln mit Herkunft und offenen Fragen. Sie ist die Grundlage für die Anforderungen an das neue System (siehe Anforderungen richtig definieren).

Nicht alles nachbauen

Der teuerste und häufigste Fehler ist das Ziel „das Neue muss alles können, was das Alte konnte". Nach fünfzehn Jahren enthält jedes System Funktionen, die einmal für einen Sonderfall gebaut wurden, der längst weggefallen ist. Gehen Sie stattdessen so vor: Nutzung messen, jede Funktion einer der drei Kategorien zuordnen – „wird gebraucht", „wird ersetzt durch etwas Besseres", „entfällt" – und die dritte Kategorie schriftlich vom Fachbereich freigeben lassen. Diese Freigabe ist wichtiger als die Liste selbst; sie verhindert, dass die Diskussion drei Monate später erneut geführt wird.

Datenmigration: der Strang, der Projekte kippt

Datenmigration ist kein Schritt am Ende, sondern ein paralleler Arbeitsstrang über die gesamte Laufzeit. Sie umfasst mehr als das Kopieren von Tabellen:

• Analyse: Wie viele Datensätze, welche Qualität, welche Dubletten, welche fachlichen Inkonsistenzen?
• Bereinigung: Wer entscheidet, welcher von zwei widersprüchlichen Datensätzen gilt? Diese Frage gehört in den Fachbereich, nicht in die IT.
• Abbildungsregeln: Wie werden alte Felder auf das neue Modell abgebildet? Was passiert mit Feldern ohne Entsprechung?
• Probeläufe: Mindestens drei, mit vollständigem Datenbestand, nicht mit Stichproben. Jeder Lauf endet mit einem Abgleichbericht.
• Abnahmekriterien: Vorher festlegen, welche Kennzahlen nach der Migration übereinstimmen müssen – Summen, Anzahlen, Stichproben je Datenart.
• Datenschutz: Eine Migration ist eine Verarbeitung personenbezogener Daten. Wenn ein Dienstleister beteiligt ist, brauchen Sie einen Auftragsverarbeitungsvertrag; Testsysteme mit Echtdaten benötigen dieselben Schutzmaßnahmen wie die Produktion oder anonymisierte Daten.

Rechnen Sie mit 15 bis 30 Prozent des Gesamtaufwands für die Migration. Die Details stehen im Ratgeber Datenmigration im Softwareprojekt.

Parallelbetrieb oder Stichtagsumstellung?

Variante	Vorgehen	Vorteil	Nachteil
Stichtagsumstellung	Alt aus, Neu an, meist über ein Wochenende	kurz, klar, keine Doppelpflege	hohes Risiko, kaum Rückweg
Parallelbetrieb	beide Systeme laufen, Daten werden abgeglichen	Vergleichbarkeit, Rückweg möglich	doppelte Arbeit, Konsistenzaufwand
Schrittweise Ablösung	Funktionsbereich für Funktionsbereich	geringes Risiko je Schritt, früher Nutzen	längere Übergangszeit, Zwischenschicht nötig
Pilotgruppe	eine Abteilung oder Region zuerst	echte Rückmeldung bei begrenztem Schaden	Sonderfälle der Pilotgruppe verzerren

Für geschäftskritische Systeme ist die schrittweise Ablösung fast immer die richtige Wahl. Sie folgt dem Muster, das Martin Fowler als Strangler Fig beschreibt: Das neue System übernimmt Bereich für Bereich, während das alte weiterläuft und nach und nach entbehrlich wird. Vorgeschaltet wird eine Steuerungsebene, die entscheidet, welches System eine Anfrage bearbeitet. Diese Zwischenschicht ist zusätzlicher Aufwand – und der Preis dafür, dass kein einzelner Fehler das Tagesgeschäft stoppt.

Unabhängig von der Variante gehört ein schriftlicher Rückfallplan dazu: Wer entscheidet bis wann anhand welcher Kriterien über einen Rücksprung, und wie kommen in der Zwischenzeit entstandene Daten zurück ins Altsystem? Ein Cutover ohne beantwortete Rückfallfrage ist ein Sprung ohne Netz.

Abschaltung und Archivierung: der vergessene Schritt

Ein Altsystem ist nicht abgelöst, wenn das Neue läuft, sondern wenn das Alte aus ist. Genau daran scheitert es oft: Das System bleibt „noch kurz" stehen, weil jemand vielleicht historische Daten braucht – und läuft fünf Jahre später immer noch, inklusive Lizenz-, Wartungs- und Sicherheitskosten.

Planen Sie die Abschaltung als eigenen Schritt mit Termin und Verantwortlichen:

• Aufbewahrungspflichten klären. In Deutschland verlangt § 147 AO die geordnete Aufbewahrung steuerlich relevanter Unterlagen – zehn Jahre für Bücher und Aufzeichnungen, acht Jahre für Buchungsbelege, sechs Jahre für sonstige Unterlagen. Die Daten müssen während der gesamten Frist jederzeit verfügbar, unverzüglich lesbar und maschinell auswertbar sein; die Finanzbehörde darf bei einer Außenprüfung darauf zugreifen. In Österreich regelt § 132 BAO Vergleichbares mit einer Frist von grundsätzlich sieben Jahren. Prüfen Sie das für Ihren Fall mit Ihrer Steuerberatung – die Anforderung „maschinell auswertbar" schließt einen simplen PDF-Ausdruck in vielen Fällen aus.
• Archivform festlegen: Übernahme der historischen Daten ins Neusystem, ein revisionssicheres Archiv oder – als schwächste Variante – ein eingefrorenes, schreibgeschütztes Altsystem in einer isolierten Umgebung.
• Löschkonzept: Personenbezogene Daten dürfen nicht unbegrenzt aufbewahrt werden, nur weil das technisch einfacher ist. Aufbewahrungspflicht und Löschpflicht müssen gegeneinander abgegrenzt werden.
• Abschaltung dokumentieren: Datum, Verantwortliche, letzte Sicherung, Ablageort. Das ist die Grundlage, um Lizenzen und Wartungsverträge tatsächlich zu kündigen – der Punkt, an dem das Projekt anfängt, Geld zu sparen.

Was ein Ablöseprojekt kostet

Faustregeln aus der Praxis: Die Analyse- und Rekonstruktionsphase liegt bei 15 bis 30 Personentagen für ein mittleres System. Die Datenmigration schlägt mit 15 bis 30 Prozent des Gesamtaufwands zu Buche. Der Parallelbetrieb kostet zusätzlich 10 bis 20 Prozent. Und für die Abschaltung inklusive Archivierung sollten Sie 5 bis 15 Personentage einplanen – ein Posten, der in Angeboten praktisch immer fehlt.

Vertraglich ist ein Ablöseprojekt in aller Regel ein Werkvertrag mit Abnahme. Achten Sie besonders auf messbare Abnahmekriterien für die Datenmigration – etwa „Summen je Konto stimmen auf den Cent überein, Stichprobe von 200 Datensätzen fehlerfrei" – und auf die Herausgabe von Quellcode, Migrationsskripten und Dokumentation. Die Migrationsskripte sind der Teil, den Sie später brauchen und der am ehesten „vergessen" wird.

Typische Fehler

• Erst bauen, dann migrieren. Die Datenqualität entscheidet über den Umfang – erst analysieren.
• Funktionsgleichheit als Ziel. Nachbauen ist teurer als neu denken und liefert selten einen besseren Prozess.
• Fachbereich erst zur Abnahme einbinden. Dann sind die Sonderfälle nicht abgebildet und es wird teuer.
• Kein Rückfallplan. Vor dem Cutover schriftlich, mit Kriterien und Entscheidungsfrist.
• Altsystem nicht abschalten. Ohne Termin und Verantwortliche läuft es jahrelang weiter.
• Aufbewahrungspflichten zu spät klären. Sie bestimmen die Archivform – und die bestimmt die Architektur.

Kurz gefasst

Ein Altsystem abzulösen beginnt mit Bestandsaufnahme und der Rekonstruktion der Fachlichkeit, nicht mit Entwicklung. Bauen Sie nicht alles nach, sondern lassen Sie den Fachbereich schriftlich freigeben, was entfällt. Behandeln Sie die Datenmigration als eigenen Strang mit Probeläufen und messbaren Abnahmekriterien. Wählen Sie für geschäftskritische Systeme die schrittweise Ablösung mit Rückfallplan. Und planen Sie die Abschaltung samt Archivierung als eigenen Schritt mit Termin – erst dann spart das Projekt Geld.

Häufige Fragen

Wie lange dauert die Ablösung eines Altsystems?

Für eine überschaubare Fachanwendung sechs bis zwölf Monate, für ein geschäftskritisches System mit vielen Schnittstellen zwei bis vier Jahre in Teilschritten. Die Analyse- und Rekonstruktionsphase allein nimmt zwei bis vier Monate in Anspruch. Zeitpläne, die diese Phase auf zwei Wochen ansetzen, sind ein Warnsignal.

Was kostet eine Altsystem-Ablösung?

Sie hängt fast vollständig vom Umfang der Fachlichkeit ab, nicht von der Technologie. Belastbar wird die Schätzung erst nach der Bestandsaufnahme. Verlangen Sie eine bezahlte Vorstudie mit einer Schätzung in Personentagen je Teilbereich – und die Übergabe des Ergebnisses in einer Form, mit der Sie auch anderswo ausschreiben können.

Kann man ein Altsystem ohne Quellcode ablösen?

Ja. Die Fachlichkeit wird dann aus dem Verhalten des laufenden Systems, aus dem Datenbestand und aus Anwendergesprächen rekonstruiert. Das ist aufwendiger und dauert länger, ist aber der Normalfall bei sehr alten Systemen. Wichtig ist der Zugriff auf die Datenbank – ohne ihn wird es deutlich schwieriger und teurer.

Müssen alle historischen Daten ins neue System?

Nein, und meist ist es die schlechtere Lösung. Üblich ist eine Zweiteilung: aktive Daten und ein definierter Zeitraum wandern ins Neusystem, ältere Bestände in ein Archiv. Das reduziert Migrationsaufwand und Komplexität erheblich. Der Zeitraum ergibt sich aus fachlichem Bedarf und Aufbewahrungspflichten.

Wie lange muss das Altsystem nach der Umstellung noch laufen?

So kurz wie möglich, so lange wie nötig. Üblich sind ein bis drei Monate als Rückfalloption, danach schreibgeschützt für Nachfragen, dann Abschaltung. Entscheidend ist ein Termin mit Verantwortlichen. Ohne ihn läuft das System dauerhaft weiter und verursacht Kosten, für die niemand mehr zuständig ist.

Wer sollte das Projekt leiten – IT oder Fachbereich?

Die Projektleitung gehört dorthin, wo die fachlichen Entscheidungen fallen, also überwiegend in den Fachbereich, mit technischer Leitung an der Seite. Ablöseprojekte scheitern häufiger an ungeklärten fachlichen Fragen als an technischen Problemen. Benennen Sie eine entscheidungsfähige Person mit Vertretung – und rechnen Sie mit ein bis zwei Tagen pro Woche über die gesamte Laufzeit.

Was passiert mit den Schnittstellen zu anderen Systemen?

Sie sind der Grund, warum Ablösungen länger dauern als geplant. Erstellen Sie in der Bestandsaufnahme eine vollständige Liste eingehender und ausgehender Verbindungen – inklusive Dateiablagen, geplanter Exportjobs und Auswertungen, die jemand monatlich von Hand zieht. Jede Verbindung braucht eine Entscheidung: übernehmen, ersetzen oder abschalten.

Weiterführende Ratgeber

• Legacy-System modernisieren – die Strategieentscheidung vor diesem Projekt
• Access-Datenbank ablösen – der häufigste konkrete Anlassfall
• Datenmigration im Softwareprojekt – der Migrationsstrang im Detail
• Systemintegration & Schnittstellen – Verbindungen zu Nachbarsystemen
• Anforderungen richtig definieren – aus rekonstruierter Fachlichkeit werden Anforderungen
• Software-Abnahme & Qualitätssicherung – Abnahmekriterien für Migrationen

Anbieter im Verzeichnis: Softwareentwicklung, IT-Beratung, ERP & CRM.