Legacy-Daten als AI Asset: Warum alte SAP-Daten nicht in alten ERP-Systemen gefangen sein sollten

Autor: Audren Butery, SAP Consultant bei TJC Group

Historische SAP-Daten können Finanzreporting, Steuerprüfungen, Langzeitanalysen und zukünftige AI Use Cases unterstützen. Wertvolle Daten zu behalten bedeutet jedoch nicht, dass Organisationen die veralteten Systeme, in denen sie liegen, weiter betreiben müssen. Eine strukturierte Strategie zur System-Außerbetriebnahme kann Business-Kontext und kontrollierten Zugriff erhalten und gleichzeitig Kosten, Sicherheitsrisiken und technische Komplexität reduzieren.

Einführung

Wenn eine Organisation von SAP ECC auf S/4HANA umstellt, mehrere ERP-Plattformen konsolidiert oder eine alte Business-Anwendung ersetzt, muss sie dennoch entscheiden, was mit den zurückbleibenden Informationen passiert.

Das Originalsystem im Read-only-Modus verfügbar zu halten, wirkt möglicherweise wie die günstigste und einfachste Option. Es birgt jedoch erhebliche Sicherheitsbedrohungen und Compliance-Risiken.

Durch Legacy-System-Decommissioning können Organisationen die historischen Daten, Dokumente, Reports und den Business-Kontext erhalten, den sie weiterhin benötigen – und gleichzeitig die Technologie stilllegen, die sie erzeugt hat.

Ziel ist es, Informationen mit einem validen Reporting-, Compliance- oder Analysezweck zu behalten, ohne die komplette Legacy-Umgebung auf unbestimmte Zeit weiter zu betreiben.

Warum Legacy-SAP-Daten weiterhin geschäftlichen Wert haben können

Daten verlieren ihren Wert nicht automatisch, wenn ein System ersetzt wird. Datensätze aus SAP-Systemen wie ECC oder S/4HANA sowie aus anderen stillgelegten SAP- und Non-SAP-Anwendungen können Geschäftsentscheidungen noch lange unterstützen, nachdem die täglichen Transaktionen anderswo stattfinden.

Der Wert fällt in der Regel in drei Bereiche:

Die passende Aufbewahrungsdauer, Zugriffsmethode und Detailtiefe unterscheiden sich je Kategorie.

Historisches Reporting und Trendanalyse

Operative Reports fokussieren sich meist auf den aktuellen Zeitraum. Strategische Analysen brauchen oft einen längeren Blick.

Finance-Teams vergleichen möglicherweise Margen, Working Capital, Closing-Aktivitäten oder Zahlungsverhalten über mehrere Jahre. Procurement-Teams bewerten Lieferantenzuverlässigkeit über mehrere Konjunkturzyklen. Operations-Teams analysieren Produktions-, Bestands- und Wartungsmuster vor und nach einer größeren Veränderung.

Ältere Reports können besonders wertvoll werden – etwa nach einer Fusion, Restrukturierung oder S/4HANA-Migration –, wenn das aktuelle Reporting nicht mehr jeden Zeitraum oder jede juristische Einheit umfasst.

Zum Beispiel kann in einem S/4HANA-Programm ein Teil der Business-Daten transformiert und in die neue Umgebung geladen werden, während ältere Informationen im Legacy-System verbleiben oder für einen gesteuerten Langzeitzugriff extrahiert werden. Da Migration häufig einen ETL-Prozess umfasst, bilden die in S/4HANA genutzten Daten die ursprüngliche Quelle möglicherweise nicht mehr exakt ab. Für Audit, Reconciliation oder spätere Referenzen benötigen Organisationen möglicherweise weiterhin eine originalgetreue Extraktion aus dem ursprünglichen ECC-System – zusammen mit den Dokumenten, Beziehungen und dem Kontext, die zum Verständnis erforderlich sind.

Die Daten müssen nicht im ursprünglichen ERP verbleiben, um diese Aufgaben zu unterstützen. Sie brauchen jedoch ausreichend Kontext, damit Nutzer verstehen, was die Zahlen bedeuten.

Audit-, Steuer- und Compliance-Anforderungen

Historische Informationen müssen möglicherweise auch für Steuerbehörden, gesetzliche Audits, regulatorische Prüfungen, Rechtsstreitigkeiten oder interne Untersuchungen verfügbar bleiben.

