Altsystemarchivierung: Altdaten revisionssicher sichern

Die virtuelle Maschine läuft seit 2011. Zwei Personen im Haus wissen noch, wie man sich anmeldet. Die Datenbanklizenz wird jedes Jahr stillschweigend verlängert, und in jedem IT-Roadmap-Workshop steht das System auf der Liste der Dinge, die man irgendwann angehen müsste. Der eigentliche Grund für den Weiterbetrieb steht nirgends: Niemand kann belegen, dass die Daten darin anderswo vollständig vorliegen. Genau diese Belegbarkeit ist das Handwerk der Altsystemarchivierung, und sie entscheidet darüber, ob das System je abgeschaltet wird.

Was Altsystemarchivierung ist und wovon sie sich unterscheidet

Altsystemarchivierung ist die strukturierte Übernahme der Daten einer abzulösenden Anwendung in ein revisionssicheres Archiv, das diese Daten unabhängig von der Ursprungssoftware lesbar, auswertbar und nachweisbar hält.

Diese Definition der Altsystemarchivierung enthält drei Einschränkungen, die in Projekten oft untergehen. Unabhängig von der Ursprungssoftware bedeutet, dass die alte Anwendung danach nicht mehr gebraucht wird, auch nicht als Notfalloption. Auswertbar bedeutet mehr als anzeigbar. Und nachweisbar bedeutet, dass der Zustand der Daten seit der Übernahme belegbar unverändert ist.

In der Praxis wird eine Altsystemarchivierung regelmäßig mit drei anderen Vorgehensweisen verwechselt. Die Unterschiede entscheiden darüber, ob das Altsystem am Ende wirklich abgeschaltet werden kann.

Die dritte Zeile ist der häufigste Stolperstein. Migrationsprojekte übernehmen typischerweise Stammdaten und offene Vorgänge, nicht aber die abgeschlossene Historie. Genau die Historie ist es, die unter der Aufbewahrungspflicht steht. Deshalb bleibt das Altsystem nach vielen erfolgreichen Migrationen trotzdem an.

Wer noch vor der Entscheidung steht, ob ein System abgelöst wird, findet die Bewertungsgrundlage in unserem Beitrag zu Legacy-Systemen und ihrer Ablösung. Dieser Artikel setzt die Entscheidung voraus und behandelt die Umsetzung der Archivierung.

Was gehört aus einem Altsystem ins Archiv?

Der zweite Bestandteil ist der, der am häufigsten fehlt. Nutzdaten ohne Datenmodell sind eine Sammlung von Spalten mit kryptischen Namen. Ein Feld namens STAT mit den Werten 1 bis 7 ist ohne Wertetabelle wertlos, und die Wertetabelle steckt im Altsystem, nicht in den Daten. Wer sie nicht mitextrahiert, hat ein Archiv, das formal vollständig und fachlich unlesbar ist.

Das OAIS-Referenzmodell nach ISO 14721 beschreibt diesen Zusammenhang mit drei Paketarten, deren Unterscheidung im Projekt hilft. Das Übergabepaket enthält, was aus dem Altsystem herauskommt. Das Archivpaket enthält, was dauerhaft aufbewahrt wird, einschließlich der beschreibenden Information. Das Auslieferungspaket enthält, was ein Nutzer oder ein Prüfer später tatsächlich bekommt. Ein Projekt, das nur das erste Paket plant, produziert ein Archiv, aus dem später niemand etwas herausbekommt.

Ein Archiv wird nicht daran gemessen, wie gut die Daten hineingekommen sind, sondern daran, wie gut sie in acht Jahren wieder herauskommen.

Welche Datenquellen im Altsystem regelmäßig vergessen werden

Die Extraktion bei einer Altsystemarchivierung konzentriert sich meist auf die Hauptdatenbank. Ein Altsystem hält seine Inhalte aber selten nur dort. Die folgenden Quellen fehlen in Archivprojekten am häufigsten, und jede einzelne kann den Vollständigkeitsnachweis kippen.

