Migration von ECC auf S/4HANA: Wege, Schritte und Zeitplan

Die Standardwartung für SAP ECC endet am 31. Dezember 2027, in etwa 15 Monaten. Die optionale erweiterte Wartung läuft gegen höhere Gebühren bis Ende 2030 (SAP News). Komplexe Migrationen können leicht 18 bis 24 Monate dauern, sobald die echten Tests beginnen. Wer noch keinen Weg gewählt hat, schafft ein Go-live vor der Frist wahrscheinlich nicht mehr.

Wenn Sie als CIO oder in der Programmleitung diese Entscheidung treffen, haben Sie drei Wege: Greenfield, Brownfield oder selektive Datenübernahme. Die Arbeit dahinter folgt jeweils denselben fünf Schritten. Führen Sie zuerst den SAP Readiness Check aus, dann wählen Sie.

Der Wechsel von ECC auf S/4HANA ist kein gerades Upgrade. Er verändert, wie Daten gespeichert werden, wie Geschäftsvorfälle gebucht werden und wie Anwender arbeiten. In einem Projekt, an dem ich beteiligt war, ließ ein Team Dutzende kundeneigener Berichte genau so nachbauen, wie sie in ECC waren. Niemand fragte, ob sie überhaupt noch gebraucht wurden. Später wurde die Hälfte davon nie genutzt. Technisch war die Migration sauber. Der Nutzen war es nicht.

Diese Unterschiede treiben den Migrationsaufwand:

Bereich	SAP ECC	SAP S/4HANA
Datenbank	Jede unterstützte Datenbank (Oracle, Db2, SQL Server, weitere)	Nur SAP HANA
Datenmodell im Finanzwesen	Getrennte Tabellen für FI, CO und Ergebnisrechnung mit Summentabellen	Universal Journal (Tabelle ACDOCA) als einzige Quelle für Einzelposten
Debitoren- und Kreditorenstamm	Getrennte Debitoren- und Kreditorenstammsätze	Geschäftspartner ist Pflicht
Benutzeroberfläche	SAP GUI	SAP-Fiori-Apps, mit SAP GUI weiterhin On-Premise und in der Private Edition
Bereitstellung	On-Premise	On-Premise, Private Edition (RISE with SAP) oder Public Edition (GROW with SAP)
Erweiterungen	Z-Programme und Modifikationen	Clean Core: freigegebene APIs, On-Stack mit ABAP Cloud oder Side-by-Side auf SAP BTP
Wartung	EHP 6 bis 8: Standardwartung bis Ende 2027, erweitert bis Ende 2030	SAP sagt Wartung bis Ende 2040 zu

Ein Kunde, mit dem ich gearbeitet habe, fragte immer wieder, warum seine kundeneigenen Batch-Jobs nach der Konvertierung nicht mehr liefen. Die Logik stützte sich auf ECC-Tabellenstrukturen, die S/4HANA verändert hatte. Die Migration selbst war abgeschlossen. Niemand hatte gefragt, ob diese Jobs im neuen Modell überhaupt noch sinnvoll waren.

Die Migration verschiebt die Daten. Die eigentliche Frage ist, was Sie mit den Designentscheidungen anfangen, die Sie erben.

Decide

Welcher Migrationsweg passt zu Ihrer Situation?

Die Altlandschaft ist zersplittert und Sie wollen Prozesse neu gestalten

→Greenfield

Die Prozesse sind solide, ECC ist stabil, die Historie muss bleiben

→Brownfield

Mehrere Gesellschaften, Teile sollen weiterverwendet und Daten selektiv übernommen werden

→Bluefield

Greenfield: neu anfangen

Eine Neueinführung von S/4HANA. Keine Altkonfiguration wird übernommen, die Prozesse werden am SAP-Standard neu ausgerichtet, und geladen werden nur die Daten, die Sie brauchen, mit dem SAP S/4HANA Migration Cockpit.

Sinnvoll, wenn die Altsysteme zu zersplittert für eine saubere Konvertierung sind oder das Unternehmen Prozesse neu denken statt kopieren will.

Achten Sie auf die Veränderungslast. Anwender verlieren vertraute Abläufe. Ich habe Unternehmen erlebt, die es bereuten, ihre Anwender nicht darauf vorbereitet zu haben, wie anders sich ein Greenfield-System anfühlt. Wenn die Planung der Akzeptanz erst mit der Schulung beginnt, ist es schon zu spät.

Brownfield: Systemkonvertierung