Die Anforderung ist selten auf eine einzelne Tabelle oder einen Buchhaltungssaldo beschränkt. Auditoren benötigen möglicherweise die Transaktion, das zugehörige Dokument, die Freigabe-Historie, relevante Stammdaten und Nachweise darüber, wie die Informationen aufbewahrt oder später gelöscht wurden.

Aufbewahrungsanforderungen können je Land, juristischer Einheit, Dokumenttyp und Branche variieren. Datenschutzregeln können außerdem verlangen, dass personenbezogene Daten gesperrt oder gelöscht werden, sobald ihr rechtmäßiger Zweck endet.

Organisationen müssen daher Erhalt und kontrollierte Löschung ausbalancieren.

Informationen sollten verfügbar bleiben, solange eine gültige rechtliche, steuerliche oder geschäftliche Verpflichtung besteht. Sobald dieser Zweck endet, müssen Daten gelöscht werden, um Datenschutzgesetze einzuhalten. Data Masking kann die Sichtbarkeit begrenzen, ersetzt aber keine Löschung, da es nicht-destruktiv ist. Legacy-Access-Umgebungen benötigen daher Data-Privacy-Mechanismen, die eine kontrollierte Löschung unterstützen, wenn Informationen das Ende ihrer Aufbewahrungsfrist erreicht haben oder keinen gültigen Zweck mehr haben.

SAP ILM- und DSGVO-Kontrollen können Aufbewahrung, Sperrung, Legal Holds und kontrollierte Vernichtung unterstützen. Gleichwertige Kontrollen müssen auch nach Stilllegung des Quellsystems wirksam bleiben.

Potenzielle Nutzung in Analytics und AI-Modellen

Historische ERP-Daten können zeigen, wie sich das Unternehmen unter unterschiedlichen Bedingungen verhalten hat.

Je nach Use Case können sie Analysen zum Zahlungsverhalten von Kunden, zur Zuverlässigkeit von Lieferanten, zu Nachfragemustern, Geräteausfällen oder finanziellen Ausnahmen unterstützen.

Mehrjährige Informationen können Muster sichtbar machen, die im aktuellen ERP allein nicht erscheinen. Sie können Organisationen auch helfen, Ergebnisse über unterschiedliche Marktbedingungen, Organisationsstrukturen oder Business-Policies hinweg zu vergleichen.

Diese Historie zu erhalten, hält zukünftige Analyseoptionen offen. Ob die Informationen für einen konkreten AI Use Case geeignet sind, sollte separat bewertet werden.

Historische Daten enthalten wertvolle Insights für Forecasting, Supply Chain und Kundentrends. Eine saubere Kuratierung versorgt predictive und generative AI-Modelle effektiv.

Warum wertvolle Daten oft in Legacy-Systemen gefangen bleiben

Viele Organisationen behalten alte Anwendungen, weil Nutzer gelegentlich noch Zugriff auf deren Daten benötigen.

Ein Finance-Team braucht vielleicht eine Rechnung von vor acht Jahren. Ein Tax-Team benötigt Unterlagen einer geschlossenen juristischen Einheit. Ein Auditor fragt nach dem Originalreport hinter einem historischen Saldo. Ein Customer-Service-Team braucht eine Transaktion aus einem stillgelegten regionalen ERP.

Die Organisation versetzt das System daher in den Read-only-Modus und verschiebt die Stilllegung.

Das ist Sunsetting statt vollständigem Decommissioning. Sunsetting hält die Anwendung verfügbar, während Decommissioning die benötigten Informationen anderweitig erhält und die ursprüngliche Anwendung stilllegt.

Daten bleiben oft gefangen, weil Reports weiterhin von der ursprünglichen Anwendungslogik abhängen oder weil Dokumente getrennt von den zugrunde liegenden Transaktionen gespeichert sind. Custom Tables sind möglicherweise schlecht dokumentiert, Interfaces wurden nicht gemappt, und Nutzer sind unsicher, welche historischen Datensätze sie später benötigen.

Der Organisation fehlt möglicherweise auch eine alternative Plattform, die Transaktionen, Dokumente, Reports und Beziehungen in einer Form erhalten kann, die Business-Nutzer und Auditoren verstehen.