Binärdaten außerhalb der Datenbank. Prüfberichte, Messkurven, Zeichnungen und Fotos liegen häufig als Dateien im Dateisystem, verknüpft über einen Pfad in der Datenbank. Wird nur die Datenbank extrahiert, enthält das Archiv Verweise auf Dateien, die es nicht mehr gibt.

Historientabellen und Änderungsprotokolle. Viele Anwendungen führen Änderungen in separaten Schattentabellen. Diese Tabellen tragen den Audit Trail und damit den Nachweis der Unveränderbarkeit. Sie werden übersehen, weil sie in der Oberfläche nicht vorkommen.

Stammdatenhistorie. Die aktuelle Lieferantenadresse steht in der Stammdatentabelle. Die Adresse, die zum Zeitpunkt der Lieferung von 2014 gültig war, steht in einer Versionstabelle oder gar nicht. Ohne Stammdatenhistorie lässt sich ein alter Vorgang nicht mehr korrekt rekonstruieren.

Berechtigungs- und Benutzerstand. Wer durfte 2016 eine Prüfung freigeben? Diese Frage entscheidet im Streitfall über die Beweiskraft einer Freigabe. Die Antwort steht im Benutzer- und Rollenmodell, das mit dem System verschwindet.

Individuelle Felder und Nachbauten. Über Jahre entstehen Zusatzfelder, Freitextfelder mit fachlicher Bedeutung und kleine Nebenanwendungen auf derselben Datenbank. Sie sind in keiner Herstellerdokumentation beschrieben und nur durch Befragung der Fachbereiche zu finden.

Bestände auf Altmedien. Bandarchive, alte Exportdateien und ausgelagerte Jahresbestände gehören fachlich zum Altsystem, liegen aber physisch außerhalb. Sie fallen bei der Systemabschaltung nicht auf und tauchen erst in einer Prüfung wieder auf.

Formatentscheidung: in welchem Format Altdaten prüfbar bleiben

Für die Altsystemarchivierung gibt es kein gesetzlich vorgeschriebenes Archivformat. Es gibt aber eine gesetzliche Anforderung an das Ergebnis. § 147 Abs. 2 AO verlangt, dass aufbewahrungspflichtige Unterlagen während der gesamten Frist jederzeit verfügbar und maschinell auswertbar sind. Die GoBD in der Fassung des BMF-Schreibens vom 28. November 2019 konkretisieren das und ergänzen Nachvollziehbarkeit und Unveränderbarkeit.

Daraus folgt eine harte Aussage über den beliebtesten Abkürzungsweg: Der Ausdruck aller Auswertungen als PDF erfüllt die Verfügbarkeit und verfehlt die Auswertbarkeit. Aus einem PDF-Bestand lässt sich nicht nach einem Merkmal filtern, nicht über Jahre aggregieren und keine Charge über mehrere Tabellen hinweg verfolgen. Für unstrukturierte Dokumente ist das Format richtig, für strukturierte Daten ist es ein Verlust.

Die dritte Zeile verdient Aufmerksamkeit, weil sie die häufigste Realität beschreibt. Ein proprietäres Archivformat ist nicht per se ein Problem, solange ein dokumentierter Export in ein offenes Format vertraglich zugesichert und einmal praktisch getestet ist. Ohne diesen Test hat man das Abhängigkeitsproblem des Altsystems lediglich auf einen neuen Anbieter verschoben. Welche Kriterien bei der Produktauswahl darüber hinaus gelten, ist in Revisionssichere Archivierung: Software richtig auswählen beschrieben.

Wie Sie die Vollständigkeit des Archivs belegen

Dies ist der Abschnitt, an dem eine Altsystemarchivierung in der Betriebsprüfung steht oder fällt. Die Frage lautet nicht, ob die Übernahme funktioniert hat, sondern ob Sie es belegen können. Vier Nachweisarten haben sich bewährt, und sie ergänzen sich, weil jede eine andere Fehlerklasse aufdeckt.

