SAP S/4HANA-Migrationskosten: Wichtige Kostentreiber, die Sie verstehen müssen

Die SAP S/4HANA-Migrationskosten beschränken sich nicht auf Softwarelizenzen. Die tatsächlichen Kosten entstehen durch Implementierungsaufwand, Custom Code, Datenmigration, Tests, Ausfallzeiten und Legacy-System-Management. Hier finden Sie einen detaillierten Einblick in die wichtigsten Kostentreiber und wie besseres Datenmanagement den Migrationsaufwand reduzieren kann.

Einführung

Viele Organisationen beginnen ihre SAP S/4HANA-Migrationsplanung mit einer zentralen Frage: Wie viel wird es kosten? Zunächst scheint sich die Antwort um Lizenzen, Infrastruktur, Implementierungspartner und Projektzeitpläne zu drehen. Diese sind sicherlich wichtig. Die tatsächlichen Kosten einer S/4HANA-Migration gehen jedoch meist viel tiefer.

Die Kosten werden durch die aktuelle SAP ECC-Landschaft geprägt. Jahre von Custom Code, ungenutzten Reports, inaktiven Buchungskreisen, alten Transaktionsdaten, großen Tabellen, veralteten Schnittstellen und unklarer Datenverantwortung können den Migrationsaufwand erhöhen. In vielen Fällen legt das Migrationsprojekt Komplexität offen, die sich über mehrere Jahre aufgebaut hat.

Deshalb kann der S/4HANA-Migrationsaufwand nicht nur als Software- oder technische Konvertierungskosten verstanden werden. Es geht auch um Daten, Geschäftsprozesse, Compliance und digitale Transformation.

Je mehr Komplexität eine Organisation in das Projekt einbringt, desto mehr Zeit und Aufwand sind erforderlich, um die neue Umgebung vorzubereiten, zu konvertieren, zu testen und zu stabilisieren. Eine große Datenbank erhöht den HANA-Speicherbedarf. Custom Code erhöht den Sanierungsaufwand. Schlecht verwaltete Daten erhöhen Test- und Abstimmungsaufwand. Legacy-Systeme erhöhen die Kosten nach der Migration, wenn sie nicht von Anfang an als Teil des Gesamtbildes betrachtet werden.

Ein praktischer Migrationsplan beginnt daher mit einem einfachen Prinzip: Reduzieren Sie unnötige Komplexität, bevor sie SAP S/4HANA erreicht.

SAP S/4HANA-Migrationskosten sind nicht nur Lizenzen

Lizenzen sind in der Regel die sichtbarsten Kosten bei einer S/4HANA-Migration. Sie sind leicht zu identifizieren, zu budgetieren und intern zu diskutieren. Sie sind jedoch nur ein Teil der Gesamtkosten.

Die vollständigen Kosten umfassen das Implementierungsprojekt, die technische Konvertierung, Beratungsunterstützung, Datenvorbereitung, Custom-Code-Sanierung, Prozessredesign, Tests, Schulungen, Ausfallzeitenplanung, Infrastruktur und Support nach dem Go-live. Darüber hinaus müssen die meisten Organisationen während der Übergangsphase weiterhin SAP ECC-Legacy-Systeme, Testsysteme, Sandbox-Umgebungen und Legacy-Plattformen betreiben.

Insgesamt bedeutet dies, dass das endgültige Budget deutlich höher ausfallen kann als erwartet, wenn das Projekt zu eng geplant wird.

Beispielsweise kann ein Unternehmen die technische Konvertierung planen, aber die Auswirkungen historischer Daten unterschätzen. Wenn alte Transaktionsdaten, veraltete Stammdaten und inaktive Organisationseinheiten mitgeführt werden, wird die Datenbank größer als notwendig. Dies kann die HANA-Speicheranforderungen, den Backup-Aufwand, die Migrationslaufzeit und die laufenden Betriebskosten erhöhen.

Ebenso können Teams, wenn Custom Code nicht frühzeitig bewertet wird, spät im Projekt feststellen, dass wichtige Reports, Integrationen oder Erweiterungen für S/4HANA angepasst werden müssen. Dies kann Tests verzögern und zusätzlichen Beratungsaufwand erzeugen.