Diese Punkte sollten die Informations- und Validierungsanforderungen des Decommissioning-Projekts definieren. Sie rechtfertigen nicht zwingend, die komplette Anwendung weiter zu betreiben.

Kosten und Risiko, alte Systeme weiter zu betreiben

Ein Read-only-Legacy-System verarbeitet zwar keine neuen Transaktionen mehr, erfordert aber weiterhin laufendes Management.

Das Unternehmen zahlt weiter für eine Anwendung, deren Hauptzweck die gelegentliche historische Recherche ist.

Mit der Zeit wird die Umgebung schwerer zu unterstützen, während das Niveau der nützlichen Business-Aktivität weiter sinkt.

Infrastruktur-, Lizenz- und Wartungskosten

Legacy-Anwendungen können von veralteter Hardware, nicht unterstützten Datenbankversionen, alten Betriebssystemen oder dedizierten Hosting-Arrangements abhängen.

Die Verlagerung des Systems in eine Cloud-Infrastruktur beseitigt die Kosten nicht. Die Organisation zahlt möglicherweise weiterhin für Rechenkapazität, Storage, Backups, Monitoring, Softwarelizenzen, Spezialistensupport, Interfaces und Disaster-Recovery-Arrangements. Einige Komponenten erhalten möglicherweise keine regelmäßigen Patches oder Vendor-Updates mehr, wodurch die Cybersecurity-Exposure im Laufe der Zeit steigt.

Diese Ausgaben sind oft über mehrere Budgets verteilt, was die Gesamtkosten der Beibehaltung der Anwendung verschleiern kann.

Die finanziellen Auswirkungen der Beibehaltung von Legacy-Systemen sollten daher auf Portfolio-Ebene bewertet werden. Eine Organisation kann Dutzende stillgelegter oder halb stillgelegter Anwendungen haben, die jeweils Geld und technische Aufmerksamkeit binden.

Zusammen können sie Ressourcen von S/4HANA-, SAP BTP-, Analytics-, Security- und AI-Programmen abziehen.

Sicherheits- und Zugriffskontrollrisiken

Ältere Systeme unterstützen möglicherweise nicht die aktuellen Standards der Organisation für Identity, Authentifizierung, Verschlüsselung oder Monitoring.

So können Legacy-SAP-User-Accounts außerhalb des aktuellen Identity Providers liegen, während breit angelegte Display-Rollen, die vor Jahren erstellt wurden, möglicherweise nicht mehr in moderne Access-Review-Prozesse einbezogen werden.

Nicht unterstützte Komponenten können Patching zudem erschweren. Security-Teams müssen möglicherweise zwischen Änderungen an einem instabilen System und dem Belassen einer bekannten Schwachstelle wählen.

Die Verlagerung historischer Informationen in eine unterstützte Access-Umgebung kann diese Exposure reduzieren, indem aktuelle Kontrollen für Authentifizierung, Logging, Autorisierung und Datenschutz angewendet werden.

Ziel ist nicht, einfach die Datenbank zu kopieren. Es geht darum, die aufbewahrten Informationen unter ein nachhaltigeres Sicherheitsmodell zu stellen.

Compliance-Herausforderungen in nicht unterstützten Systemen

Compliance wird schwieriger, wenn historische Informationen über mehrere Legacy-Anwendungen verteilt sind.

Jedes System kann unterschiedliche Aufbewahrungsregeln, Vernichtungsprozesse, Zugriffsmodelle und Audit-Mechanismen nutzen. Einige Datensätze können personenbezogene Informationen enthalten, die irgendwann gesperrt oder gelöscht werden sollten, während andere weiterhin Legal Holds unterliegen.

Eine nicht unterstützte Anwendung kann den Originaldatensatz bewahren, aber die Kontrollen fehlen, um ihn über den restlichen Lebenszyklus zu steuern. Viele Legacy-Anwendungen wurden entwickelt, bevor moderne Datenschutzanforderungen existierten; daher enthalten sie möglicherweise keine verlässlichen Mechanismen für Privacy Review, kontrollierte Löschung, Evidence Capture oder autorisierte Data-Removal-Workflows.