Die vierte Zeile ist die, die am häufigsten weggelassen und am dringendsten gebraucht wird. Mengen-, Summen- und Prüfsummenabgleich sind technische Nachweise. Sie belegen, dass die Bits angekommen sind. Sie belegen nicht, dass ein Sachbearbeiter aus dem Archiv heraus einen Vorgang von 2015 noch verstehen kann. Genau das prüft die fachliche Stichprobe, und genau das fragt ein Prüfer.

Praktisch sinnvoll ist eine Stichprobe von zehn bis zwanzig Vorgängen, ausgewählt nach Fallschwere statt nach Zufall: der komplexeste Vorgang, der älteste Vorgang, ein Vorgang mit Nachträgen, ein storniertes Geschäft, ein Vorgang mit Dateianhang. Wenn diese fünf Muster im Archiv nachvollziehbar sind, sind es die einfachen Fälle ohnehin.

Alle vier Nachweise gehören anschließend nicht in ein Projektlaufwerk, sondern in das Archiv selbst. Sie sind Teil der Aufbewahrung, weil sie in acht Jahren die einzige Antwort auf die Frage nach der Vollständigkeit sind. Warum eine Sicherung diese Nachweisfunktion nicht übernehmen kann, ist im Vergleich von Backup und Archivierung beschrieben.

Die Verfahrensdokumentation zur Systemstilllegung

Die GoBD verlangen eine Verfahrensdokumentation für steuerlich relevante Prozesse. Bei einer Altsystemarchivierung ist sie der Abschluss des Projekts und nicht sein Nebenprodukt. Bei einer Systemstilllegung ist sie das Dokument, das die Lücke zwischen dem alten und dem neuen Zustand schließt. Ohne sie steht in acht Jahren die Frage im Raum, warum es zu einem bestimmten Zeitpunkt keine Daten mehr im Altsystem gibt und ob dort etwas verschwunden ist.

Sechs Angaben gehören mindestens hinein:

1. Beschreibung des stillgelegten Systems mit Version, Betriebszeitraum und fachlichem Umfang.
2. Abgrenzung des übernommenen Datenbestands mit Begründung, welche Bereiche nicht übernommen wurden und warum.
3. Beschreibung des Extraktions- und Transformationsverfahrens einschließlich aller Umformatierungen.
4. Die vier Vollständigkeitsnachweise mit Datum und verantwortlicher Person.
5. Beschreibung des Archivzugriffs: wer greift wie zu, in welcher Form erfolgt eine Datenträgerüberlassung.
6. Datum und Freigabe der Abschaltung, mit Nennung der Entscheidungsträger.

Diese Dokumentation entsteht während des Projekts, nicht danach. Wer sie nachträglich schreibt, rekonstruiert Entscheidungen aus dem Gedächtnis und produziert genau die Unsicherheit, die sie beseitigen soll. Die detaillierten Anforderungen an eine prüfungsfeste Dokumentation sind im Beitrag zur GoBD-konformen Archivierung aufgeschlüsselt.

Wie das Archiv nach der Stilllegung genutzt wird

Eine Altsystemarchivierung, deren Ergebnis niemand nutzen kann, ist ein teurer Datenfriedhof. Die vier realen Zugriffsanlässe unterscheiden sich stark in Frist und Anspruch, und die Architektur muss allen vier genügen.

Die Betriebsprüfung. Nach § 147 Abs. 6 AO kann die Finanzverwaltung in drei Formen zugreifen: unmittelbarer Lesezugriff auf das System, mittelbarer Zugriff über Auswertungen, die das Unternehmen durchführt, oder Überlassung der Daten auf einem Datenträger. Bei stillgelegten Systemen ist die dritte Form die praktisch relevante. Das Archiv muss also einen strukturierten Export mit dokumentiertem Schema liefern, nicht nur eine Bildschirmmaske.

Die Reklamation. Hier zählt Geschwindigkeit. Gefragt ist der betroffene Umfang: welche Chargen, welcher Zeitraum, welche Prüfergebnisse. Ein Archiv, das nur einzelne Vorgänge anzeigen kann, aber keine Mengenabfrage über Jahre erlaubt, verfehlt diesen Anlass.