Die Migrationskosten betreffen daher nicht nur den Umzug in ein neues System. Es geht darum, das alte System so gut vorzubereiten, dass das neue System keine unnötigen Kosten erbt.

Implementierungs- und Beratungshonorare

Implementierungs- und Beratungshonorare sind oft einer der größten Teile eines S/4HANA-Migrationsbudgets. Diese Honorare decken funktionale Workshops, technische Konvertierung, Projektmanagement, Systemkonfiguration, Datenmigration, Tests, Change Management und Go-live-Support ab. Je komplexer das Quellsystem, desto mehr Beratungsaufwand ist erforderlich.

Der Migrationsansatz beeinflusst ebenfalls die Kosten.

Eine Brownfield-Migration oder Systemkonvertierung wird oft als schnellster Weg angesehen, da sie das bestehende ECC-System in S/4HANA umwandelt. Sie kann jedoch auch bestehende Komplexität in das neue System übertragen, wenn Daten, Custom Code und Prozesse nicht vor dem Projekt überprüft werden.

Eine Greenfield-Migration gibt Organisationen die Möglichkeit, neu zu beginnen, erfordert aber in der Regel mehr Design, Tests und Change Management, da das System von Grund auf neu aufgebaut wird.

Selective Data Transition liegt zwischen diesen beiden Ansätzen. Sie ermöglicht es Organisationen, ausgewählte Historie zu behalten, unnötige Daten zurückzulassen und während der Migration gezielte Änderungen vorzunehmen. Sie erfordert jedoch auch sorgfältige Planung und Spezialexpertise.

Deshalb kann die zu frühe Wahl des Migrationspfads riskant sein. Eine datenbasierte Bewertung vor dem Projekt hilft festzustellen, ob das Unternehmen Geschwindigkeit, Transformation, Datenreduzierung, historischen Zugriff oder eine Kombination dieser Ergebnisse benötigt.

Custom-Code-Sanierung

Die meisten langjährigen SAP ECC-Umgebungen enthalten Custom Code.

Dies kann Z-Reports, Erweiterungen, Workflows, Schnittstellen, Formulare, Custom-Tabellen und maßgeschneiderte Geschäftslogik umfassen. Ein Teil dieses Custom Codes kann noch kritisch sein. Ein Teil kann veraltet sein. Ein Teil wird möglicherweise überhaupt nicht mehr verwendet.

Während der S/4HANA-Migration muss Custom Code bewertet werden, um festzustellen, ob er mit der neuen Umgebung kompatibel ist. Code, der von alten Datenstrukturen, veralteten Transaktionen oder geänderten Geschäftsprozessen abhängt, muss möglicherweise angepasst, ersetzt oder außer Betrieb genommen werden.

Dieser Sanierungsaufwand kann aus mehreren Gründen teuer werden.

Erstens muss die Organisation identifizieren, welcher Custom Code existiert. Zweitens muss sie feststellen, welche Objekte noch verwendet werden. Drittens müssen technische Teams die Auswirkungen von S/4HANA-Vereinfachungselementen bewerten. Viertens muss jeder geänderte oder neu entwickelte Code getestet werden.

Wenn diese Arbeit spät beginnt, kann sie den Migrationszeitplan verzögern.

Custom-Tabellen erhöhen ebenfalls die Komplexität. Sie können historische Daten, geschäftsspezifische Felder oder Integrationen mit externen Systemen enthalten. Wenn die Organisation nicht versteht, welche Custom-Daten nützlich, redundant oder rechtlich erforderlich sind, wird der Migrationsumfang schwerer zu kontrollieren.

Hier wird die frühzeitige Datenermittlung wichtig. Bevor die Migration beginnt, sollten Organisationen nicht nur Standard-SAP-Tabellen, sondern auch Custom-Tabellen und Custom-Entwicklungen bewerten. Dies hilft, technische Schulden zu reduzieren und verhindert, dass unnötige Objekte mitgeführt werden.