So unterstützt die Anwendung möglicherweise nicht die kontrollierte Vernichtung eines abgelaufenen Kundendatensatzes, ohne zugehörige Dokumente oder buchhalterische Nachweise zu beeinflussen. Dadurch entsteht eine Compliance-Lücke: Die Organisation ist für die Anwendung von Privacy Rules verantwortlich, aber das alte System bietet möglicherweise nicht die Funktionen, um sie sicher umzusetzen.

Decommissioning bietet die Chance, Legacy-Informationen unter einem stärker kontrollierten Zugriffsmodell zu verwalten. Das kann Retrieval, Access Reviews, Privacy Checks und Audit-Support vereinfachen. Privacy- und Löschregeln müssen jedoch weiterhin je nach Quellsystem, Datentyp und Aufbewahrungsanforderung bewertet und angewendet werden – statt anzunehmen, dass eine einzige Policy automatisch für jedes stillgelegte System gilt.

Was Legacy-Daten brauchen, bevor sie AI unterstützen können

Historische Daten sind nicht automatisch für Analytics oder AI geeignet, aber sie sind auch nicht immer direkt in ihrer rohen Legacy-System-Form nutzbar. Manche Daten sind schwer zu extrahieren, in Strukturen gespeichert, die nicht für moderne Analysen ausgelegt sind, oder in Formaten wie geclusterten, verschlüsselten oder Custom Tables abgelegt. Bevor sie AI unterstützen können, müssen die Daten mit Kontext extrahiert, auf Qualität geprüft und für den vorgesehenen Use Case vorbereitet werden.

Für Enterprise-Use-Cases müssen sie verständlich, konsistent, nachvollziehbar und unter definierten Berechtigungen verfügbar bleiben.

Das ist besonders wichtig bei SAP-Daten, weil die Business-Bedeutung oft über Transaktionen, Stammdaten, Customizing, Custom Fields, Organisationsstrukturen und unterstützende Dokumente verteilt ist.

Business-Kontext und Metadaten

Eine Tabelle historischer Transaktionen hat nur begrenzten Wert, wenn Nutzer nicht erklären können, wofür jedes Feld steht, welcher Buchungskreis den Datensatz erzeugt hat, welche Währung und welcher Fiskalzeitraum gelten oder ob sich Identifikatoren während Fusionen oder Migrationen geändert haben.

Sie müssen möglicherweise auch verstehen, ob das ursprüngliche Ergebnis durch Quellsystem-Konfiguration, Custom Fields, Reports oder Business Rules beeinflusst wurde, wo unterstützende Dokumente gespeichert sind und wie der Datensatz mit anderen Business-Objekten zusammenhängt. Das bedeutet nicht, die ursprüngliche Anwendungslogik in der Decommissioning-Plattform nachzubauen.

Metadaten erhalten diese Bedeutung.

Dazu können Tabellendefinitionen, Feldbeschreibungen, Dokumentbeziehungen, organisatorischer Kontext, Report-Logik, Quellsystem-IDs, Extraktionsdaten, Extraktionslogs und die Rückverfolgbarkeit zum Originalsystem gehören.

Die Erhaltung der Report-Logik verdient besondere Aufmerksamkeit. Ein historischer Finanzreport kann von Wechselkurstabellen, Fiskalkalendern, Konfigurationswerten, Custom Calculations oder Regeln abhängen, die sich im Laufe der Zeit geändert haben. Unterstützende Anhänge können zudem außerhalb der SAP-Datenbank liegen.

Allein das Beibehalten von Transaktionstabellen reicht daher möglicherweise nicht aus, um das ursprüngliche Ergebnis zu reproduzieren.

Betrachten Sie ein Modell, das Zahlungsverzögerungen vorhersagen soll.

• Es kann aktuelle Forderungen aus S/4HANA, historisches Zahlungsverhalten aus ECC, Streitfallinformationen aus einem stillgelegten Customer-Service-System und Kundenattribute aus einer früheren regionalen Anwendung kombinieren.

• Diese Quellen sind nicht austauschbar, solange Kunden-IDs, Währungen, Zahlungsbedingungen, Datumsformate und Business-Definitionen nicht abgeglichen wurden.

• Historische Daten müssen mit dem Kontext verbunden bleiben, der ihnen Bedeutung gibt.

Historische Daten für Analytics und AI vorbereiten

Decommissioning erhält historische Informationen und den Kontext, der nötig ist, um sie nach Stilllegung der Quellanwendung zu nutzen.