Die Auskunftsanfrage nach Art. 15 DSGVO. Die Frist beträgt nach Art. 12 Abs. 3 DSGVO einen Monat. Auskunftsfähig zu sein bedeutet, alle Datensätze zu einer Person über den gesamten Altbestand hinweg finden zu können. Dafür braucht das Archiv einen personenbezogenen Suchpfad, der bei der Übernahme angelegt werden muss.

Die fachliche Recherche. Ein Konstrukteur sucht die Prozessparameter eines Bauteils, das seit 2018 nicht mehr gefertigt wird. Dieser Anlass ist der häufigste und der am schlechtesten geplante, weil er nicht compliancegetrieben ist. Passende Rollenmodelle beschreibt der Beitrag Archivzugriff ohne IT-Ticket.

Was mit personenbezogenen Daten im Altbestand passiert

Ein Altsystem in der Fertigung enthält vor der Altsystemarchivierung mehr Personenbezug, als die Systembeschreibung vermuten lässt: Bedienerkennungen in Maschinenprotokollen, Prüferkürzel an Freigaben, Benutzerkonten mit Klarnamen, Ansprechpartner in Lieferantendaten, Zeitstempel mit Schichtzuordnung.

Vor der Altsystemarchivierung stellen sich deshalb zwei Fragen in dieser Reihenfolge. Die erste: Welcher Teil des Altbestands muss überhaupt übernommen werden? Nach Art. 5 Abs. 1 lit. e DSGVO ist die Speicherung auf das erforderliche Maß begrenzt. Ein Bestand, dessen Frist 2019 abgelaufen ist, gehört nicht in ein neues Archiv, sondern gelöscht. Diese Fristprüfung ist gleichzeitig der wirksamste Hebel für das Archivvolumen.

Die zweite Frage betrifft die Datensätze, die bleiben müssen: Wie wird der Personenbezug behandelt, wenn die Aufbewahrungspflicht länger läuft als der Verarbeitungszweck? Der praktikable Weg ist die Anonymisierung einzelner Felder innerhalb weiterhin aufbewahrter Datensätze, sodass der Vorgang für Produkthaftung und Steuerrecht vollständig bleibt, während die Personenzuordnung entfällt. Das setzt ein Archiv mit fachlichem Datenmodell voraus, denn auf Dateiebene ist diese Operation nicht möglich. Der strukturelle Rahmen dafür ist im Löschkonzept für Produktionsbetriebe beschrieben, die zugehörigen Fristen in der Übersicht der gesetzlichen Aufbewahrungspflichten.

Ein Hinweis zur Reihenfolge: Beide Schritte gehören vor die Übernahme. Nach der Archivierung ist die Fristprüfung ein zweites Projekt, und die Pseudonymisierung eines bereits versiegelten Bestands ist deutlich aufwändiger als die eines noch beweglichen.

Wo Altsystemarchivierung in der Praxis scheitert

Das zweite Fehlerbild ist das teuerste einer Altsystemarchivierung, weil es unauffällig auftritt. Die Archivierung ist abgeschlossen, die Nachweise liegen vor, und trotzdem bleibt das Altsystem an, weil niemand die Verantwortung für die Abschaltung übernimmt. Wirksam ist eine Gegenmaßnahme, die im Projektplan steht: ein festes Abschaltdatum, das mit der Abnahme der Vollständigkeitsnachweise verbunden ist, und eine benannte Person, die es freigibt. Wie diese Freigabe in einen Stilllegungsablauf eingebettet wird, beschreibt der Beitrag zum Abschalten von Legacy-Systemen in der Fertigung.

Die wirtschaftliche Seite des Weiterbetriebs, insbesondere die Lizenzkosten ruhender Datenbankinstanzen, ist im Beitrag zu Datenbanklizenzen und IT-Kosten in der Fertigungsindustrie aufgeschlüsselt.

Wie das Manufacturing OS Altsystemarchivierung umsetzt

Das Manufacturing OS von CSP verbindet Prozessdatenmanagement, Werkerführung, Prüfung und revisionssichere Archivierung in einer Plattform. Für die Altsystemarchivierung ist die Archivierungskomponente CHRONOS die tragende Einheit.