Datenmigrationskomplexität

Daten sind einer der größten Kostentreiber bei jeder S/4HANA-Migration.

Jede Organisation muss entscheiden, welche Daten in das neue System übernommen werden sollen, was archiviert werden soll, was gelöscht werden soll und was außerhalb der operativen S/4HANA-Umgebung zugänglich bleiben soll.

Die Schwierigkeit besteht darin, dass nicht alle Daten denselben Wert haben.

Einige Daten werden für den täglichen Betrieb benötigt. Einige sind für Reporting erforderlich. Einige müssen aus rechtlichen, steuerlichen oder Prüfungsgründen aufbewahrt werden. Einige sind nicht mehr nützlich, verbrauchen aber dennoch Datenbankplatz. Einige müssen möglicherweise gelöscht werden, um Datenschutzanforderungen zu erfüllen.

Ohne eine klare Datenvolumen-Management-Strategie können Unternehmen zu viele Daten nach S/4HANA übertragen. Dies erhöht die Datenbankgröße, den Projektaufwand, den Testumfang und den HANA-Speicherbedarf.

Der Migrationsansatz von TJC Group und Xmateria’s empfiehlt, Daten durch praktische Blickwinkel zu betrachten: Welche Prozesse werden migriert, wie viele historische Daten werden benötigt, welche Organisationseinheiten sind aktiv und welche kundenspezifischen Daten sollen übernommen werden. Das hilft Organisationen zu entscheiden, was für das neue System wirklich notwendig ist. Sehen Sie sich die Aufzeichnung des Webinars „How to select the right path to S/4HANA for your business an, um mehr über Data Management für die S/4HANA-Migration zu erfahren.

Beispielsweise kann ein Unternehmen viele Buchungskreise in SAP ECC haben, aber nur einige sind möglicherweise noch aktiv. Inaktive Buchungskreise können starke Kandidaten für die Archivierung sein, anstatt in das operative S/4HANA-System migriert zu werden.

Deshalb ist SAP-Datenarchivierung nicht nur eine Aufräummaßnahme. Sie ist eine Maßnahme zur Kostenkontrolle bei der Migration.

Parallelbetrieb von SAP ECC und SAP S/4HANA während der Übergangsphase

Während der Migration müssen Organisationen häufig mehrere Umgebungen gleichzeitig betreiben.

Das bestehende ECC-System unterstützt weiterhin das Geschäft. Die zukünftige S/4HANA-Umgebung wird aufgebaut, getestet oder konvertiert. Sandbox-, Entwicklungs-, Qualitäts- und Schulungssysteme können ebenfalls erforderlich sein. In einigen Projekten müssen Legacy-Anwendungen und Satellitensysteme verfügbar bleiben, bis die Migration abgeschlossen ist.

Diese Phase des Parallelbetriebs erhöht die Kosten.

Es können zusätzliche Infrastrukturanforderungen, Supportkosten, Verwaltungsaufwand, Benutzerzugriffsverwaltung, Datensynchronisation und Sicherheitsverantwortlichkeiten entstehen. Geschäftsteams müssen möglicherweise auch Migrationstests unterstützen und gleichzeitig ihre normalen operativen Aufgaben fortsetzen.

Die Kosten werden noch höher, wenn Legacy-Systeme nach dem S/4HANA-Go-live aktiv bleiben, nur weil historische Daten noch benötigt werden.

Das Betreiben alter Systeme für gelegentlichen Zugriff kann laufende Lizenz-, Infrastruktur-, Wartungs-, Sicherheits- und Compliance-Kosten verursachen. Deshalb sollte die Systemstilllegung frühzeitig geplant werden und nicht als separate Aufräumaktivität nach der Migration behandelt werden. TJC Group hat dieses Thema ausführlich in seiner ELSA-Webinar-Reihe zu S/4HANA-Migration und Systemstilllegung behandelt, die Migrationsentscheidungen, Datenvorbereitung, HANA-Kostenkontrolle, Compliance, langfristigen Zugriff und Stilllegungs-Use-Cases nach dem Go-live abdeckt.

