Die Altsystem-Ablösung im Mittelstand ist für viele Unternehmen kein optionales IT-Projekt mehr, sondern eine organisatorische Notwendigkeit. Alte ERP-Module, historisch gewachsene Eigenentwicklungen oder Anwendungen ohne Herstellersupport laufen oft seit zehn, fünfzehn oder mehr Jahren im Hintergrund und tragen zentrale Geschäftsprozesse. Solange sie funktionieren, geraten sie selten auf die Prioritätenliste der Geschäftsführung. Genau darin liegt das Risiko: Mit jedem Jahr ohne Patches, mit jedem Mitarbeiter, der das System als Einziger versteht, und mit jeder Inkompatibilität zu neuer Hardware wächst der Druck, unter dem eine spätere Ablösung stattfinden muss. Anders als bei der Einführung neuer Werkzeuge geht es bei der Altsystem-Ablösung nicht um die Auswahl der besten Lösung, sondern um den kontrollierten Abschied von etwas, das oft tief in Prozesse, Datenbestände und Köpfe eingewachsen ist. Dieser Beitrag beschreibt, wie eine strukturierte Bestandsaufnahme aussieht, welche Risikofaktoren in die Bewertung gehören, welche Migrationsstrategien sich in der Praxis bewährt haben und wie Datenmigration sowie Archivierung unter Beachtung von GoBD und HGB gelingen. Ziel ist ein Vorgehen, das Geschäftsrisiken minimiert, ohne den laufenden Betrieb zu gefährden.
Titelbild: Foto von Kevin Ache auf Unsplash.
Warum die Altsystem-Ablösung im Mittelstand zur Pflichtaufgabe wird
Legacy-Systeme entstehen selten aus einer bewussten Entscheidung. Sie sind das Ergebnis jahrelanger Anpassungen, individueller Schnittstellen und punktueller Erweiterungen, die zu einem Zeitpunkt sinnvoll waren, aber nie grundlegend überarbeitet wurden. Mit der Zeit verschiebt sich das Verhältnis von Nutzen und Risiko: Der Hersteller stellt den Support ein, Sicherheitsupdates bleiben aus, und die zugrunde liegende Programmiersprache oder Datenbank findet am Arbeitsmarkt kaum noch Fachkräfte. Gleichzeitig verlangen Kunden, Lieferanten und Behörden zunehmend digitale Schnittstellen, die ein isoliertes Altsystem nicht mehr bedienen kann.
Für Geschäftsführer und IT-Verantwortliche im Mittelstand bedeutet das: Die Frage ist nicht mehr, ob Legacy-Systeme abgelöst werden, sondern wann und unter welchen Bedingungen. Wer die Ablösung aufschiebt, bis das System ausfällt, verliert die Kontrolle über Zeitplan, Budget und Datenqualität. Eine geplante Systemmigration lässt sich dagegen in Etappen steuern, testen und absichern.
Hinzu kommt ein organisatorischer Faktor, der häufig unterschätzt wird: Mit jedem Jahr, das ein Altsystem länger im Einsatz bleibt, wächst die Zahl der Ausnahmeregelungen, individuellen Anpassungen und stillschweigenden Workarounds, die sich im Tagesgeschäft eingespielt haben. Diese informelle Komplexität taucht in keiner Systemdokumentation auf, beeinflusst aber jede spätere Ablösungsplanung. Je länger ein Unternehmen wartet, desto aufwendiger wird es, diese gewachsenen Abhängigkeiten überhaupt zu identifizieren, bevor sie im neuen System fehlen und zu Prozessbrüchen führen.
Bestandsaufnahme: Das Altsystem-Inventar strukturiert erfassen
Am Anfang jeder Altsystem-Ablösung steht eine vollständige Inventur. Viele mittelständische Unternehmen unterschätzen, wie viele Altanwendungen tatsächlich im Einsatz sind, weil einzelne Abteilungen eigene Insellösungen betreiben, die der zentralen IT nicht bekannt sind. Ohne dieses Inventar lässt sich weder eine belastbare Risikobewertung noch eine realistische Migrationsplanung erstellen.
Eine strukturierte Inventur sollte für jedes System mindestens folgende Punkte dokumentieren:
- Funktionaler Zweck und betroffene Geschäftsprozesse (zum Beispiel Warenwirtschaft, Fakturierung, Produktionssteuerung)
- Technische Basis: Betriebssystem, Datenbank, Programmiersprache, Schnittstellen zu anderen Systemen
- Herstellersupport-Status (aktiv, ausgelaufen, nie vorhanden bei Eigenentwicklungen)
- Anzahl und Rolle der Nutzer sowie der Personen mit Administrations- oder Wartungswissen
- Vorhandene oder fehlende Dokumentation, einschließlich Quellcode-Kommentaren bei Eigenentwicklungen
- Datenvolumen, Datenarten und rechtlich relevante Aufbewahrungsfristen
Fachbereiche als Wissensquelle einbeziehen
Die IT allein kennt selten alle fachlichen Feinheiten eines Altsystems. Fachbereiche wissen oft, welche manuellen Workarounds im Alltag existieren, welche Berichte niemand mehr braucht und welche Funktionen unverzichtbar sind. Diese Informationen fließen direkt in die spätere Entscheidung ein, welche Funktionalität ein Nachfolgesystem zwingend abbilden muss und welche ersatzlos entfallen kann.
In der Praxis empfiehlt sich dafür ein einfaches, aber verbindliches Format: kurze Fachinterviews von etwa einer Stunde je Abteilung, protokolliert und anschließend von den Beteiligten gegengelesen. So entsteht eine nachvollziehbare Grundlage, auf die sich spätere Entscheidungen zur Migrationsstrategie stützen lassen, ohne dass Wissen ausschließlich in den Köpfen einzelner Mitarbeiter verbleibt.
Risikobewertung: Sicherheitslücken, Support-Ende und Wissensträger
Nach der Inventur folgt die Bewertung, welche Altsysteme am dringendsten abgelöst werden müssen. Eine reine Alterseinschätzung reicht dafür nicht aus, da ein zehn Jahre altes, gut gepflegtes System weniger riskant sein kann als eine drei Jahre alte, aber unsupportete Eigenentwicklung. Bewährt hat sich ein Bewertungsraster mit mehreren Risikodimensionen, die jeweils mit einer Punktzahl versehen und anschließend gewichtet werden.
| Risikodimension | Leitfrage | Beispiel für hohes Risiko |
|---|---|---|
| Sicherheit | Erhält das System noch Sicherheitsupdates? | Ausgelaufener Support, bekannte ungepatchte Schwachstellen |
| Wissensverfügbarkeit | Wie viele Personen können das System warten? | Nur eine Person, kurz vor Renteneintritt |
| Technische Abhängigkeit | Läuft das System auf veralteter Hardware oder Software? | Betriebssystem ohne Herstellersupport, spezielle Altserver |
| Prozesskritikalität | Wie stark hängt der Betrieb vom System ab? | Zentrale Warenwirtschaft ohne manuellen Ersatzprozess |
| Compliance | Erfüllt das System aktuelle Anforderungen an Nachvollziehbarkeit? | Fehlende Protokollierung, keine GoBD-konforme Journalführung |
Für jede Dimension empfiehlt sich eine einfache Skala von eins (unkritisch) bis fünf (hochkritisch). Systeme mit hoher Punktzahl in mehreren Dimensionen gleichzeitig, etwa fehlender Support kombiniert mit nur einem Wissensträger, sollten in der Ablösungsreihenfolge priorisiert werden. Das Bundesamt für Sicherheit in der Informationstechnik stellt hierzu allgemeine Empfehlungen zur Absicherung veralteter IT-Systeme bereit, die sich als Orientierung für die Sicherheitsbewertung eignen (www.bsi.bund.de).
Ein Altsystem ist nicht deshalb unkritisch, weil es seit Jahren störungsfrei läuft. Es ist unkritisch, wenn sein Ausfall keine Geschäftsprozesse gefährdet und sein Wissen nicht an einzelnen Personen hängt.
Migrationsstrategien für die Ablösung von Legacy-Systemen
Wer Legacy-Systeme ablösen will, steht vor der grundsätzlichen Frage nach dem Vorgehen. Drei Strategien haben sich im Mittelstand etabliert, jede mit unterschiedlichem Risikoprofil und Ressourcenbedarf.
Big-Bang-Ablösung
Bei der Big-Bang-Strategie wird das Altsystem an einem festgelegten Stichtag vollständig abgeschaltet und durch das neue System ersetzt. Der Vorteil liegt in der klaren zeitlichen Abgrenzung: Es gibt keinen langwierigen Parallelbetrieb, und alle Beteiligten arbeiten ab einem bestimmten Datum nur noch mit der neuen Umgebung. Der Nachteil ist ein hohes Ausfallrisiko, da Fehler in der Datenmigration oder unerwartete Prozesslücken sich unmittelbar auf den laufenden Betrieb auswirken. Diese Strategie eignet sich vor allem für kleinere, klar abgegrenzte Systeme mit überschaubarem Datenvolumen.
Schrittweise Ablösung
Bei der schrittweisen Ablösung wird die Funktionalität des Altsystems modulweise auf das neue System übertragen, etwa zunächst die Lagerverwaltung, danach die Fakturierung und zuletzt die Produktionsplanung. Dieses Vorgehen reduziert das Risiko einzelner Migrationsschritte und erlaubt es, aus jedem Schritt für den nächsten zu lernen. Der Preis dafür ist ein längerer Gesamtzeitraum, in dem beide Systeme koexistieren und Schnittstellen zwischen ihnen gepflegt werden müssen.
Parallelbetrieb
Beim Parallelbetrieb laufen Alt- und Neusystem für einen definierten Zeitraum gleichzeitig, wobei Daten in beiden Systemen erfasst oder abgeglichen werden. Dieses Vorgehen bietet die höchste Sicherheit, da im Zweifelsfall auf das Altsystem zurückgegriffen werden kann. Es bindet allerdings erheblich mehr Personalkapazität, da Mitarbeiter zeitweise doppelt arbeiten. Ein klar terminiertes Enddatum für den Parallelbetrieb ist entscheidend, da sich sonst beide Systeme dauerhaft etablieren und keine echte Ablösung stattfindet.
Die Wahl der Strategie hängt von Systemkomplexität, Datenvolumen, verfügbaren Ressourcen und der Risikobereitschaft der Geschäftsführung ab. In der Praxis kombinieren viele Unternehmen die Ansätze: unkritische Module werden per Big-Bang abgelöst, zentrale Kernsysteme schrittweise mit befristetem Parallelbetrieb.
Unabhängig von der gewählten Strategie sollte jede Migrationsphase mit klar definierten Abnahmekriterien enden, bevor die nächste beginnt. Dazu gehören vollständige Datenabgleiche zwischen Alt- und Neusystem, ein dokumentierter Testlauf der wichtigsten Geschäftsprozesse sowie eine schriftliche Freigabe durch die jeweiligen Fachbereiche. Ohne solche Abnahmepunkte besteht die Gefahr, dass Fehler erst Wochen später auffallen, wenn eine Rückverfolgung zur Ursache erheblich aufwendiger ist.
Datenmigration und Archivierung nach GoBD und HGB
Die technische Datenmigration ist nur ein Teil der Aufgabe. Ebenso wichtig ist die rechtssichere Behandlung der Daten, die im Altsystem verbleiben oder aus dem Altsystem übernommen werden. Nach den Grundsätzen zur ordnungsmäßigen Führung und Aufbewahrung von Büchern, Aufzeichnungen und Unterlagen in elektronischer Form (GoBD) müssen steuerlich relevante Daten während der gesamten Aufbewahrungsfrist maschinell auswertbar und unveränderbar verfügbar bleiben. Eine reine Ausdruck- oder PDF-Archivierung reicht dafür in der Regel nicht aus, wenn die ursprünglichen Daten strukturiert vorlagen.
Handelsrechtlich ergeben sich die Aufbewahrungsfristen aus § 257 Handelsgesetzbuch: Handelsbücher, Inventare, Jahresabschlüsse und Buchungsbelege sind zehn Jahre aufzubewahren, empfangene und abgesandte Handelsbriefe sowie sonstige Unterlagen von handelsrechtlicher Bedeutung sechs Jahre. Der genaue Gesetzestext findet sich im Gesetzesportal des Bundesministeriums der Justiz (gesetze-im-internet.de). Wird ein Altsystem abgeschaltet, entbindet das nicht von diesen Pflichten. Für die Praxis ergeben sich daraus drei Optionen.
- Vollständige Übernahme aller aufbewahrungspflichtigen Daten in das neue System, inklusive Historie
- Aufbau eines separaten, GoBD-konformen Archivsystems, das nur für Lese- und Prüfzwecke vorgehalten wird
- Befristeter Weiterbetrieb einer minimalen, gesicherten Altsystem-Instanz ausschließlich für Auskunftszwecke
Die dritte Option verursacht laufende Kosten und Sicherheitsrisiken, weil ein technisch veraltetes System aktiv bleibt. In den meisten Fällen ist ein dediziertes Archivsystem die wirtschaftlichere und sicherere Lösung, da es ohne die volle Funktionalität und ohne die Angriffsfläche der ursprünglichen Anwendung auskommt. Wichtig ist, die Vollständigkeit und Lesbarkeit archivierter Daten vor der endgültigen Abschaltung des Altsystems zu verifizieren, idealerweise durch stichprobenartige Prüfungen mit dem Steuerberater oder Wirtschaftsprüfer.
Typische Stolperfallen bei der Systemmigration
Auch gut geplante Projekte zur Altsystem-Ablösung im Mittelstand scheitern häufig an denselben wiederkehrenden Fehlern. Die Kenntnis dieser Stolperfallen hilft, sie im eigenen Projekt gezielt zu vermeiden.
- Unterschätzte Datenqualität: Altsysteme enthalten oft jahrelang gewachsene Inkonsistenzen, Dubletten und undokumentierte Sonderfälle, die vor der Migration bereinigt werden müssen.
- Fehlende Dokumentation von Schnittstellen: Eigenentwicklungen kommunizieren häufig über undokumentierte Schnittstellen mit anderen Systemen, die bei der Ablösung leicht übersehen werden.
- Zu später Einbezug der Fachabteilungen: Werden Endanwender erst kurz vor dem Umstieg informiert, fehlt die Zeit für Tests und Rückmeldungen.
- Kein klarer Rückfallplan: Ohne definierte Kriterien und Prozesse für einen Rollback im Störungsfall steigt das operative Risiko erheblich.
- Unklare Verantwortung für Restdaten: Wird nicht eindeutig geregelt, wer für die archivierten Altdaten zuständig bleibt, drohen Lücken bei späteren Anfragen von Prüfern oder Kunden.
Ein weiterer, oft unterschätzter Punkt ist die organisatorische Wissenssicherung. Wenn die Person, die ein Altsystem seit Jahren betreut, das Unternehmen vor Abschluss der Migration verlässt, gehen Detailkenntnisse verloren, die sich später nur mit hohem Aufwand rekonstruieren lassen. Interviews und schriftliche Übergabeprotokolle sollten daher fester Bestandteil jeder Ablösungsplanung sein.
Auch die Kommunikation innerhalb des Unternehmens wird häufig vernachlässigt. Wenn Mitarbeiter nicht wissen, warum ein vertrautes System ersetzt wird und welcher Zeitplan gilt, entsteht Unsicherheit, die sich in Widerstand gegen den Umstieg äußern kann. Eine kurze, regelmäßige Statusinformation an alle betroffenen Abteilungen, unabhängig von formellen Projektberichten, reduziert diese Reibung spürbar.
Praxisbeispiel: Ablösung einer veralteten Warenwirtschaft
Das folgende Beispiel ist konstruiert und dient der Veranschaulichung, nicht der Wiedergabe eines realen Falls. Ein mittelständischer Großhändler betreibt eine selbst entwickelte Warenwirtschaft, die vor über fünfzehn Jahren in Betrieb genommen wurde. Der ursprüngliche Entwickler ist seit Jahren nicht mehr im Unternehmen, die Anwendung läuft auf einem Server mit veraltetem Betriebssystem, und Sicherheitsupdates werden nicht mehr eingespielt.
Beispielhafter Ablauf: Nach einer sechswöchigen Inventur identifiziert das Unternehmen 340 GB migrationsrelevante Daten, drei aktive Schnittstellen zur Finanzbuchhaltung und zwei Mitarbeiter mit Detailwissen zum System. Die Risikobewertung stuft das System aufgrund fehlenden Supports und geringer Wissensverteilung als hochkritisch ein.
Das Unternehmen entscheidet sich für eine schrittweise Ablösung mit befristetem Parallelbetrieb von drei Monaten je Modul. Zunächst wird die Lagerverwaltung auf das neue System überführt, während Fakturierung und Einkauf vorerst im Altsystem verbleiben. Historische Buchungsdaten, die aufbewahrungspflichtig sind, werden in ein separates, GoBD-konformes Archivsystem exportiert und dort revisionssicher gespeichert. Erst nachdem alle Module erfolgreich migriert und die Datenvollständigkeit durch Stichproben bestätigt sind, wird die alte Warenwirtschaft endgültig abgeschaltet und der Server stillgelegt. Die genannten Zahlen sind beispielhaft und nicht als allgemeingültige Kennwerte zu verstehen.
Fazit: Strukturiertes Vorgehen statt Reaktion unter Zeitdruck
Die Altsystem-Ablösung im Mittelstand gelingt selten nebenbei. Sie erfordert eine ehrliche Bestandsaufnahme, eine belastbare Risikobewertung und eine zur Systemlandschaft passende Migrationsstrategie. Wer die IT-Modernisierung frühzeitig und planvoll angeht, vermeidet, dass ein Support-Ende oder ein Systemausfall den Zeitplan diktiert. Gleichzeitig sichert eine sorgfältige Datenmigration mit GoBD-konformer Archivierung, dass rechtliche Aufbewahrungspflichten auch nach der Abschaltung des Altsystems erfüllt bleiben. Die Investition in diesen Prozess zahlt sich langfristig durch geringere Sicherheitsrisiken, weniger Abhängigkeit von einzelnen Mitarbeitern und eine belastbarere IT-Infrastruktur aus.
FAQ
Was versteht man unter Altsystem-Ablösung im Mittelstand?
Darunter versteht man den geplanten, strukturierten Ersatz veralteter IT-Anwendungen wie alter ERP-Module, Eigenentwicklungen oder unsupporteter Software durch aktuelle Systeme, einschließlich der ordnungsgemäßen Migration und Archivierung der zugehörigen Daten.
Wie lange sollte ein Parallelbetrieb bei der Systemmigration dauern?
Eine feste Regel gibt es nicht, üblich sind je nach Systemkomplexität mehrere Wochen bis wenige Monate. Entscheidend ist ein von Beginn an klar definiertes Enddatum, damit der Parallelbetrieb nicht zum Dauerzustand wird.
Welche Daten müssen nach GoBD auch nach Abschaltung eines Altsystems verfügbar bleiben?
Steuerlich relevante Daten wie Buchungsbelege, Rechnungen und Journale müssen während der gesetzlichen Aufbewahrungsfrist maschinell auswertbar bleiben, unabhängig davon, ob das ursprüngliche System noch aktiv ist.
Wie lange gelten die handelsrechtlichen Aufbewahrungsfristen nach HGB?
Nach § 257 HGB sind Handelsbücher, Inventare, Jahresabschlüsse und Buchungsbelege zehn Jahre aufzubewahren, Handelsbriefe und vergleichbare Unterlagen sechs Jahre.
Wann ist eine Big-Bang-Ablösung sinnvoller als eine schrittweise Ablösung?
Big-Bang eignet sich für kleinere, klar abgegrenzte Systeme mit überschaubarem Datenvolumen und geringer Prozesskritikalität. Bei komplexen, zentralen Systemen mit hoher Abhängigkeit ist eine schrittweise Ablösung mit Parallelbetrieb in der Regel risikoärmer.
Wer sollte in die Risikobewertung von Altsystemen einbezogen werden?
Neben der IT-Abteilung sollten die betroffenen Fachbereiche, die Geschäftsführung sowie bei aufbewahrungspflichtigen Daten auch Steuerberater oder Wirtschaftsprüfer einbezogen werden, um technische, organisatorische und rechtliche Aspekte gemeinsam zu bewerten.