Bezogen auf die hier beschriebenen Anforderungen an eine Altsystemarchivierung deckt sie die Punkte ab, an denen ein reiner Speicher nicht ausreicht. Die Übernahme erfolgt datenbankübergreifend und herstellerneutral, sodass auch abgekündigte Datenbankversionen als Quelle dienen können. Das Datenmodell der Quelle wird mit übernommen, sodass Feldbedeutungen und Beziehungen im Archiv erhalten bleiben. Die Archivierung erfolgt in einem offenen, dokumentierten Format nach dem OAIS-Referenzmodell, wodurch die maschinelle Auswertbarkeit nach § 147 Abs. 2 AO nicht von der Verfügbarkeit einer bestimmten Software abhängt. Fristen werden pro Datenklasse gesteuert, und einzelne Datensätze lassen sich selektiv löschen oder in einzelnen Feldern anonymisieren, ohne den übrigen Bestand zu berühren.

Ein praktisches Beispiel aus der Medizintechnik beschreibt die Success Story zur Sicherung von Applikationsdaten bei der KLS Martin Group. Den größeren Zusammenhang der Systemstilllegung behandelt der Beitrag zu Application Retirement.

Eine ehrliche Einordnung gehört dazu: Die Abgrenzung des Datenbestands, die Fristzuordnung und die fachliche Stichprobe bleiben Aufgaben des Unternehmens. Software kann die Übernahme leisten und die Nachweise erzeugen, sie kann aber nicht entscheiden, welcher Bestand fachlich vollständig ist. Details zur Archivkomponente finden sich auf der Seite zur revisionssicheren Datenarchivierung mit CHRONOS.

Vorgehen in sieben Schritten

Die Schritte zwei und drei werden bei einer Altsystemarchivierung gern zusammen mit der Übernahme geplant und sind dort falsch platziert. Beide reduzieren den Umfang, und jede Reduktion vor der Extraktion senkt Aufwand, Volumen und Risiko gleichzeitig. Wer erst überträgt und dann aussortiert, macht die Arbeit zweimal.

Schritt vier wird häufig als Formalie behandelt. Er ist der einzige Punkt im Ablauf, der verhindert, dass am Ende eines Projekts gegen Anbieterabhängigkeit eine neue Anbieterabhängigkeit steht.

Fazit

Altsystemarchivierung ist kein Speicherproblem, sondern ein Nachweisproblem. Die Daten aus einem Altsystem herauszubekommen ist der technisch einfachere Teil. Belegen zu können, dass sie vollständig, unverändert und fachlich verständlich vorliegen, ist der Teil, der über die Abschaltung entscheidet.

Die beiden Bedingungen einer belastbaren Altsystemarchivierung lassen sich in einem Satz zusammenfassen. Das Archiv muss ohne die Ursprungssoftware auswertbar sein, und seine Vollständigkeit muss technisch und fachlich belegt sein. Sind beide erfüllt, ist die Abschaltung eine Entscheidung. Fehlt eine, bleibt sie ein Risiko, und das Altsystem läuft weiter.

Der wichtigste einzelne Schritt einer Altsystemarchivierung ist deshalb nicht die Extraktion, sondern die fachliche Stichprobe. Sie ist der einzige Nachweis, der die Frage beantwortet, die in acht Jahren wirklich gestellt wird: Findet ein Mensch in diesem Archiv den Vorgang wieder, den er sucht?

Häufige Fragen

Was ist Altsystemarchivierung?

Altsystemarchivierung ist die strukturierte Übernahme der Daten einer abzulösenden Anwendung in ein revisionssicheres Archiv, das die Daten unabhängig von der Ursprungssoftware lesbar, auswertbar und nachweisbar hält. Ziel ist nicht die Sicherung eines Systemzustands, sondern die dauerhafte Verfügbarkeit der Geschäftsinhalte über die gesetzliche Aufbewahrungsfrist hinweg. Der Unterschied zur Migration liegt darin, dass die Daten nicht in ein Nachfolgesystem übernommen, sondern in eine systemneutrale Archivform gebracht werden.