Für Analytics oder AI müssen ausgewählte Informationen möglicherweise dennoch gemappt, standardisiert oder für den spezifischen Use Case vorbereitet werden – insbesondere dort, wo sich Business-Strukturen oder Definitionen im Laufe der Zeit verändert haben.

Das mindert den Wert von Decommissioning nicht. Es trennt zwei unterschiedliche Anforderungen: den Erhalt eines verlässlichen Zugriffs auf historische Informationen und die Vorbereitung ausgewählter Daten für einen bestimmten analytischen oder AI-Zweck.

Governance und kontrollierter Zugriff

Historische Daten sollten nicht allein deshalb breiter verfügbar werden, weil sie für AI in Betracht gezogen werden.

User-Autorisierung, zweckgebundener Zugriff, Masking, Aufbewahrung, Löschung, Audit Trails, Data Residency und Vertraulichkeitsanforderungen gelten weiterhin.

Eine Plattform kann historische Datensätze für compliant Retrieval erhalten, während eine separate kontrollierte Pipeline ausgewählte Informationen an SAP Business Data Cloud, einen Data Lake, ein Warehouse oder eine andere Analytics-Plattform liefert.

Diese Zugriffsmuster dienen unterschiedlichen Zwecken:

Das Legacy-Repository und die AI-Plattform müssen nicht dasselbe System sein.

Das Erhalten historischer Informationen in einer Legacy-Access-Umgebung ermöglicht es Organisationen, das aktuelle ERP auf aktive Abläufe zu fokussieren und gleichzeitig Zugriff auf die Daten, Dokumente und Reports zu behalten, die nach der Stilllegung voraussichtlich benötigt werden. Das bedeutet nicht, dass die Plattform als reine Cold-Storage-Schicht für jeden denkbaren zukünftigen Use Case behandelt werden sollte.

Wenn ein späterer Analytics- oder AI-Use-Case freigegeben wird, sollte die Organisation einen separaten Zugriffs- oder Extraktionsprozess aus den aufbewahrten Legacy-Daten definieren. Zweck, Berechtigungen, Data Quality und Aufbewahrungsstatus sollten geprüft werden, bevor diese Informationen außerhalb der Legacy-Access-Umgebung genutzt werden.

Wie man historische Informationen erhält und gleichzeitig das Quellsystem außer Betrieb nimmt

Ein erfolgreiches Decommissioning-Projekt beginnt nicht damit, die Anwendung abzuschalten.

Es beginnt damit, zu identifizieren, welche historischen Informationen Nutzer, Auditoren, Tax-Teams und Business Owner nach Stilllegung des Quellsystems weiterhin benötigen. Dazu können Business-Daten, Dokumente, Attachments, Reports, Quellsystem-Referenzen und ausreichend Kontext gehören, um die aufbewahrten Informationen verständlich zu machen.

Ziel ist nicht, die Legacy-Anwendung in einer neuen Plattform nachzubauen. Es geht darum, Informationen zu erhalten, die weiterhin einen gültigen geschäftlichen, rechtlichen, steuerlichen oder Reporting-Zweck haben – und gleichzeitig das Originalsystem stilllegen zu können.

Aus diesem Grund sollte der Scope vor dem Shutdown abgestimmt werden. Die Organisation sollte bestätigen, welche Daten und Dokumente zugänglich bleiben müssen, wer Zugriff benötigt, wie Retrieval getestet wird und welche Privacy-, Aufbewahrungs- und Legal-Hold-Anforderungen weiterhin gelten.

Sobald dieser Scope klar ist, sind die wichtigsten Phasen Validierung und kontrollierte Stilllegung.

1. Abgestimmte Abstimmung (Reconciliation) und Retrieval-Tests mit Sign-off

Business-Nutzer, Auditoren, Tax-Teams und Data Owner sollten bestätigen, dass die aufbewahrten Informationen vollständig und nutzbar sind.

Tests sollten das Retrieval von Transaktionen, Reports, Dokumenten und Attachments abdecken. Außerdem sollte bestätigt werden, dass Summen mit der Quelle übereinstimmen, User-Rollen wie vorgesehen funktionieren und anwendbare Privacy- oder Legal-Hold-Kontrollen wirksam bleiben.