Ihr bestehendes ECC-System wird an Ort und Stelle konvertiert. Konfiguration, Custom Code und Historie kommen mit. Die technische Konvertierung läuft über den Software Update Manager (SUM) mit seiner Option für die Datenbankmigration.

Sinnvoll, wenn die Prozesse ausgereift sind, die Transaktionshistorie für die Compliance zählt und keine größere Restrukturierung läuft.

Achten Sie auf die technischen Schulden, die Sie mitnehmen. Die Komplexität der Altlandschaft zieht mit um, wenn Sie sie nicht während der Konvertierung gezielt aufräumen.

Selektive Datenübernahme

Wird manchmal als „Bluefield“ verkauft. Sie verschieben ausgewählte Buchungskreise, Geschäftseinheiten oder Zeitscheiben der Daten, nicht alles, meist mit Spezialwerkzeugen und einem Partner, der damit Erfahrung hat. Der Weg passt zu Konzernen, die durch Fusionen oder Carve-outs entstanden sind, oder wenn Jahre an Historie keine Rolle mehr spielen.

Sinnvoll, wenn Sie die Prozessfreiheit eines Greenfield mit der Datenkontinuität eines Brownfield dort verbinden wollen, wo es zählt.

So schneiden die drei bei den Fragen ab, die Vorstände üblicherweise stellen:

Kriterium	Greenfield	Brownfield	Selektiv
Prozessneugestaltung	Vollständig, am SAP-Standard	Weitgehend erhalten	Je Einheit gewählt
Historische Daten	Nicht übernommen (oder nur offene Posten und Salden)	Vollständig übernommen	Ausgewählter Umfang
Zeit bis zum Go-live	Länger	Kürzer	Abhängig vom Umfang
Technische Schulden	Abgebaut	Mitgenommen	Für den migrierten Umfang reduziert
Change-Impact	Hoch	Geringer	Moderat
Am besten für	Zersplitterte Altlandschaft, grundlegende Neugestaltung	Stabiles, gepflegtes ECC	Fusionen, Carve-outs, gestufte Rollouts

Die Migrationsabfolge

1. 01

   Bewerten

   Führen Sie den SAP Readiness Check aus. Erfassen Sie Custom Code, Add-ons und Schnittstellen.

2. 02

   Daten klassifizieren

   Teilen Sie Daten in heiß, warm und kalt ein. Kalte Daten müssen nicht mitziehen.

3. 03

   Bereinigen

   Beheben Sie Dubletten, Inkonsistenzen und fehlende Felder. Es dauert immer länger als geplant.

4. 04

   Code anpassen

   Führen Sie die Prüfungen des ABAP Test Cockpit aus. Reduzieren Sie Z-Code, statt ihn nur zu portieren.

5. 05

   Testen und umstellen

   Mehrere Testrunden und mindestens eine vollständige Cutover-Probe.

1. Bewertung und Readiness

Fangen Sie hier an. Immer. Der SAP Readiness Check analysiert Ihr ECC-System und berichtet über Simplification Items, die Kompatibilität von Add-ons, Custom Code, Datenvolumen und Sizing.

Die Überraschungen sind meist die Add-ons und der Custom Code. Einige meiner Kunden hatten Hunderte kundeneigener Objekte im Umfang, und die meisten sind überrascht, wie viel inaktiver Code auftaucht. Das finden Sie besser in Woche zwei als in Monat zwölf.

Prüfen Sie zugleich die technischen Voraussetzungen. Die Konvertierung funktioniert ab SAP ERP 6.0 auf jedem Enhancement Package. Das System muss Unicode sein, sonst planen Sie eine zweistufige Konvertierung. Dual-Stack-Systeme müssen zuerst getrennt werden. Debitoren- und Kreditorenstämme müssen vor der Konvertierung in Geschäftspartner überführt werden. Dieser letzte Punkt erwischt mehr Teams als jeder andere.

2. Datenanalyse und Klassifizierung

Vermessen Sie Ihre Daten, bevor Sie sie verschieben, und sortieren Sie sie:

1. Heiß: häufig genutzt, für die laufende Verarbeitung nötig.
2. Warm: gelegentlicher Zugriff, relevant, aber nicht täglich.
3. Kalt: historisch oder ungenutzt, nur für Prüfungszwecke aufbewahrt.

Kalte Daten müssen nicht nach S/4HANA. Archivieren Sie sie. Teams, die diesen Schritt überspringen, schleppen Ballast ins neue System, der sowohl die Migration als auch die Performance bremst.