Eine gut geplante Migration berücksichtigt sowohl die Daten, die nach S/4HANA übertragen werden, als auch die Daten, die zurückbleiben.

Infrastrukturkosten

Infrastrukturkosten können einen erheblichen Anteil der SAP S/4HANA-Migrationsausgaben ausmachen, oft abhängig vom gewählten Lizenzmodell, der Deployment-Architektur, dem Datenvolumen und den langfristigen Systemwachstumserwartungen.

Für viele Organisationen beschränkt sich die Infrastrukturentscheidung nicht auf die Wahl zwischen Cloud- und On-Premises-Hosting. Sie umfasst auch die Entscheidung, ob eine Hyperscaler-Umgebung wie AWS, Microsoft Azure oder Google Cloud, eine von SAP verwaltete Private Cloud oder eine andere Architektur verwendet werden soll, die den Sicherheits-, Compliance-, Performance- und Skalierbarkeitsanforderungen der Organisation entspricht.

Jede Option bringt eigene Kostenauswirkungen mit sich. Eine vollständig verwaltete Cloud-Umgebung kann einige interne Infrastrukturverantwortlichkeiten reduzieren, aber dennoch Kosten für Rechenleistung, Speicher, Sicherheit, Netzwerkkonfiguration, Überwachung und laufende Administration verursachen. Ebenso können von SAP verwaltete Private-Cloud-Umgebungen Teile des Betriebsmodells vereinfachen, aber die erforderliche Systemgröße hängt weiterhin stark vom Volumen der migrierten und aufbewahrten Daten ab.

Hier werden Daten zu einem direkten Infrastrukturkostentreiber. SAP S/4HANA läuft auf der In-Memory-Datenbank SAP HANA, was bedeutet, dass größere Datenvolumen die Speicher- und Storage-Anforderungen erhöhen können. Wenn Organisationen unnötige historische oder inaktive Daten nach S/4HANA migrieren, beginnen sie möglicherweise ihre neue Umgebung mit einem größeren Infrastruktur-Footprint als erforderlich.

SAP-Datenarchivierung hilft, diese Last zu reduzieren, indem sie den aktiven Daten-Footprint vor der Migration verringert. Durch die Archivierung von Daten, die nicht in der Live-Datenbank verbleiben müssen, können Organisationen die Datenmenge reduzieren, die migriert, gespeichert, gesichert und in der neuen S/4HANA-Umgebung verwaltet werden muss. Dies kann helfen, die HANA-Speicheranforderungen richtig zu dimensionieren, den Infrastrukturdruck zu reduzieren und das HANA-Datenbankwachstum nach dem Go-live unter Kontrolle zu halten.

Schulungen und Geschäftsunterbrechungen

Die S/4HANA-Migration betrifft Menschen genauso wie Systeme.

Benutzer müssen möglicherweise neue Prozesse, Oberflächen, Reporting-Strukturen und Genehmigungsabläufe erlernen. Teams müssen sich möglicherweise an Fiori-Anwendungen, neue Rollen, geänderte Stammdatenstrukturen oder neu gestaltete Workflows anpassen.

Schulungen nehmen Zeit in Anspruch. Sie verursachen auch vorübergehende Produktivitätsverluste, wenn Benutzer von vertrauten ECC-Prozessen zur neuen S/4HANA-Umgebung wechseln.

Geschäftsunterbrechungen können auch während der Tests auftreten. Key User müssen möglicherweise an Workshops teilnehmen, migrierte Daten validieren, Testskripte ausführen, Prozessänderungen überprüfen und bei der Problemlösung unterstützen. Diese Aktivitäten sind wesentlich, ziehen aber Geschäftsteams von ihren regulären Aufgaben ab.

Diese Kosten werden oft unterschätzt, weil sie nicht immer als einfache Position im Projektbudget erscheinen. Sie wirken sich jedoch direkt auf das Geschäft aus.

Ein saubererer Migrationsumfang kann helfen, Unterbrechungen zu reduzieren. Wenn das System weniger unnötige Daten und weniger redundante Prozesse trägt, können sich Tests und Schulungen auf das konzentrieren, was das Unternehmen nach dem Go-live tatsächlich benötigt.

