S/4HANA-Migration: Zeitplan und Projektplan nach Migrationsweg

Nach meiner Erfahrung dauert eine S/4HANA-Migration von SAP ECC 12 bis 18 Monate bei einer Brownfield-Konvertierung und 18 bis 24 Monate bei einer Greenfield-Implementierung. Eine Selective Data Transition dauert 12 bis 18 Monate. Der Projektplan folgt den sechs Phasen von SAP Activate, und die Phase, die am häufigsten überzieht, sind die Eigenentwicklungen.

Kurz gesagt: Beginnen Sie den Plan mit dem SAP Readiness Check und geben Sie den Daten 30 bis 40 Prozent des Aufwands. Planen Sie bei einem Brownfield drei Probekonvertierungen ein und rechnen Sie mit einer Cutover-Downtime zwischen einem Wochenende und einer Woche.

Dieser Artikel liefert die Details zu Zeitplan und Planung hinter meinem Leitfaden zur Migration von ECC auf S/4HANA, der die Migrationswege und die ECC-Fristen behandelt. Wenn Sie SAP neu einführen, statt von ECC zu wechseln, deckt mein Leitfaden zum SAP-Implementierungszeitplan diesen Fall mit Phasendauern ab.

Der Weg bestimmt die Dauer. Meine Regel: Greenfield, wenn Sie von anderen Systemen kommen oder neue Prozesse definiert werden müssen. Brownfield, wenn die Prozesse definiert sind und funktionieren, und selektiv, wenn die Prozesse einiger Bereiche neu definiert werden müssen.

So lange dauert jeder Weg in den Programmen, die ich erlebt habe, und das verlängert ihn meistens:

Weg	Typischer Zeitplan	Worauf der Plan aufbaut	Was ihn meistens verlängert
Brownfield (Systemkonvertierung)	12 bis 18 Monate	Konvertierung des bestehenden ECC-Systems mit dem Software Update Manager, dann wiederholte Testkonvertierungen	Anpassung der Eigenentwicklungen und die Konvertierung auf Geschäftspartner
Greenfield (Neuimplementierung)	18 bis 24 Monate	Fit-to-Standard-Design, Build und wiederholte Datenladezyklen	Explore-Workshops, aus denen lange Anforderungslisten werden, und die Datenbereinigung
Selective Data Transition	12 bis 18 Monate	Einigung, welche Buchungskreise, Einheiten und Historie umziehen, dann Spezialwerkzeuge	Datenumfang und Abhängigkeit von spezialisierten Partnern

Der Kalender zählt so viel wie der Weg. Für ECC auf den Erweiterungspaketen 6 bis 8 endet die Standardwartung am 31. Dezember 2027 (SAP News). Ein Brownfield, das diesen Monat startet, geht zwischen Oktober 2027 und April 2028 live, und ein Greenfield, das jetzt startet, landet 2028.

Die meisten Pläne, die heute geschrieben werden, brauchen also etwas erweiterte Wartung im Budget. Nehmen Sie sie von Anfang an auf, nicht als Überraschung im zweiten Jahr.

RISE with SAP ist ein kommerzielles Paket, kein Migrationsweg. Ein Brownfield- oder selektiver Umzug unter RISE landet auf SAP Cloud ERP Private, dem aktuellen Namen, den SAP verwendet für das, was viele noch als S/4HANA Cloud Private Edition suchen. Die 6 bis 9 Monate, die ich für GROW with SAP nenne, und die 9 bis 18 Monate für RISE gelten für Neuimplementierungen, nicht für ECC-Umzüge.

SAP Activate ist die Vorgehensweise von SAP für S/4HANA. Sie hat sechs Phasen: Discover, Prepare, Explore, Realize, Deploy und Run (SAP Activate).

Eine Migration nutzt dieselben Phasen. Was sich ändert, ist die Arbeit in jeder einzelnen.

Der Projektplan der Migration

1. 01

   Discover

   Readiness Check, Wegentscheidung und Business Case.

2. 02

   Prepare

   Plan, Governance, Team und erste Sandbox.

