7 Min. Lesezeit

Die S/4HANA-Migration dominiert die IT-Agenda. Doch während Unternehmen Milliarden in neue Systeme investieren, bleiben die alten oft einfach stehen. Das kostet Geld, erzeugt Compliance-Risiken und bindet Ressourcen, die anderswo fehlen. Data Decommissioning löst dieses Problem, wird aber in den meisten Migrationsprojekten systematisch vergessen.

Das Wichtigste in Kürze

• Knapp die Hälfte der deutschsprachigen SAP-Nutzer wird die ECC-Systeme über 2027 hinaus weiterbetreiben, obwohl der Mainstream-Support ausläuft (DSAG-Umfrage, Februar 2026).
• Legacy-Wartung verschlingt typischerweise 15 Prozent des IT-Budgets für Systeme, die operativ nicht mehr gebraucht werden.
• Im deutschsprachigen Raum gibt es zu Data Decommissioning praktisch keinen unabhängigen redaktionellen Content. Das Thema ist unterbelichtet, obwohl der Handlungsdruck steigt.
• Moderne Historisierungslösungen ermöglichen den revisionssicheren Zugriff auf Legacy-Daten als SaaS, ohne die Quellsysteme weiterbetreiben zu müssen.

SAP ECC: Der Support läuft aus, die Systeme bleiben

SAP hat die Zeitlinie klar kommuniziert. Für ECC-Releases EHP 0 bis 5 ist der Mainstream-Support bereits Ende 2025 ausgelaufen. EHP 6 bis 8 folgen Ende 2027. Danach bleibt nur Extended Maintenance mit einem Aufpreis von 9 Prozent auf die bisherigen Lizenzkosten.

Die Realität sieht anders aus als die Roadmap. Laut einer DSAG-Umfrage vom Februar 2026 plant knapp die Hälfte der deutschsprachigen SAP-Anwender, ihre ECC-Systeme über 2027 hinaus zu betreiben. Die Gründe sind nachvollziehbar: S/4HANA-Migrationen dauern länger als geplant, kosten mehr als budgetiert und binden die besten Leute im Team.

Was dabei übersehen wird: Selbst Unternehmen, die erfolgreich auf S/4HANA migrieren, lassen die alten Systeme oft einfach weiterlaufen. Der operative Betrieb ist abgeschlossen, aber die historischen Daten müssen zugänglich bleiben. Aufbewahrungsfristen nach GoBD verlangen bis zu zehn Jahre revisionssicheren Zugriff. DSGVO-Löschfristen müssen eingehalten werden. Und bei M&A-Transaktionen können Gewährleistungsansprüche auch Jahre später noch einen Zugriff auf Altdaten erfordern.

Der vergessene Schritt: Was nach dem Go-Live passiert

Eine S/4HANA-Migration besteht aus zwei Hälften. Die erste Hälfte bekommt die Aufmerksamkeit, das Budget und die Projektteams: Datenmigration, Customizing, Testing, Go-Live. Die zweite Hälfte wird vertagt: Was passiert mit den Altsystemen?

In der Praxis bedeutet das: ECC-Instanzen, Navision-Systeme, AS/400-Anwendungen und Mainframe-Applikationen bleiben im Rechenzentrum stehen. Sie verbrauchen Lizenzen, Server-Ressourcen und Admin-Kapazität. Patches müssen eingespielt werden, obwohl kein User mehr produktiv damit arbeitet. Das Know-how für diese Systeme schwindet, während die Kosten konstant bleiben.

IT-Leiter kennen das Problem. Aber es gibt selten ein dediziertes Budget für „Altsysteme abschalten“. Decommissioning taucht in keiner Roadmap auf, weil es kein neues Feature liefert und keinen Business Case auf Folie füllt. Dabei ist die Rechnung einfach: Jeder Euro, der nicht in die Wartung toter Systeme fliesst, steht für Innovation zur Verfügung.

„Data Decommissioning löst dieses Problem, wird aber in den meisten Migrationsprojekten systematisch vergessen.“

Drei typische Szenarien für Data Decommissioning

Data Decommissioning adressiert Situationen, die IT-Abteilungen in DACH regelmäßig treffen. Drei Szenarien aus der Praxis.

Szenario 1: Post-Migration. Ein Unternehmen hat die Transformation zu S/4HANA abgeschlossen und konsolidiert gleichzeitig mehrere Legacy-Systeme. Die operativen Daten der letzten zwei Jahre sind migriert. Aber die historischen Daten aus ECC und Navision müssen weiterhin zugänglich sein, weil Wirtschaftsprüfer, Steuerberater und interne Revision darauf zugreifen. Statt beide Altsysteme weiterzubetreiben, werden die Daten in ein Historisierungssystem überführt. Das Quellsystem wird abgeschaltet.

Szenario 2: M&A-Transaktion. Firma A verkauft einen Geschäftsbereich an Firma B. Die operativen Daten werden migriert, aber beide Seiten müssen weiterhin auf die historischen Daten zugreifen können, unter anderem für Gewährleistungsansprüche und GoBD-Konformität. Eine Systemkopie wäre die teure Lösung. Ein Historisierungstool, das die Daten revisionssicher vorhält und den logischen Zugriff erhält, ist die schlanke Alternative.

