Übergang vom Altsystem zur integrierten ERP-Plattform S/4HANA-Migration: Diese Fakten sollten Sie kennen

Die Migration auf SAP S/4HANA im Cloud-only-Modell verändert Betrieb und Steuerungslogik des ERP. Architektur, Datenstrategie, Integrationen und Governance orientieren sich an Plattformvorgaben. Erfolg setzt Entscheidungen zu Standardprozessen, Erweiterungen außerhalb des Kerns und Rollen im Betrieb voraus.

Die Migration von SAP ECC auf SAP S/4HANA verändert nicht nur die zugrunde liegende Datenbanktechnologie. Sie greift in zentrale Bereiche der Unternehmenssteuerung ein, darunter Finanzwesen, Logistik, Stammdatenmanagement, Integrationen und Systembetrieb. Der Umstieg wirkt dauerhaft auf Kostenstrukturen, Releasezyklen, Testaufwände und die Fähigkeit, das ERP über Jahre stabil weiterzubetreiben. Ein erfolgreicher Übergang hängt weniger von einzelnen Tools ab als von klaren Entscheidungen zu Architektur, Datenumfang, Prozessstandardisierung und Governance.

Ausgangslage und Entscheidungsdruck

Das Wartungsende von SAP ECC definiert einen zeitlichen Rahmen, ersetzt jedoch keine strategische Zielsetzung. Unternehmen stehen vor der Entscheidung, ob sie das ERP weiterhin primär als transaktionales Abwicklungssystem nutzen oder als integrierte Plattform für Steuerung, Analyse und Prozessautomatisierung. Diese Entscheidung beeinflusst unmittelbar den zulässigen Grad an Individualisierung, den Umgang mit Eigenentwicklungen und die spätere Upgradefähigkeit.

Ohne ein definiertes Ziel verläuft die Migration häufig als technisches Pflichtprojekt. Fachbereiche bringen Anforderungen ein, die aus dem Bestand heraus argumentiert sind. Die IT versucht, Risiken zu minimieren, indem bestehende Lösungen übernommen werden. Das Ergebnis ist ein neues System mit alter Logik, hoher Komplexität und steigenden Betriebsaufwänden. Der eigentliche Nutzen der neuen Plattform bleibt aus.

Architekturwechsel und Umgang mit Eigenentwicklungen

SAP S/4HANA folgt anderen architektonischen Prinzipien als klassische ECC-Systeme. Erweiterungen sollen nicht mehr durch Modifikationen im SAP-Standard erfolgen, sondern über klar definierte Schnittstellen und Erweiterungspunkte. Diese Vorgabe ist eine Voraussetzung für einen beherrschbaren Betrieb. Eigenentwicklungen im SAP-Kern führen dazu, dass Support Packages und Releases nicht mehr automatisiert eingespielt werden können. Jede Anpassung muss bei jedem Upgrade erneut geprüft, angepasst und getestet werden. Der Aufwand entsteht nicht einmalig, sondern wiederholt sich über den gesamten Lebenszyklus des Systems. Unternehmen unterschätzen diesen Effekt oft, weil er erst nach dem Go-Live sichtbar wird.

Ein tragfähiges Ziel legt daher fest, welche Erweiterungen zwingend erforderlich sind, wo Standardfunktionen ausreichen und welche Anforderungen besser außerhalb des ERP-Kerns umgesetzt werden. Diese Entscheidung muss verbindlich getroffen und im Projekt durchgesetzt werden. Andernfalls entsteht bereits während der Implementierung eine neue technische Altlast.

Wahl des idealen Migrationspfads

Der gewählte Migrationspfad bestimmt Struktur und Risiko des gesamten Programms. Eine System Conversion überführt das bestehende System technisch nach S/4HANA. Konfigurationen, Daten und Eigenentwicklungen bleiben weitgehend erhalten. Dieser Ansatz reduziert den initialen Umstellungsaufwand, setzt jedoch voraus, dass Prozesse konsistent, Daten bereinigt und Integrationen beherrschbar sind. Andernfalls verlagern sich Probleme in Test- und Stabilisierungsphasen.