3. 03

   Explore

   Fit-to-Standard- oder Delta-Design, WRICEF-Liste vereinbart.

4. 04

   Realize

   Build, Eigenentwicklungen, Datenladungen, Testkonvertierungen.

5. 05

   Deploy

   Generalprobe, Cutover und Go-live.

6. 06

   Run

   Hypercare, Stabilisierung und Abschaltung von ECC.

Das enthält jede Phase bei einer Migration, und hier unterscheiden sich die Wege:

Phase	Was bei einer Migration passiert	Wie sich die Wege unterscheiden
Discover	SAP Readiness Check, Wegentscheidung, Business Case, erster Blick auf Eigenentwicklungen und Daten	Selektiv braucht hier einen ersten Datenumfang
Prepare	Plan, Governance, Team, Datenverantwortung, Sandbox	Brownfield führt eine erste Sandbox-Konvertierung durch; Greenfield richtet das System und den Workshop-Plan ein
Explore	Fit-to-Standard-Workshops oder Delta-Design, WRICEF-Liste vereinbart, Daten-Mapping	Greenfield verbringt hier die meiste Zeit; Brownfield arbeitet die zutreffenden Simplification Items ab
Realize	Build, Anpassung der Eigenentwicklungen, Datenladezyklen, Testrunden	Brownfield führt Probekonvertierungen durch; Greenfield führt Ladezyklen durch, meist mit dem Migration Cockpit
Deploy	Generalprobe, Cutover, Go-live	Das Downtime-Fenster hängt von Weg, Datenvolumen und Ansatz ab
Run	Hypercare, Stabilisierung	ECC abschalten und archivieren, was Sie behalten haben

WRICEF steht für Workflows, Reports, Interfaces, Conversions, Enhancements und Forms. Es ist die Liste von allem, was Sie über den SAP-Standard hinaus bauen, und es ist die Zahl, die Sie im Auge behalten müssen.

In den 21 SAP-Programmen, die ich geleitet oder gerettet habe, ist der größte Fehler, zu Beginn der Implementierung nicht richtig zu planen. Vereinbaren Sie in Prepare, wer die Datenbereinigung verantwortet, welche Eigenentwicklungen stillgelegt werden und wann jede Testkonvertierung und Generalprobe stattfindet. Diese Termine werden zum Rückgrat des Plans.

Brownfield: um Testkonvertierungen herum planen

Ein Brownfield-Plan baut auf dem Konvertierungszyklus auf. Der Software Update Manager konvertiert das System, und jeder Testlauf zeigt Ihnen, wie lange der echte dauern wird und was bricht.

Bei einem Brownfield plane ich drei Probekonvertierungen vor dem Cutover. Jede sollte auf einer aktuellen Kopie der Produktion laufen, damit die Laufzeiten etwas aussagen. Die letzte sollte sich wie der Go-live verhalten: gleiche Reihenfolge, gleiche Personen, gleiche Prüfungen.

Der eigene Plan von SAP für den Downtime-optimierten Ansatz ist ähnlich. Er sieht einen Sandbox-Lauf, einen Lauf in der Qualitätssicherung, eine Ladeverifikation auf einem Klon und eine Generalprobe vor (SAP Learning). SAP weist darauf hin, dass weniger Läufe technisch möglich sind, aber das Risiko erhöhen.

Greenfield: um Design und Datenladungen herum planen

Bei Greenfield fließt die Zeit in Explore. Fit-to-Standard-Workshops entscheiden, wie viel vom SAP-Standard Sie übernehmen, und jede Lücke wird zu einem WRICEF-Objekt, das gebaut, getestet und gewartet werden muss.

Die Daten wandern in Ladezyklen, meist mit dem SAP S/4HANA Migration Cockpit. Planen Sie mehrere vollständige Ladezyklen ein, jeweils gefolgt von einer Abstimmung, die der Fachbereich abzeichnet. Mein Leitfaden zum Migration Cockpit Schritt für Schritt behandelt Staging-Tabellen, Migrationsobjekte und den Ladeprozess.