3. Datenbereinigung und Archivierung

Dieser Schritt dauert länger, als jeder Plan vorsieht. Doppelte Kreditorenstammsätze. Uneinheitliche Mengeneinheiten. Halb gepflegte Debitorenstämme. Diese Probleme gibt es in jedem ECC-System, und sie ziehen unverändert nach S/4HANA um, wenn sie niemand vorher behebt.

Ein Kunde, mit dem ich gearbeitet habe, brauchte allein für Datenbereinigung und Archivierung fünf Monate. Teams, die die Bereinigung auslassen, stoßen im Cutover auf die Probleme, wenn keine Zeit bleibt, sie ordentlich zu beheben. Mein Artikel darüber, warum SAP-Datenmigrationen scheitern, geht auf diesen Schritt tiefer ein.

4. Anpassung des Custom Codes

Führen Sie die S/4HANA-Readiness-Prüfungen des ABAP Test Cockpit (ATC) aus, die Ihren Code mit den Simplification Items von SAP vergleichen. Das Ergebnis zeigt, was eine Syntaxkorrektur braucht, was funktional ersetzt werden muss und was ausgemustert werden sollte.

Das Ziel ist weniger Z-Code, nicht nur funktionierender Z-Code. Jedes kundeneigene Objekt, das Sie mitnehmen, verteuert jedes künftige Upgrade. Mein Clean-Core-Leitfaden zeigt, wie Sie das Verbleibende einordnen.

5. Tests, Schulung und Cutover

Testen Sie in Runden: Unit-Test, Integrationstest, Benutzerabnahmetest (UAT), dann mindestens eine vollständige Cutover-Probe. Beziehen Sie in den UAT sowohl Power-User als auch Gelegenheitsnutzer ein. Sie finden unterschiedliche Probleme.

Die Probe ist nicht optional. Sie deckt Lücken im Zeitplan, fehlende Validierungen und Schnittstellenfehler auf, die erst auftreten, wenn die ganze Abfolge läuft. Teams, die sie überspringen, begegnen diesen Problemen am Go-live-Wochenende.

Diese SAP-Werkzeuge erwarte ich in jedem Migrationsplan:

Werkzeug	Was es tut	Wann Sie es einsetzen
SAP Readiness Check	Simplification Items, Add-ons, Custom Code, Sizing	Vor der Wahl des Wegs
ABAP Test Cockpit (ATC)	Findet Custom Code, der brechen wird	Anpassung des Custom Codes
SAP Signavio	Zeigt, wie Prozesse tatsächlich laufen, nicht wie sie dokumentiert wurden	Vor dem Design-Freeze
SAP LeanIX	Bildet Anwendungen und Schnittstellen ab	Integrationsdesign
Software Update Manager (SUM)	Führt die technische Konvertierung durch	Brownfield-Konvertierung
SAP S/4HANA Migration Cockpit	Lädt Stamm- und Bewegungsdaten	Greenfield-Datenmigration

Für SAP ERP 6.0 auf den Enhancement Packages 6 bis 8 endet die Standardwartung am 31. Dezember 2027. Die optionale erweiterte Wartung läuft bis zum 31. Dezember 2030, gegen einen Aufschlag von zwei Prozentpunkten auf die Wartungsbasis. Frühere Enhancement Packages sind Ende 2025 aus der Standardwartung gefallen.

Über 2030 hinaus gibt es genau einen schmalen Weg. Die Transition-Option für SAP ERP, Private Edition von SAP deckt 2031 bis 2033 ab. Sie gilt nur für große Systeme, die vor Ende 2030 in SAP ERP, Private Edition auf SAP HANA überführt wurden, und nur mit dem Max-Success-Plan von SAP. Behandeln Sie sie als Ausnahme, nicht als Plan.

Zur Dauer: Vollständige Migrationen komplexer Systeme können 18 bis 24 Monate oder länger dauern, sobald die echten Tests beginnen. Für mittlere bis große Unternehmen sind bei einer gut vorbereiteten Konvertierung 12 bis 18 Monate oder mehr realistisch. Ein großes Greenfield-Programm über mehrere Gesellschaften kann 24 bis 36 Monate laufen.