Eine Neuimplementierung setzt das System neu auf Basis von Standardprozessen auf. Dieser Weg erfordert eine konsequente Auseinandersetzung mit Prozessvarianten, Rollenmodellen und Datenstrukturen. Der organisatorische Aufwand ist höher, die langfristige Wartbarkeit jedoch deutlich besser. Selektive Ansätze kombinieren beide Wege, verlangen aber präzises Scoping und erfahrene Steuerung, da Datenabhängigkeiten und Compliance-Themen schnell komplex werden.

Die Entscheidung darf nicht allein auf Basis von Kosten oder Projektlaufzeit erfolgen. Maßgeblich sind Integrationsdichte, Datenvolumen, gewünschter Rolloutmodus, organisatorische Reife und die Fähigkeit, Prozesse zu vereinheitlichen.

Datenstrategie und Finanzsystem

Daten stellen den größten Risikofaktor der Migration dar. SAP S/4HANA deckt Inkonsistenzen auf, die im bisherigen System toleriert wurden. Besonders im Finanzwesen treten Probleme zutage, die sich direkt auf Laufzeiten, Testaufwände und Projektstabilität auswirken. Große Belegvolumina verlängern Konversionsläufe. Historisch gewachsene Kontenpläne, unvollständige Ledger-Strukturen oder inkonsistente Belegsplits führen zu Abbrüchen und manuellen Korrekturen.

Stammdaten gewinnen zusätzliche Bedeutung. Das Business-Partner-Modell führt Kunden und Lieferanten in einem Objekt zusammen. Dadurch greifen mehrere Fachbereiche auf denselben Datensatz zu. Ohne klare Regeln zu Pflegeverantwortung, Pflichtfeldern und Freigabeprozessen entstehen Zielkonflikte, die das Projekt blockieren und spätere Nacharbeiten erzwingen.

Ein belastbares Ziel unterscheidet zwischen operativ benötigten Startdaten und historischen Beständen. Operative Daten sichern den Geschäftsbetrieb nach dem Go-Live. Historische Daten dienen Nachweis, Analyse und Audit. Sie müssen verfügbar bleiben, gehören aber nicht zwingend in das operative S/4HANA-System.

Warum Cloud-only als strategische Festlegung?

Eine Cloud-only-Entscheidung für SAP S/4HANA ist kein einfaches Betriebsmodell, sondern eine strukturelle Festlegung für Architektur, Organisation und Projektsteuerung. Unternehmen verzichten damit bewusst auf On-Premises-Optionen, lokale Systemzugriffe und individuelle Betriebsfreiheit zugunsten standardisierter Plattformmechanismen, vorgegebenen Releasezyklen und klar abgegrenzter Verantwortlichkeiten. Diese Entscheidung erhöht Planbarkeit und erzwingt Disziplin in Architektur und Prozessen.

Cloud-only bedeutet, dass das ERP nicht mehr als individuell gestaltbares System verstanden wird, sondern als standardisierte Kernplattform. Differenzierung verlagert sich von Modifikationen im Kern auf Erweiterungen außerhalb des Systems, Integrationen und datengetriebene Zusatzfunktionen. Die Wahl des Migrationspfads wird bei Cloud-only faktisch eingeschränkt. Eine klassische System Conversion mit vollständiger Übernahme historischer Konfigurationen und Eigenentwicklungen passt nur eingeschränkt zu Cloud-only-Szenarien. Technisch ist sie möglich, führt jedoch häufig zu Zielsystemen, die zwar formal in der Cloud laufen, aber strukturell On-Premises-Denkmuster nutzen.

In der Praxis begünstigt Cloud-only entweder eine Neuimplementierung oder eine stark selektive Transition. Beide Ansätze reduzieren Altlasten und erzwingen eine Auseinandersetzung mit Standardprozessen. Das Projekt muss früh definieren, welche Prozesse im Standard abgebildet werden und wo Erweiterungen außerhalb des Kerns notwendig sind. Jede Abweichung vom Standard erhöht nicht nur Implementierungsaufwand, sondern verschiebt Komplexität in Betrieb und Releasephasen.

Die Zielarchitektur trennt klar zwischen ERP-Kern, Integrationsschicht und Erweiterungsebene. Der SAP-Kern übernimmt transaktionale Prozesse und Datenhaltung. Erweiterungen laufen außerhalb, zum Beispiel auf der SAP Business Technology Platform. Integrationen nutzen standardisierte APIs und Ereignisse. Direkte Datenbankzugriffe, Betriebssystemskripte oder kundenspezifische Batchlogik entfallen vollständig.