Szenario 3: Rechenzentrumsräumung. Die Server müssen zum Jahresende aus dem Rechenzentrum. Auf einer AS/400 und einem Mainframe liegen geschäftskritische historische Daten, die aus regulatorischen Gründen nicht gelöscht werden dürfen. Die Applikationen sind nicht cloud-fähig. Die Lösung: Daten exportieren, in einem cloud-basierten Historisierungstool speichern und die alte Hardware abschalten.

Wie modernes Decommissioning funktioniert

Der Ansatz hat sich in den letzten Jahren verändert. Früherer Standard war die SAP-eigene Archivierung mit ILM oder der Betrieb von Read-Only-Kopien. Beide Ansätze haben Grenzen: ILM ist komplex, erfordert laufende SAP-Lizenzen und deckt nur SAP-Daten ab. Read-Only-Kopien müssen gepatcht und administriert werden.

Moderne Historisierungsplattformen wie Historia von der SDD Group verfolgen einen anderen Ansatz. Die Daten werden aus dem Quellsystem exportiert und in einem cloud-basierten Data Store gespeichert. Der Zugriff erfolgt über eine Web-Applikation, die die Geschäftslogik des ehemaligen Systems nachbildet. Benutzer sehen die Daten in der gewohnten Struktur, obwohl das Quellsystem nicht mehr existiert.

Das Preismodell basiert auf Speichervolumen, nicht auf Userzahlen. Unbegrenzte Nutzer, Single Sign-On, rollenbasierte Zugriffskontrolle. Für IT-Abteilungen bedeutet das: keine laufenden Lizenzkosten für Altsysteme, kein Administrations-Overhead, kein Patch-Management für End-of-Life-Software.

Ein Retention Manager stellt sicher, dass Löschfristen nach DSGVO eingehalten werden und Daten nach Ablauf der Aufbewahrungspflicht automatisch entfernt oder verschleiert werden. In regulierten Branchen wie Finanzdienstleistung und Pharma prüfen Aufsichtsbehörden das aktiv.

Warum das Thema jetzt auf die Agenda gehört

Die Kombination aus auslaufendem SAP-Support, steigenden Cloud-Kosten und verschärften Compliance-Anforderungen erzeugt einen Handlungsdruck, der sich nicht aussitzen lässt. Wer ECC-Systeme über 2027 hinaus im Extended-Maintenance-Modus weiterbetreibt, zahlt 9 Prozent mehr für ein System, das keine neuen Features mehr bekommt.

Gleichzeitig wächst der regulatorische Druck. GoBD-konforme Aufbewahrung, DSGVO-Löschpflichten und branchenspezifische Vorgaben wie DORA im Finanzsektor machen eine strukturierte Datenhistorisierung zur Pflicht. „Einfach weiterlaufen lassen“ ist keine Compliance-Strategie.

Für IT-Leiter und CIOs ist Decommissioning kein glamouröses Thema. Es liefert keine Innovation, keine KI-Features, kein Prestige-Projekt für die nächste Vorstandspräsentation. Aber es setzt Budget frei, reduziert Risiken und vereinfacht die IT-Landschaft. Das sind die Themen, die in zwölf Monaten den Unterschied machen.

Häufige Fragen

Was ist Data Decommissioning?

Data Decommissioning bezeichnet den strukturierten Prozess, Legacy-Systeme abzuschalten und die darin enthaltenen Daten in ein separates Archivierungs- oder Historisierungssystem zu überführen. Ziel ist es, den Zugriff auf historische Daten zu erhalten, ohne das Quellsystem weiterbetreiben zu müssen.

Wie lange dauert ein typisches Decommissioning-Projekt?

Die Implementierung hängt von der Komplexität des Quellsystems und dem Datenvolumen ab. Bei standardisierten SAP-Umgebungen ist ein Projekt in wenigen Wochen umsetzbar. Komplexere Landschaften mit mehreren Legacy-Systemen können drei bis sechs Monate in Anspruch nehmen.

Was kostet es, Legacy-Systeme einfach weiterlaufen zu lassen?

Branchenschätzungen gehen davon aus, dass Legacy-Wartung rund 15 Prozent des IT-Budgets bindet. Dazu kommen indirekte Kosten: Personalaufwand für Administration, Sicherheitsrisiken durch ungepatchte Systeme und Opportunitätskosten durch gebundene Ressourcen.

Ist Data Decommissioning nur für SAP-Systeme relevant?

Nein. Historisierungslösungen wie Historia unterstützen neben SAP auch Non-SAP-Systeme wie Navision, AS/400-Anwendungen, Mainframe-Applikationen und andere Legacy-Datenbanken. Der Ansatz ist systemunabhängig.

Welche Compliance-Anforderungen werden durch Decommissioning adressiert?

Die GoBD verlangt bis zu zehn Jahre revisionssicheren Zugriff auf geschäftsrelevante Daten. Die DSGVO fordert die Löschung personenbezogener Daten nach Ablauf des Verarbeitungszwecks. Branchenspezifische Vorgaben wie DORA im Finanzsektor verschärfen die Anforderungen zusätzlich. Moderne Historisierungsplattformen adressieren alle drei Bereiche.

Quelle Titelbild: FLUX.2 / Cloudflare Workers AI