Selektiv: um den Datenumfang herum planen

Ein selektiver Plan beginnt mit dem Datenumfang. Welche Buchungskreise, Geschäftsbereiche und Jahre an Historie umziehen, und welche Prozesse neu gestaltet werden.

Dieser Umfang bestimmt die Werkzeuge, den spezialisierten Partner und die Testzyklen. Ändern Sie ihn spät, verschiebt sich der Zeitplan mit.

Nach meiner Erfahrung sind Eigenentwicklungen die Phase, die am häufigsten überzieht. Sie sind auch die am häufigsten vergessenen versteckten Kosten einer Migration, die mein Leitfaden zu den Kosten einer S/4HANA-Migration behandelt.

Das sind die Stellen, die ich im Auge behalten würde, in dieser Reihenfolge:

1. Eigenentwicklungen. Teams schätzen den Umfang aus einem Bericht und entdecken die tatsächliche Größe erst, wenn die Bereinigung beginnt. In einem Programm reduzierte die Analyse mit smartShift die kundeneigenen Objekte von 18.000 auf 3.200. Erst stilllegen, dann anpassen.
2. Kundeneigene Objekte, die die Analyse übersehen hat. Nach meiner Erfahrung sind es die vom SAP Readiness Check übersehenen kundeneigenen Objekte, die später wehtun. Lesen Sie meinen Leitfaden zum SAP Readiness Check, bevor Sie sein Ergebnis als Ihren Umfang behandeln.
3. Daten. Die Datenmigration macht 30 bis 40 Prozent des Aufwands aus. Hat die Bereinigung keinen Verantwortlichen, beginnt sie spät und drückt dann die Testzyklen zusammen. Mein Artikel darüber, warum SAP-Datenmigrationen scheitern, geht tiefer.
4. Explore. Budgets werden in Explore getroffen, wenn die WRICEF-Liste wächst. Wenn der Anbieter den Umfang steuert, hat auf Anbieterseite niemand einen Grund, das Wachstum zu stoppen.
5. Gestrichene Generalproben, um Zeit zu sparen. Eine Generalprobe, die zum Schutz des Termins entfällt, kostet am Go-live-Wochenende meist mehr Zeit, als sie gespart hat.

Meine Sicht: Legen Sie den Go-live-Termin am Ende von Explore fest, wenn die WRICEF-Liste und der Umfang der Eigenentwicklungen bekannt sind. Ein beim Kickoff festgelegtes Datum ist eine Schätzung mit angehängter Vorstandspräsentation.

Die Cutover-Downtime, die ich erlebt habe, reicht von einem Wochenende bis zu einer Woche. Datenvolumen, der Konvertierungsansatz, die Zahl der Gesellschaften und Schnittstellen, die gemeinsam live gehen, und wie schnell der Fachbereich validieren kann, verschieben sie alle.

Für ein Brownfield bietet SAP im Software Update Manager einen Downtime-optimierten Konvertierungsansatz. Er verlagert einen Teil der Datenkonvertierung und -migration in die Uptime, während die Produktion weiterläuft.

Geschenkte Zeit ist das nicht. SAP nennt zusätzliche Testläufe, komplexere Planung, Sperren für Customizing und Entwicklung vor der Downtime und einen in diesem Ansatz geschulten Experten.

Vereinbaren Sie also die Downtime, die der Fachbereich akzeptieren kann, bevor Sie den technischen Ansatz wählen. Beweisen Sie sie dann in den Probekonvertierungen, nicht am Go-live-Wochenende. Halten Sie den Cutover vom Monatsabschluss und von der Hochsaison fern.

Ein Plan ist nur so gut wie die Annahmen dahinter. Das sind die Fragen, die ich stellen würde, bevor jemand unterschreibt:

1. Von welchem Weg geht der Plan aus, und was in den Ergebnissen unseres Readiness Checks stützt ihn?
2. Wie viele kundeneigene Objekte sind nach der Nutzungsanalyse im Umfang, und wie viele werden stillgelegt?
3. Wer verantwortet die Datenbereinigung, und in welcher Phase beginnt sie?
4. Wie viele Probekonvertierungen oder Ladezyklen sind geplant, und mit welchen Daten?
5. Von welcher Downtime geht der Plan aus, und welcher Testlauf beweist sie?
6. Wann wird der Termin festgelegt, und was passiert mit ihm, wenn die WRICEF-Liste in Explore wächst?

Fragen Sie den Partner nach Referenzen aus Programmen wie Ihrem und nach seinem Grobdesign. Wenn die Antworten allgemein und nicht spezifisch für Ihr Unternehmen sind, werten Sie das als Warnsignal.

Führen Sie den SAP Readiness Check in diesem Quartal aus. Legen Sie die Befunde zu Eigenentwicklungen und Daten dem CFO und dem Programmdirektor vor, bevor sich irgendjemand auf einen Go-live-Termin festlegt.

Bauen Sie den Plan dann rückwärts vom Cutover-Fenster auf, das Sie akzeptieren können, mit drei Probekonvertierungen bei einem Brownfield oder den Ladezyklen, die Ihr Weg braucht. Um zuerst den Weg selbst zu prüfen, probieren Sie meine Bewertung Greenfield vs. Brownfield.

Ich helfe Unternehmen, Migrationspläne wie diesen aufzubauen und auf Belastbarkeit zu prüfen. Wenn Sie eine unabhängige Sicht möchten, nehmen Sie Kontakt auf.

Wie lange dauert eine S/4HANA-Migration?

Nach meiner Erfahrung dauert eine Brownfield-Konvertierung von ECC 12 bis 18 Monate, eine Greenfield-Implementierung 18 bis 24 Monate und eine Selective Data Transition 12 bis 18 Monate. Eigenentwicklungen sind die Phase, die am häufigsten überzieht, und die Datenmigration macht 30 bis 40 Prozent des Aufwands aus.

Welche Phasen hat der Projektplan einer S/4HANA-Migration?

Der Plan folgt SAP Activate: Discover, Prepare, Explore, Realize, Deploy und Run. Bei einer Migration enthält Discover den Readiness Check und die Wegentscheidung, Realize die Eigenentwicklungen, Datenladungen und Testkonvertierungen und Deploy die Generalprobe und den Cutover.

Wie viele Probekonvertierungen braucht eine Brownfield-Migration auf S/4HANA?

Bei einem Brownfield plane ich drei Probekonvertierungen vor dem Cutover. Für den Downtime-optimierten Ansatz sieht SAP einen Sandbox-Lauf, einen Lauf in der Qualitätssicherung, eine Ladeverifikation und eine Generalprobe vor und sagt, dass weniger Läufe das Risiko erhöhen.

Wie lange dauert die Cutover-Downtime bei S/4HANA?

Die Cutover-Downtime, die ich erlebt habe, reicht von einem Wochenende bis zu einer Woche. Sie hängt vom Datenvolumen, vom Konvertierungsansatz und davon ab, wie viele Gesellschaften und Schnittstellen gemeinsam live gehen. Die Downtime-optimierte Konvertierung von SAP verlagert einen Teil der Arbeit in die Uptime, braucht aber mehr Testläufe und Planung.

Können wir eine S/4HANA-Migration abschließen, bevor der ECC-Support 2027 endet?

Die Standardwartung für ECC auf den Erweiterungspaketen 6 bis 8 endet am 31. Dezember 2027. Ein Brownfield, das im Oktober 2026 startet, geht zwischen Oktober 2027 und April 2028 live, ein Greenfield 2028. Die meisten Programme, die jetzt starten, sollten etwas erweiterte Wartung einplanen.

Was verzögert S/4HANA-Migrationsprojekte am meisten?

Nach meiner Erfahrung überziehen Eigenentwicklungen am häufigsten, gefolgt von einer Datenbereinigung, die zu spät beginnt, und einer WRICEF-Liste, die in Explore immer weiter wächst. Zu Beginn des Programms nicht richtig zu planen, ist die Wurzel der meisten davon.