Clean Core als zwingende Voraussetzung

In Cloud-only-Szenarien ist Clean Core keine Leitlinie, sondern eine technische Notwendigkeit. Modifikationen im SAP-Standard sind entweder nicht zulässig oder führen zu massivem Mehraufwand bei Releases. Eigenentwicklungen im Kern bedeuten, dass jedes Upgrade zusätzliche Anpassungen und Tests erfordert. Da Cloud-Systeme regelmäßigen Releasezyklen unterliegen, wiederholt sich dieser Aufwand mehrfach im Jahr. Ein Cloud-only-Programm muss daher verbindlich festlegen, dass Erweiterungen außerhalb des Kerns umgesetzt werden. Diese Regel gilt unabhängig vom fachlichen Druck einzelner Bereiche. Governance-Strukturen müssen diese Entscheidung absichern.

Die Rolle der SAP Business Technology Platform (BTP) wächst damit deutlich. Sie übernimmt Workflow-Logik, Integrationsprozesse, UI-Erweiterungen, Event-Verarbeitung und zusätzliche Anwendungen. Das Projekt muss diese Plattform nicht als Add-on betrachten, sondern als festen Bestandteil der Zielarchitektur. Dazu gehören Identitätsmanagement, Transportkonzepte, Monitoring und Betriebsverantwortung.

Datenstrategie unter Cloud-only-Bedingungen

Die Übernahme großer historischer Datenmengen in das operative System treibt Kosten und erhöht Betriebsrisiken. Gleichzeitig unterliegen Cloud-Systeme strengeren technischen und organisatorischen Restriktionen. Ein Projekt muss daher sehr früh entscheiden, welche Daten für den operativen Betrieb notwendig sind und welche außerhalb des ERP vorgehalten werden.

ERP-Cloud-Migration am Beispiel von SAP S/4HANA

Sichere Umstellung auf Cloud-ERP

In der Praxis bedeutet das eine klare Trennung zwischen Startdaten für den Geschäftsbetrieb und historischen Daten für Nachweis und Analyse. Historische Daten gehören in ein separates Zugriffssystem, nicht in das Cloud-ERP. Diese Trennung reduziert Systemgröße, beschleunigt Migration und vereinfacht Tests. Sie ist in Cloud-only-Szenarien nicht optional, sondern Voraussetzung für wirtschaftlichen Betrieb.

Zusätzlich erzwingt Cloud-only eine saubere Stammdatenstrategie. Zentrale Objekte wie Business Partner müssen konsistent gepflegt werden. Da mehrere Prozesse und Anwendungen auf dieselben Stammdaten zugreifen, führen unklare Zuständigkeiten schnell zu Konflikten. Das Projekt muss verbindlich regeln, wer welche Daten pflegt, welche Felder verpflichtend sind und wie Änderungen freigegeben werden.

Integration und Drittanwendungen

Cloud-only schließt viele historische Integrationsmuster aus. Punkt-zu-Punkt-Schnittstellen, Dateiaustausch über Filesysteme oder direkte Datenbankzugriffe sind nicht mehr zulässig. Integrationen erfolgen über APIs, Events oder Messaging. Das erhöht initialen Designaufwand, senkt jedoch langfristig Betriebsrisiken. Ein Cloud-only-Programm muss daher die Integrationsarchitektur früh festlegen. Welche Systeme bleiben angebunden, welche werden ersetzt, welche Funktionen wandern in die Cloud. Kritisch sind Eigenentwicklungen, die auf Betriebssystemzugriffe oder lokale Tools angewiesen sind. Diese müssen entweder ersetzt oder funktional neu konzipiert werden.

Auch das Monitoring ändert sich. Betrieb erfolgt nicht mehr über Systemzugriff, sondern über Plattformmechanismen, Logs, Metriken und Schnittstellenüberwachung. Das Projekt muss diese Fähigkeiten im Betriebsteam aufbauen. Cloud-only verändert dabei auch den Charakter von Tests und Betrieb. Releasezyklen sind vorgegeben. Das Projekt muss daher ein dauerhaftes Testkonzept etablieren, das auch nach dem Go-Live funktioniert. Manuelle Einmaltests reichen nicht aus. Regressionstests, klare Abnahmekriterien und feste Testfenster gehören zur Betriebsorganisation.