Wenn historische Reports reproduziert werden müssen, sollte das Testing bestätigen, dass die erforderliche Logik, Konfiguration und unterstützenden Daten erhalten wurden.

Das Quellsystem sollte verfügbar bleiben, bis die relevanten Owner die Ergebnisse freigegeben haben.

2. Stilllegung der Anwendung und kontrollierter zukünftiger Zugriff

Sobald Extraktion, Reconciliation und User-Testing abgeschlossen sind, kann die Organisation die alte Infrastruktur, Lizenzen, Interfaces, Accounts und Support-Prozesse stilllegen.

Historische Informationen können über ein dauerhaftes Legacy-Access-Modell verfügbar bleiben.

Der Stilllegungsplan sollte definieren, wie routinemäßiges historisches Retrieval, Audit-Support, rechtliche Anfragen und freigegebene analytische Extrakte nach dem Shutdown gemanagt werden.

Wie ELSA die Außerbetriebnahme von Legacy-Systemen und den langfristigen Datenzugriff unterstützt

Die Enterprise Legacy System Application, oder ELSA, ist die Lösung der TJC Group für die Außerbetriebnahme von SAP- und Non-SAP-Systemen bei gleichzeitigem Erhalt des Zugriffs auf historische Informationen.

ELSA trennt den Langzeitzugriff von der ursprünglichen Anwendung und kann Business-Daten, Dokumente, Attachments, Reports, Beziehungen, Quellsystem-Kontext und Audit-Informationen aufbewahren.

Autorisierte Nutzer können diese Informationen nach Stilllegung der alten Anwendung suchen, abfragen, reporten und abrufen.

Ein Decommissioning-Projekt mit ELSA kann Source Assessment, Daten- und Dokumentextraktion, Reconciliation, Vorbereitung und Erhalt erforderlicher Reports, Access- und Privacy-Konfiguration, User Acceptance Testing, Application Retirement und Long-term Support umfassen. Wenn historische Reports benötigt werden, sollten sie in der Regel vor oder während des Projekts aus dem Quellsystem erzeugt und für den späteren Zugriff gespeichert werden – statt sie in der Legacy-Access-Plattform nachzubauen.

ELSA kann in der SAP BTP-Umgebung des Kunden oder in der SAP BTP-Umgebung der TJC Group bereitgestellt werden, während der Data Storage im Eigentum des Kunden bleibt. Je nach Architektur des Kunden kann dieser Storage cloud-basiert oder on-premises sein. TJC Group übernimmt nicht die Speicherung von Kundendaten. ELSA ist als „built on SAP BTP“ zertifiziert und im SAP store verfügbar. Seine SAP BTP-Zertifizierung unterstützt seine Rolle in modernen SAP-Landschaften.

ELSA ermöglicht es, dass das aktuelle ERP auf aktive Abläufe fokussiert bleibt, während historische Informationen über ELSA zugänglich bleiben. Wo erforderlich, können freigegebene Anwendungen oder Analytics- und AI-Pipelines über ELSAs API unter definierten Berechtigungen auf ausgewählte Legacy-Daten zugreifen.

Fazit

Die Stilllegung eines SAP-Legacy-Systems muss nicht bedeuten, die darin enthaltenen Informationen zu verlieren. Historische Transaktionen, Dokumente, Reports und Business-Kontext können echten Wert für Reporting, Audits, Steuerpflichten und zukünftige AI Use Cases behalten – lange nachdem die ursprüngliche Anwendung nicht mehr läuft.

Das Risiko liegt darin, diesen Wert in einem alternden, teuren und zunehmend verwundbaren System gefangen zu lassen. Ein strukturierter Decommissioning-Ansatz – basierend auf validierter Extraktion, Reconciliation und gesteuertem Zugriff – ermöglicht es Organisationen, das zu erhalten, was weiterhin zählt, und gleichzeitig das stillzulegen, was nicht mehr laufen muss.

Mit ELSA unterstützt TJC Group Organisationen dabei, diesen Schritt mit Sicherheit zu gehen: nachvollziehbaren, gut gesteuerten Zugriff auf Legacy-Daten zu erhalten und gleichzeitig Infrastrukturkosten, Security Exposure und Compliance-Risiko zu reduzieren – damit historische Informationen bereit bleiben, das Business zu unterstützen, wann und wie auch immer sie als Nächstes gebraucht werden.