Was ist der Unterschied zwischen Altsystemarchivierung und einem Backup?

Ein Backup sichert einen Systemzustand, um ihn im Fehlerfall wiederherzustellen. Es ist an die Software, die Datenbankversion und teilweise an die Hardware gebunden und wird nach seinem Aufbewahrungszyklus überschrieben. Eine Altsystemarchivierung überführt die Geschäftsinhalte in ein systemunabhängiges Format mit eigenem Datenmodell, Metadaten und Protokollen. Ein Backup einer abgeschalteten Anwendung ist nach wenigen Jahren praktisch nicht mehr auswertbar, weil die zugehörige Laufzeitumgebung fehlt.

Kann ich ein Altsystem nach der Archivierung abschalten?

Ja, sofern das Archiv nachweislich vollständig ist und die Auswertbarkeit ohne die Ursprungssoftware sichergestellt ist. Beides muss belegt werden: die Vollständigkeit über einen dokumentierten Abgleich von Satzzahlen und Prüfsummen, die Auswertbarkeit über einen praktischen Zugriffstest auf dem Archiv. Erst mit diesen beiden Nachweisen und der zugehörigen Verfahrensdokumentation ist die Stilllegung gegenüber einer Betriebsprüfung vertretbar.

In welchem Format müssen archivierte Altdaten vorliegen?

Ein gesetzlich vorgeschriebenes Format existiert nicht. § 147 Abs. 2 AO verlangt aber, dass die Unterlagen während der gesamten Aufbewahrungsfrist jederzeit verfügbar und maschinell auswertbar sind. Ein reiner Dokumentenstapel aus PDF-Dateien erfüllt die Verfügbarkeit und verfehlt die Auswertbarkeit, weil sich strukturierte Daten daraus nicht mehr filtern, sortieren oder verknüpfen lassen. Praxistauglich sind offene, dokumentierte Strukturformate mit erhaltenem Datenmodell, orientiert am OAIS-Referenzmodell nach ISO 14721.

Welche Zugriffsrechte hat die Finanzverwaltung auf ein Archiv?

Nach § 147 Abs. 6 AO kann die Finanzverwaltung auf steuerlich relevante Daten in drei Formen zugreifen: unmittelbarer Lesezugriff auf das System, mittelbarer Zugriff über Auswertungen, die das Unternehmen durchführt, oder Überlassung der Daten auf einem Datenträger. In der Praxis ist die dritte Variante bei stillgelegten Systemen die relevante. Das Archiv muss deshalb einen strukturierten Datenexport mit dokumentiertem Schema liefern können, nicht nur eine Bildschirmansicht.

Müssen personenbezogene Daten aus einem Altbestand gelöscht werden?

Ja, sobald der Verarbeitungszweck entfallen ist und keine Aufbewahrungspflicht entgegensteht. Nach Art. 5 Abs. 1 lit. e DSGVO ist die Speicherung auf das erforderliche Maß begrenzt. Ein Altbestand enthält häufig Datensätze, deren Frist längst abgelaufen ist. Vor der Archivierung lohnt daher eine Fristprüfung, denn nicht mehr benötigte Daten in ein neues Archiv zu übernehmen verlängert ein bestehendes Risiko statt es zu beenden. Wo Aufbewahrungspflicht und Löschpflicht auf demselben Datensatz liegen, ist die Anonymisierung einzelner Felder der Weg.

Wie lange muss ein Archiv aus einem stillgelegten System vorgehalten werden?

Die Dauer richtet sich nicht nach dem System, sondern nach dem Inhalt. Für Handelsbücher und Buchungsbelege gilt nach § 257 Abs. 4 HGB und § 147 Abs. 3 AO eine Frist von zehn Jahren. VDA Band 1 empfiehlt für Dokumentation zu Produkten mit besonderen Merkmalen eine Archivierungsdauer von 15 Jahren. Der Haftungszeitraum der EU-Produkthaftungsrichtlinie (EU) 2024/2853 kann darüber hinausreichen. Maßgeblich ist immer die längste Frist, die auf einen der enthaltenen Datenbestände zutrifft.