1. 2027Ende der ECC-Standardwartung31. Dezember, für SAP ERP 6.0 EHP 6 bis 8
2. 2028Wahrscheinliches Go-live bei Start jetzt18 bis 24 Monate, sobald die echten Tests beginnen
3. 2030Ende der erweiterten WartungOptional, mit zwei Prozentpunkten Aufschlag
4. 2033Ende der Transition-OptionPrivate Edition, nur für große Systeme

Quelle: SAP News, Februar 2020 und August 2025

Die Rechnung ist also einfach. Wenn Sie heute eine komplexe Bewertung starten, liegt das Go-live im Jahr 2028. Planen Sie die erweiterte Wartung im Budget ein und nutzen Sie die Zeit, um Daten zu bereinigen und Custom Code auszumustern, statt zu warten. Um Ihre Optionen zu prüfen, probieren Sie meine Migrationsbewertung aus.

Was ist der Unterschied zwischen Greenfield- und Brownfield-Migration von ECC auf S/4HANA?

Greenfield ist eine Neueinführung: Weder Altkonfiguration noch Custom Code werden übernommen, die Prozesse werden am SAP-Standard ausgerichtet, und geladen werden nur die Daten, die Sie brauchen. Brownfield konvertiert Ihr bestehendes ECC-System und behält Konfiguration, Custom Code und Historie. Das geht schneller und stört weniger, aber die technischen Schulden kommen mit. Die selektive Datenübernahme liegt zwischen beiden.

Welche Frist gilt für die Migration von SAP ECC auf S/4HANA?

Für SAP ERP 6.0 auf den Enhancement Packages 6 bis 8 endet die Standardwartung am 31. Dezember 2027. Die optionale erweiterte Wartung läuft bis zum 31. Dezember 2030, gegen einen Aufschlag von zwei Prozentpunkten auf die Wartungsbasis. Eine Transition-Option für 2031 bis 2033 gibt es nur für große Systeme, die vor Ende 2030 in SAP ERP, Private Edition auf SAP HANA überführt wurden.

Was sagt der SAP Readiness Check aus?

Er analysiert Ihr ECC-System und berichtet über Simplification Items, die Ihre Konfiguration betreffen, über die Kompatibilität von Add-ons, die Auswirkungen auf Custom Code, Datenvolumen und das HANA-Sizing. Wer ihn früh ausführt, verändert die Diskussion über den Umfang, denn Teams stoßen regelmäßig auf Add-ons und Custom Code, von denen sie nicht wussten, dass sie darauf angewiesen sind.

Wie lange dauert eine Migration von ECC auf S/4HANA?

Eine gut vorbereitete Konvertierung dauert bei mittleren bis großen Unternehmen oft 12 bis 18 Monate oder länger. Komplexe Programme über mehrere Gesellschaften können 18 bis 24 Monate dauern, sobald die echten Tests beginnen, große Greenfield-Programme 24 bis 36 Monate. Die Datenbereinigung ist der häufigste Grund, warum Zeitpläne reißen.

Was ist das Universal Journal (ACDOCA) und warum ist es für die Migration wichtig?

Das Universal Journal ist die einzige Einzelposten-Tabelle ACDOCA, die Daten aus Finanzbuchhaltung, Controlling und Ergebnisrechnung zusammenführt, die ECC in getrennten Tabellen führte. Custom Code und Berichte, die die alten Strukturen lesen, etwa COEP oder die Ergebnisrechnungstabellen, müssen geprüft werden. Manche brauchen kleine Anpassungen, andere eine Neugestaltung.

Welche technischen Voraussetzungen gelten für die Konvertierung von ECC auf S/4HANA?

Die Konvertierung funktioniert ab SAP ERP 6.0 auf jedem Enhancement Package. Das System muss Unicode sein, sonst gehen Sie zweistufig vor. Dual-Stack-Systeme müssen zuerst getrennt werden. Debitoren- und Kreditorenstämme müssen in Geschäftspartner überführt werden. Führen Sie den SAP Readiness Check und die ATC-Prüfungen für Custom Code aus, bevor Sie sich auf Termine festlegen.

Soll ich für eine ECC-Migration RISE with SAP oder GROW with SAP wählen?

Die meisten ECC-Kunden mit viel Custom Code und komplexen Prozessen gehen auf S/4HANA Cloud Private Edition unter RISE with SAP, das die Konvertierung des bestehenden Systems unterstützt. GROW with SAP nutzt die Public Edition. Das ist eine Neueinführung mit Standardprozessen und Erweiterungen ausschließlich über freigegebene APIs. Sie passt zu Unternehmen, die bereit sind, den SAP-Standard zu übernehmen.