Ausfallzeiten und Cutover-Risiko

Ausfallzeiten sind ein weiterer wichtiger Kostentreiber.

Während der finalen Migrations- und Cutover-Phase können Systeme nicht verfügbar oder eingeschränkt sein. Für globale Organisationen kann selbst eine kurze Unterbrechung die Auftragsabwicklung, Finanzoperationen, Logistik, Reporting oder Kundenservice beeinträchtigen.

Die Größe und Komplexität der Datenbank beeinflussen dieses Risiko. Größere Datenbanken können die Konvertierungslaufzeit, den Abstimmungsaufwand und die technische Verarbeitungszeit erhöhen. Mehr Custom Code und mehr Schnittstellen können auch die Anzahl der Abhängigkeiten erhöhen, die vor dem Go-live überprüft werden müssen.

Deshalb ist die Reduzierung des Datenvolumens vor der Migration wertvoll.

Die Archivierung unnötiger Daten vor der S/4HANA-Migration kann die Datenmenge reduzieren, die während der Konvertierung verarbeitet werden muss. Dies kann helfen, die Laufzeit zu reduzieren, ein kürzeres Ausfallzeitfenster zu unterstützen und die Vorhersagbarkeit während des Cutover zu verbessern.

Es reduziert auch die Belastung für Test- und Validierungsteams. Anstatt große Mengen alter Daten abzustimmen, die möglicherweise operativ nicht mehr nützlich sind, können sich Teams auf die Daten konzentrieren, die für die aktuelle Geschäftstätigkeit am wichtigsten sind.

Ausfallzeiten können nicht vollständig beseitigt werden, aber sie können besser kontrolliert werden, wenn der Daten-Footprint kleiner und besser verstanden ist.

Legacy-System-Kosten nach der Migration

Die Migrationskosten enden nicht mit dem Go-live.

Nachdem S/4HANA live ist, stehen Organisationen oft vor einer neuen Frage: Was passiert mit dem alten ECC-System und anderen Legacy-Anwendungen?

Wenn historische Daten in diesen Systemen verbleiben, müssen sie möglicherweise aus rechtlichen, steuerlichen, Prüfungs- oder Geschäftsgründen verfügbar bleiben. Das Betreiben dieser Systeme kann jedoch teuer sein. Alte Systeme erfordern weiterhin Infrastruktur, Lizenzen, Sicherheitsüberwachung, Zugriffskontrolle, Support und technische Wartung. Sie können auch Compliance-Risiken schaffen, wenn veraltete Plattformen nicht mehr ordnungsgemäß verwaltet werden.

Deshalb sollte die Stilllegung von Legacy-Systemen von Anfang an Teil des Migrationsplans sein. Organisationen müssen entscheiden, welche Daten nach S/4HANA übertragen werden, welche Daten archiviert werden und wie auf historische Daten nach der Stilllegung des alten Systems zugegriffen wird.

Mit dem richtigen Ansatz können Unternehmen den Zugriff auf historische Informationen bewahren, ohne das vollständige Legacy-System auf unbestimmte Zeit betreiben zu müssen.

Wie reduziert besseres Datenmanagement die Migrationskosten?

Besseres Datenmanagement reduziert die S/4HANA-Migrationskosten, indem es vermeidbare Arbeit reduziert.

Wenn unnötige Daten vor der Migration archiviert oder gelöscht werden, hat die Organisation weniger Daten zu bewerten, zu konvertieren, zu übertragen, zu testen, abzustimmen, zu sichern und nach dem Go-live zu betreiben. Dies kann die Migrationskomplexität reduzieren und helfen, die HANA-Speicheranforderungen zu kontrollieren.

Ein strukturierter Datenmanagement-Ansatz sollte Folgendes umfassen:

• Frühzeitige Datenermittlung
• Identifizierung von Tabellen mit hohem Volumen und Archivierungsobjekten
• Überprüfung aktiver und inaktiver Organisationseinheiten
• Bewertung kundenspezifischer Tabellen und technischer Schulden
• Archivierung abgeschlossener oder selten abgerufener Transaktionsdaten
• Löschung personenbezogener Daten, sofern nach ILM-Regeln erforderlich
• Planung der Stilllegung von Altsystemen
• Kontrollierter Zugriff auf historische Daten nach der Migration

Diese Arbeit sollte beginnen, bevor der Migrationsansatz finalisiert wird. Andernfalls wählen Organisationen möglicherweise einen Weg, ohne die darunterliegende Datenkomplexität vollständig zu verstehen.

Der HANA-Speicherbedarf ist besonders wichtig, da S/4HANA in einer Premium-Datenbankumgebung läuft. Eine größere Datenbank kann Organisationen in eine höhere Speicherkategorie drängen und die langfristigen Kosten erhöhen. Eine Reduzierung des Datenvolumens vor der Migration hilft, die zukünftige Umgebung passend zu dimensionieren und das künftige Wachstum zu kontrollieren.

Wie TJC Group SAP-Datenarchivierung vor der Migration unterstützen kann

TJC Group unterstützt Organisationen dabei, die Migrationskomplexität durch Datenvolumenmanagement, SAP-Datenarchivierung, Datenlöschung , Stilllegung von Altsystemen und Unterstützung bei fiskalischer Compliance über den gesamten Migrationslebenszyklus hinweg zu reduzieren.

Der Prozess kann bereits vor der Migration mit einer Bewertung des Datenvolumenmanagements starten. So lassen sich Datenbankgröße, Tabellenwachstum, Archivierungsobjekte und potenzielle Einsparungen identifizieren, bevor das Projekt beginnt. Außerdem erhält die Organisation einen klareren Überblick darüber, welche Daten nach SAP S/4HANA migriert werden sollen, welche Daten archiviert werden können und welche Daten aus Compliance-Gründen möglicherweise gelöscht werden müssen.

TJC Group bietet außerdem SAP-Datenarchivierungsservices für SAP-ECC- und S/4HANA-Umgebungen. Archivierung vor der Migration hilft, die zu migrierende Datenmenge zu reduzieren und die operative Belastung nach dem Go-live zu senken. Für Organisationen, die Automatisierung benötigen, kann das Archiving Sessions Cockpit Datenarchivierungs- und Löschprozesse automatisieren. Das ist besonders nützlich für komplexe SAP-Landschaften, in denen manuelle Archivierung zeitaufwendig ist und sich nur schwer skalieren lässt.

Die Unterstützung sollte jedoch nicht enden, sobald die Migration beginnt. Während des Übergangs von SAP ECC zu SAP S/4HANA müssen Organisationen auch planen, wie historische Daten, archivierte Daten und Verpflichtungen zur fiskalischen Berichterstattung über beide Systeme hinweg verwaltet werden.

Das ist besonders wichtig, weil die Stilllegung von SAP ECC idealerweise zusammen mit dem Migrationsprojekt geplant werden sollte und nicht als separate Aktivität nach dem Go-live. Bleibt das alte ECC-System nur deshalb aktiv, weil historische Daten weiterhin benötigt werden, zahlt die Organisation möglicherweise weiterhin für Infrastruktur, Lizenzen, Wartung, Sicherheit und Compliance-Management. Ein besserer Ansatz ist, die Stilllegung frühzeitig zu planen und gleichzeitig sicherzustellen, dass historische Informationen für rechtliche, steuerliche, Audit- und geschäftliche Zwecke zugänglich bleiben.

Für historische Informationen, die nach der Migration zugänglich bleiben müssen, unterstützt die Enterprise Legacy System Application von TJC Group die Stilllegung von Systemen und bewahrt dabei den kontrollierten Zugriff auf Legacy-SAP- und Nicht-SAP-Daten. So können Organisationen die Kosten für den Betrieb alter Systeme nach dem S/4HANA-Go-live senken und gleichzeitig sicherstellen, dass Nutzer auf die benötigten Informationen zugreifen können.