Der Go-Live ist nicht der Endpunkt, sondern der Übergang in einen kontinuierlichen Änderungsmodus. Erweiterungen, Anpassungen und Integrationen müssen so gestaltet sein, dass sie mit den Releasezyklen kompatibel bleiben. Ein Betrieb, der auf Ausnahmegenehmigungen oder Release-Verschiebungen setzt, ist in Cloud-only-Szenarien nicht tragfähig.

Das ist für Entscheider wichtig

Cloud-only reduziert technische Freiheitsgrade, erhöht aber Transparenz, Planbarkeit und langfristige Wartbarkeit. Der Preis dafür ist organisatorische Disziplin. Unternehmen müssen bereit sein, Prozesse zu vereinheitlichen, Eigenentwicklungen kritisch zu hinterfragen und Governance konsequent durchzusetzen. Wer Cloud-only wählt, entscheidet sich gegen maximale Individualisierung und für steuerbare Komplexität.

Für Entscheider bedeutet das, Cloud-only nicht als IT-Option zu behandeln, sondern als strukturelle Unternehmensentscheidung. Nur wenn Architektur, Datenstrategie, Organisation und Betrieb auf dieses Ziel ausgerichtet sind, entfaltet Cloud-only seinen Nutzen. Andernfalls ergibt sich ein System, das zwar in der Cloud läuft, aber dieselben Probleme wie zuvor mit sich trägt.

Stilllegung von Altsystemen und Compliance

Ein Migrationsprojekt ist fachlich erst abgeschlossen, wenn der Umgang mit Altdaten geregelt ist. Das Weiterbetreiben von SAP ECC als Archiv verursacht Lizenzkosten, Sicherheitsrisiken und Betriebsaufwand. Auch das Einfrieren eines Systems in einer virtuellen Maschine stellt keine dauerhafte Lösung dar, da Patches, Abhängigkeiten und Zugriffskonzepte langfristig nicht stabil bleiben.

Ein belastbarer Ansatz extrahiert Daten, Dokumente und Reports aus dem Altsystem und stellt sie über eine separate Zugriffsebene bereit. Diese Lösung muss Nachweise zu Vollständigkeit und Unveränderbarkeit liefern, um steuer- und revisionsfest zu sein. Gleichzeitig müssen Datenschutzanforderungen wie Löschung oder Anonymisierung technisch abbildbar bleiben. Diese Themen gehören in die Projektplanung und dürfen nicht in eine spätere Phase verschoben werden.

So geht die technische Vorbereitung und Projektsteuerung

Werkzeuge liefern Transparenz, ersetzen jedoch keine Entscheidungen. Analysen zu Simplification Items, Custom Code und Add-ons müssen früh erfolgen und in konkrete Maßnahmen übersetzt werden. Unbenutzter Code sollte entfernt werden, bevor er migriert wird. Späte Bereinigung verschiebt Arbeit in die teuersten Projektphasen.

System Conversions benötigen mehrere Testläufe auf produktionsnahen Kopien, um reale Laufzeiten und Fehlerbilder zu erkennen. Neuimplementierungen benötigen wiederholte Datenladungen mit fachlicher Validierung. Selektive Ansätze erfordern zusätzliche Kontrollmechanismen, da Daten aus unterschiedlichen Quellen zusammengeführt werden.

Warnung vor Transformationsfalle

SAP-Systemumstellung: Unternehmen unter Zeitdruck

Integration, Tests und Betriebsaufnahme

Die Integrationsarchitektur entscheidet über Stabilität und Erweiterbarkeit. Schnittstellen müssen auf freigegebenen APIs basieren. Historische Abhängigkeiten auf Betriebssystemebene blockieren Cloud-Szenarien und erhöhen Betriebsrisiken. Tests müssen End-to-End-Prozesse, Schnittstellen, Berechtigungen und Volumen abdecken. Performanceprobleme ergeben sich häufig durch Eigenentwicklungen und komplexe Abfragen und müssen vor dem Go-Live behoben sein.

Der Cutover ist ein abgestimmter Ablauf aus technischen und fachlichen Aktivitäten. Ein Fallback-Szenario benötigt klare Kriterien und Entscheidungswege. Nach dem Go-Live beginnt der Regelbetrieb mit klarer Supportstruktur, geplanter Stabilisierung und definiertem Übergang in den Wartungsmodus.

(ID:50688778)