TJC Group kann Organisationen auch bei der SAP-Datenarchivierung in der neuen S/4HANA-Umgebung unterstützen. Nach Abschluss der Migration stoppt das Datenwachstum nicht. Ohne laufende Archivierung und Housekeeping kann die neue HANA-Datenbank weiter wachsen, was den Speicherbedarf und die langfristigen Betriebskosten erhöht. Eine Archivierungsstrategie nach der Migration hilft, das S/4HANA-System schlank, effizient und leichter zu verwalten zu halten.

Mit der Migration von einem System auf ein anderes ist auch ein Compliance-Aspekt verbunden. Organisationen müssen weiterhin rechtliche und fiskalische Anforderungen erfüllen, selbst wenn die Daten während des Übergangs zwischen SAP ECC und SAP S/4HANA aufgeteilt sind. Dazu können Anforderungen im Zusammenhang mit DART, SAF-T, fiskalischer Archivierung und FEC-Reporting gehören.

Beispielsweise sind französische Unternehmen verpflichtet, den FEC-Report jedes Jahr zu erstellen. Findet die Migration während eines Geschäftsjahres statt, kann ein Teil der Daten in SAP ECC liegen und die restlichen Daten in SAP S/4HANA. In solchen Fällen müssen Unternehmen sicherstellen, dass der Report weiterhin korrekt erstellt werden kann und die zugrunde liegenden Daten vollständig, zugänglich und compliant bleiben. TJC Group hat außerdem einen eigenen Artikel zu Best Practices für die Erstellung der FEC-Datei bei der Migration zu SAP S/4HANA veröffentlicht, der diese Herausforderung ausführlicher erläutert.

TJC Group kann Organisationen dabei helfen, diese Kontinuität zu gewährleisten, indem sie während und nach der Migration den Datenzugriff, die fiskalische Extraktion, Archivierung sowie Reporting-Anforderungen unterstützt. Das reduziert das Risiko von Compliance-Lücken und hilft der Organisation gleichzeitig, mit einer saubereren, besser kontrollierten Datenlandschaft zu S/4HANA zu wechseln.

Unternehmen, die eine Migration planen, können auch den SAP-Archivierungsrechner nutzen, um potenzielle Einsparungen durch die Reduzierung des Datenvolumens zu schätzen, bevor das Projekt beginnt.

Fazit

SAP-S/4HANA-Migrationskosten sind so hoch, weil das Projekt selten nur ein technisches Upgrade ist.

Es vereint Lizenzierung, Implementierung, Beratung, kundenspezifischen Code, Datenmigration, Tests, Downtime, Schulungen, Betriebsunterbrechungen und das Management von Altsystemen. Je mehr Komplexität eine Organisation in ihrer ECC-Landschaft mit sich trägt, desto teurer kann die Migration werden.

Daten sind einer der wichtigsten Bestandteile dieser Kostenrechnung.

Eine große, nicht verwaltete Datenbank erhöht den HANA-Speicherbedarf, die Laufzeit der Migration, den Testaufwand, die Anforderungen an Backups und die Betriebskosten nach dem Go-live. Sie kann außerdem den Cutover erschweren und die Belastung für Fachanwender erhöhen.

SAP-Datenarchivierung hilft, diesen Druck zu reduzieren, bevor die Migration beginnt. Durch das Archivieren unnötiger Daten, das Löschen dessen, was nicht mehr aufbewahrt werden sollte, und die frühzeitige Planung des Zugriffs auf Altdaten können Organisationen mit einer saubereren und besser handhabbaren Landschaft zu S/4HANA wechseln.

Das Ziel ist nicht einfach, Daten zu reduzieren. Das Ziel ist, die richtigen Daten zu migrieren, die richtige Historie zu behalten und zu vermeiden, für die Migration und den Betrieb von Informationen zu zahlen, die nicht mehr in das aktive System gehören.

Die SAP-Datenarchivierungsservices von TJC Group vor der Migration reduzieren die Datenmenge, die verschoben werden muss. TJC Group kann außerdem die Archivierung über das Archiving Sessions Cockpit automatisieren und potenzielle Einsparungen durch eine Bewertung des Datenvolumenmanagements abschätzen.