SAP S/4HANA-Migration: Häufige Fallstricke – Erkenntnisse aus einem 8-monatigen Projekt

Die Brownfield-Migration eines größeren ungarischen Unternehmens von SAP ECC zu S/4HANA, an der wir als Subunternehmer beteiligt waren. Ein achtmonatiges Projekt mit einem vierköpfigen Core-Team auf Kundenseite plus zwei Personen von uns. In diesem Artikel teilen wir die fünf wichtigsten Lehren, die auch für andere nützlich sein können – plus den tatsächlichen Projektzeitplan, die Herausforderungen und was wir im Nachhinein anders gemacht hätten.

Da das Ende des SAP-ECC-Mainstream-Supports 2027 näher rückt, werden 2026 und 2027 für viele Unternehmen zu Jahren ähnlicher Brownfield-Migrationen. Dieser Artikel unterstützt mit konkreten Erkenntnissen bei der Vorbereitung.

Der Kunde und das Projekt

Anonymisiert: ein mittelgroßes ungarisches Unternehmen (250+ Mitarbeiter, über 40 Mrd. HUF Jahresumsatz), das seit Jahren auf SAP ECC 6.0 lief. Wegen des ECC-End-of-Support 2027 musste auf S/4HANA migriert werden — mit einem Brownfield-Ansatz (In-Place-Upgrade), damit das bestehende Customizing und die Daten erhalten bleiben.

Der Projektumfang

• Von: ECC 6.0 EHP7
• Nach: S/4HANA 2023 (im Projektverlauf auf 2024 aktualisiert)
• Module: FI/CO/MM/SD
• Custom-Codebasis: 80+ Z-Programme
• Integrationen: 12 externe Schnittstellen (Banken, Webshop, Partner, EDI)
• User-Basis: 180 Named User
• Stammdaten: ca. 30.000 Artikel, ca. 5.000 Kunden, ca. 2.000 Lieferanten

Das Team

• Kunde: vierköpfiges Core-Team (1 PM, 1 Functional Lead, 1 ABAP-Entwickler, 1 BASIS-Administrator)
• Wir: zwei Personen als Subunternehmer (1 Senior Functional Consultant, 1 ABAP-Entwickler)
• SAP-Beratungspartner: drei externe Berater (Premium-Support-Partner)

Die dreistufige Systemlandschaft

Production (PRD)  — produktiv laufendes SAP ECC
                   ↓ Brownfield-Upgrade-Wochenende
Production (PRD)  — produktiv laufendes SAP S/4HANA

Quality Assurance (QAS) — UAT, Regressionstests
Development (DEV)       — Customizing, Transport
Sandbox (SBX)           — Tests, Proof-of-Concept

Der Unterschied zwischen Brownfield und Greenfield: Beim Brownfield bleiben das bestehende Customizing, die Stammdaten und die Transaktionshistorie erhalten. Greenfield bedeutet dagegen ein neuer Tenant mit separater Datenmigration.

Der reale Zeitplan der 9 Monate (8 + 1 Verzug)

Monat	Phase	Kundenseite	Unsere Seite
1	Discovery	Audit, Scope, Freigabe	Audit-Unterstützung
2	Plan	High-Level Technical Plan	Z-Objekt-Audit
3–5	Stammdatenbereinigung	3 Vollzeitkräfte	1 Teilzeitkraft
6	Custom-Code-Migration	2 Personen (ABAP + Functional)	1 ABAP-Vollzeitkraft
7	Integrationstests	3 Personen	1 Teilzeitkraft
8	UAT	8 Key User	UAT-Unterstützung
9	Cutover + Hyper-Care	Alle Hände an Deck	2 Vollzeitkräfte

Der ursprüngliche Plan sah 8 Monate vor, tatsächlich wurden es 9 Monate (1 Monat Verzug, vor allem wegen der Stammdatenbereinigung und der Z-Objekt-Umschreibung — siehe Lehre 1 und 2).

Lehre 1: Die Stammdatenbereinigung dauert länger als erwartet

Das Problem

Ursprüngliche Schätzung: 4 Wochen. Tatsächlich: 11 Wochen. Das ist eine Überschreitung von 177 % in diesem Workstream.

Die über Jahre in ECC 6.0 angehäuften „dirty" Daten:

• Doppelte Lieferanten — dieselbe Firma auf 3–4 unterschiedlichen Datensätzen (abweichende Schreibweise, Stadt, IBAN)
• Inaktive Kunden — 2010 angelegt, seit 2018 nicht mehr genutzt; nie hat sie jemand gelöscht
• Falsche Artikelkategorien — ein Partner-Export war falsch gemappt, 2000+ Artikel in der falschen Kategorie
• Formatierungsinkonsistenzen — IBAN-Nummern in 4 unterschiedlichen Formaten
• Fehlende Werte — Pflichtfelder auf NULL, was ECC tolerierte, S/4HANA jedoch nicht

Warum das in S/4HANA kritischer ist

Das Business-Partner-Konzept von S/4HANA ist strenger: Kunde, Lieferant und Mitarbeiter aus der alten Welt werden alle in einer einzigen „Business Partner"-Entität zusammengeführt. Wer gleichzeitig Kunde und Lieferant ist (etwa Vermittlerfirmen), hatte in ECC 2 Datensätze, in S/4HANA nur noch 1 — diese mussten harmonisiert werden.

Hinzu kommt, dass S/4HANA strengere Validierungen anwendet (Pflichtfelder, Formate), die die in ECC gepflegten Legacy-Daten nicht erfüllen konnten.

Was haben wir gemacht?

1. Stammdaten-Audit-Skript (ABAP)
   → Ergebnis: 12.000 Anomalien (Duplikate, Inkonsistenzen, fehlende Werte)

2. Kategorisierung der Anomalien:
   - High Priority (Kunden, Lieferanten, kritische Artikel): 3000 Datensätze
   - Medium (inaktiv, selten genutzt): 6000 Datensätze
   - Low (irrelevante Altdaten): 3000 Datensätze

3. Durchführung der Bereinigung:
   - High Priority: manuell, dediziertes 3-köpfiges Team (Finanzen + 
     Logistik + IT auf Kundenseite)
   - Medium: Skript mit menschlicher Prüfung
   - Low: Anonymisierung und Archivierung

4. Testmigration in die Sandbox:
   - 3 Iterationen, nach jeder ein neuer Bereinigungs-Batch

Lehre

Planen Sie für die Stammdatenbereinigung einer Brownfield-Migration das 2- bis 3-Fache Ihrer ersten Schätzung ein. Wenn Sie in der Discovery-Phase „4 Wochen" hören, planen Sie mit 10–12 Wochen.

Lehre 2: Wir haben die Kosten der Migration der Custom-Z-Objekte unterschätzt

Das Problem

80 kundenspezifische Z-Programme. Laut der Analyse der SAP Custom Code Migration App:

Ursprüngliche Schätzung der SAP-App	Tatsächliches Ergebnis
60 „Grün" (unkompliziert)	35 Grün
15 „Gelb" (kleinere Anpassung)	30 Gelb
5 „Rot" (umfangreiche Umschreibung)	15 Rot

Der tatsächliche Aufwand im „Gelb"- und „Rot"-Bereich verdreifachte sich. Die SAP-App erkennt Breaking Changes auf Syntaxebene, aber die Laufzeitsemantik und die Nebeneffekte wurden unterschätzt.

Was haben wir gemacht?

1. Priorisierung
   → die 5 geschäftskritischsten Z-Programme identifiziert (z. B. 
     individueller Rechnungsstellungs-Flow, Zollabfertigungsbericht)
   → diese erhielten Release-Blocker-Priorität

2. Umgang mit den übrigen 75 Z-Programmen:
   - 15 alte Z-Programme entfernt (nicht mehr genutzt, vom Business 
     Owner bestätigt)
   - 30 gelbe Z-Programme umgeschrieben (durchschnittlich 4–8 Std. pro Stück)
   - 15 rote Z-Programme neu geschrieben (durchschnittlich 40–80 Std. pro Stück)
   - 15 grüne Z-Programme automatisch angepasst

3. Tech-Debt-Backlog
   → die 25 Z-Programme niedrigerer Priorität in die „Post-Go-Live"-Phase 
     verschoben

4. Regressionstest-Framework
   → Unit-Tests plus Regressionstests auf UAT-Niveau für jedes Z-Programm

Die 5 kritischen Z-Programme

Z-Programm	Funktion	Geschätzt → Tatsächlich
Z_VAT_REPORT_HU	Export der ungarischen USt-Voranmeldung	16 Std. → 24 Std.
Z_BANK_SFTP_INTEGRATION	Import von Banktransaktionen	24 Std. → 48 Std. (neuer OData-Flow)
Z_CUSTOMS_DECLARATION	Zollabfertigungsbericht	32 Std. → 60 Std.
Z_INVENTORY_BARCODE	Barcode-basierte Inventur	40 Std. → 56 Std.
Z_PRICING_LOGIC	Individuelle Preislogik	56 Std. → 88 Std. (umfangreichste Umschreibung)

Lehre

Die SAP Custom Code Migration App liefert eine grobe Schätzung, unterschätzt aber den Aufwand für die tiefgreifende (gelbe/rote) Code-Umschreibung. Planen Sie für den Aufwand der Z-Objekt-Umschreibung +50 % ein.

Lehre 3: Integrationsmapping ist ein kritischer Punkt — es verdient deutlich mehr Zeit, als wir dachten

Das Problem

12 externe Schnittstellen:

• Banken-SFTP (MasterCard, OTP, K&H, Erste — unterschiedliche Formate)
• Webshop-REST (Magento → SAP)
• Partner-SOAP (3 große Partnerunternehmen, EDI)
• Lieferanten-EDI (ENGDAT, X12)
• Mobile-App-Webhook (CRM-Integration)
• Logistik-Drittanbieter (DHL, GLS)
• Lohnprogramm-Integration (Nexon-CSV-Export)
• HR-Portal (SuccessFactors → ECC → S/4HANA)

Laut Analyse waren alle kompatibel. In der Realität nutzte ECC bei 4 Schnittstellen proprietäre RFC-Module, die in S/4HANA als veraltet gelten.

Die 4 problematischen Schnittstellen

Schnittstelle	Problem	Lösung
Magento-Webshop	RFC-basierte, individuelle BAPI	Umstellung auf OData-Service
K&H Bank	Proprietäres IDoc	XML-REST-Endpoint
Lieferanten-EDI	Z-Modul-RFC	SAP Integration Suite
HR-Portal (alt)	Individuelle RFC-DEST	RESTful-Endpoint

Was haben wir gemacht?

1. Discovery (im Nachhinein): End-to-End-Testszenario für alle 12 
   Schnittstellen
2. Die 4 problematischen wurden durch OData/REST ersetzt (und dabei 
   gleich modernisiert)
3. Zusätzlicher Scope von 3 Wochen, aber es hat sich gelohnt — die 
   alten RFCs hatten ohnehin keine langfristige Roadmap

Lehre

Integrationsmapping funktioniert nicht auf Basis einer reinen Analyse — jede Schnittstelle muss bereits in der Discovery-Phase in einer Testumgebung auf dem Sandbox-S/4HANA getestet werden. „Auf dem Papier okay" bedeutet zur Laufzeit oft „unsicher".

Lehre 4: Ein 36-Stunden-Cutover-Wochenende funktioniert nicht ohne dokumentiertes Runbook

Das Problem

Viele kleine Schritte (35+), alle in strikter Reihenfolge. Fällt einer aus, folgt ein Rollback. Der erste Testlauf (Test-Cutover) dauerte 42 Stunden; im Produktivsystem durfte das Zeitfenster jedoch nicht über 36 Stunden hinausgehen.

Die Iterationen des Cutover-Runbooks

Testlauf 1 (Sandbox):     42 Std.
  Optimierung 1:
  - 6 Schritte parallelisierbar
  - 3 Schritte in Skriptform umgeschrieben
  
Testlauf 2 (Sandbox):     35 Std.
  Optimierung 2:
  - Vorwärmen des Stammdaten-Caches
  - Index-Rebuilds parallelisiert
  - Cutover-Cache-Invalidierung per Skript
  
Testlauf 3 (Sandbox):     31 Std.

Produktiv-Cutover:         28 Std.
  (Freitag 16:00 → Sonntag 20:00)

Die wichtigsten Gruppen der 35 Schritte

Phase 1: Pre-Cutover (Freitag 16:00 → 20:00)
  - Altsystem eingefroren, Kommunikation an die User
  - Finale Datenextrakte
  - Sandbox-Validierung

Phase 2: Datenbank-Upgrade (Freitag 20:00 → Samstag 12:00)
  - Vorbereitung der HANA-Migration
  - Schema-Konvertierung
  - Index-Rebuild (parallel, wo möglich)
  - Aktivierung des Custom Code

Phase 3: Stammdaten-Load (Samstag 12:00 → 20:00)
  - Business-Partner-Harmonisierung
  - Laden der bereinigten Stammdaten
  - Validierungsskripte

Phase 4: Integrationstest (Samstag 20:00 → Sonntag 08:00)
  - Alle 12 Schnittstellen End-to-End getestet
  - Druckerwarteschlange, Batch-Jobs verifiziert

Phase 5: UAT-Freigabe (Sonntag 08:00 → 14:00)
  - Verifizierung durch 8 Key User
  - Durchlauf der kritischen Szenarien

Phase 6: Go-live (Sonntag 14:00 → 20:00)
  - Benutzerzugriff aktiviert
  - Hyper-Care-War-Room aktiv
  - Monitoring-Dashboard live

Lehre

Führen Sie den Test-Cutover mindestens zweimal durch, committen Sie das dokumentierte Runbook in Git, und analysieren Sie die Parallelisierbarkeit. Das Runbook mit den 35 Schritten bestand aus einem Notion-Dokument plus in Git versionierten SQL-/ABAP-Skripten.

Lehre 5: 30 Tage Hyper-Care waren zu wenig — wir haben auf 60 Tage umgeplant

Das Problem

In den ersten 30 Tagen fielen typischerweise 5–10 Tickets pro Tag an. Ab Tag 31 waren es immer noch 4–5 Tickets pro Tag. Im Scope waren 30 Tage Hyper-Care vorgesehen — eine Verlängerung musste beantragt werden.

Was haben wir gemacht?

Hyper-Care-Zeitplan:
Tag 1–30:  Hyper-Care-Phase 1 (volles Team, 5–10 Tickets/Tag)
Tag 31–60: Hyper-Care-Phase 2 (reduziertes Team, 4–5 Tickets/Tag)
Tag 61–90: Warm-Support (1 Teilzeitkraft, on-call)
Ab Tag 91: Standard-Wartungsvertrag

Der Post-Go-live-Retro-Call fand jeden Freitag statt — wir haben die eingegangenen Tickets besprochen, nach Priorität kategorisiert und für die 20 häufigsten Ticket-Typen Runbooks erstellt (für die Übernahme durch den Support des Kunden).

Die 10 häufigsten Hyper-Care-Ticket-Typen

Rang	Problem	Lösung
1	„Alter Transaktionscode nicht gefunden"	Aktualisierung der Schulungsunterlagen
2	„Verständnisprobleme mit dem neuen Berichtsformat"	Zusätzliche Schulungssession
3	„Buchungsfehler im individuellen Finanz-Flow"	Feinjustierung des Customizing
4	„Druckformular fehlerhaft"	Aktualisierung der Formularvorlage
5	„Workflow-Freigabe zu langsam"	Performance-Tuning
6	„Bankintegration bleibt hängen"	Schnittstellen-Monitoring
7	„Doppelte Bestandsbuchungen"	Korrektur der Stammdaten
8	„Formatierungsprobleme beim Excel-Export"	Korrektur der XLS-Vorlage
9	„RBAC: kein Zugriff auf X"	Aktualisierung der Berechtigungen
10	„Fehlerhafte Lieferantendaten auf der Rechnung"	Korrektur der Stammdaten

Lehre

Planen Sie bei einer S/4HANA-Brownfield-Migration 60 Tage Hyper-Care ein. Bei einem KMU-Projekt können 30 Tage ausreichen, im Enterprise-Umfeld nicht.

Ergebnisse — 6 Monate nach dem Go-live

Kennzahl	Vorher (ECC)	6 Monate danach (S/4HANA)
Kritische Incidents (P1)	1–2 / Monat	0
Hohe Incidents (P2)	5–8 / Monat	1–2 / Monat
Berichtserstellungszeit (Finanzmonatsabschluss)	4–5 Tage	1–2 Tage
Performance (kritische Transaktionen, p95)	3–5 s	0,8–1,5 s
Nutzerzufriedenheit (interner NPS)	5,2 / 10	7,2 / 10
Stammdatengenauigkeit	ca. 85 %	ca. 98 %
Audit-Findings (ISO 9001)	12 Findings	3 Findings

Die Performance-Verbesserung ist der In-Memory-Datenbank HANA zu verdanken (die kritischen Transaktionen laufen 30–50 % schneller). Die höhere Nutzerzufriedenheit geht auf die neue Fiori-Oberfläche zurück.

Konkrete geschäftliche Auswirkungen

• Finanzmonatsabschluss von 4–5 Tagen auf 1–2 Tage verkürzt. Das verschafft der Geschäftsführung 3 zusätzliche Tage für Entscheidungen.
• Audit-Findings von 12 auf 3 reduziert. Der ISO-9001-Auditprozess ist um 50 % kürzer.
• Echtzeit-Reporting — das wöchentliche Management-Dashboard läuft jetzt live.

Was hätten wir anders gemacht?

1. Eine längere Discovery-Phase

Die einmonatige Discovery-Phase hätte zwei Monate dauern müssen. Die Analyse von Stammdaten, Z-Objekten und Integrationen wurde durchweg unterschätzt.

2. Das Stammdaten-Team einen Monat früher starten

Das dreiköpfige Team für die Stammdatenbereinigung startete erst ab dem 3. Monat. Hätte es bereits ab dem 1. Monat gearbeitet, wäre der gesamte Projektverzug vermeidbar gewesen.

3. Ein dedizierter Sprint für Integrationstests

Das Testen der 12 Schnittstellen erfolgte erst am Ende der Build-Phase — ein dedizierter einwöchiger Sprint im 5. Monat hätte geholfen.

4. Ein Kommunikationsplan für die User

Die 180 User erhielten ihre Schulungseinladung erst 30 Tage vor dem Go-live. Das hätte 2 Monate früher passieren müssen — auch der eigentliche Schulungsbeginn startete erst 1 Monat vor dem Go-live.

5. Eine konsequentere „No-Customizing"-Haltung

Von den 25 gelben und 15 roten Z-Programmen hätten sich 8–10 vermutlich auch mit einem Best-Practice-Flow lösen lassen. Das Argument „aber wir haben das schon immer so gemacht" wurde manchmal zu leicht akzeptiert.

Worauf sollten Sie achten, wenn Sie jetzt ein S/4HANA-Brownfield-Projekt starten?

Pre-Flight-Checkliste

• Discovery auf 2 Monate geplant (nicht 1)
• Stammdaten-Audit-Skript ausgeführt, Anomalien kategorisiert
• Custom-Code-Audit mit der SAP-App plus manuellem Review
• Alle Integrationsschnittstellen in der Sandbox getestet
• Cutover-Runbook entworfen (ja, bereits in der Discovery-Phase)
• Hyper-Care-Budget für 60 Tage
• Test-Cutover mindestens 2x durchgeführt
• Kommunikationsplan für die User 8 Wochen vor dem Go-live

Budgetpuffer

• +15 % Zeitpuffer für die Stammdatenbereinigung
• +25 % Aufwandspuffer für die Z-Objekt-Umschreibung
• +1 Woche Puffer für die Integrationstests

Offizielle Dokumentationen und weiterführende Lektüre

• SAP S/4HANA Conversion Guide — offiziell
• SAP Custom Code Migration App — Code-Readiness-Analyse
• SAP Readiness Check — Audit vor der Migration
• SAP Activate methodology — Implementierungs-Framework
• Hungarian SAP User Group — Community

Verwandte Artikel von uns: Von Excel zu SAP für KMU — Greenfield-Implementierungs-Roadmap. KI-Implementierung bei ungarischen KMU — Integration von ERP und KI-Pipeline. Wie wir remote arbeiten — Projektmanagement.

Fazit

Eine S/4HANA-Brownfield-Migration ist kein einfaches Projekt. Die Bezeichnung „In-Place-Upgrade" ist irreführend — die Datenmigration und das Custom-Code-Refactoring können bis zu 50 % des Projektaufwands ausmachen.

Die wichtigste Lehre aus diesen anonymisierten Projekterfahrungen: Planen Sie in allen drei kritischen Bereichen einen Puffer ein — Stammdaten, Custom Code, Integration. Keiner davon lässt sich in der Discovery-Phase exakt schätzen, und alle drei benötigen 2- bis 3-mal so viel Zeit, wie die SAP-Tools veranschlagen.

Wenn Sie eine SAP S/4HANA-Migration planen, beginnen wir mit einem Discovery-Call — der erste Monat dient genau der Identifikation dieser Pufferbereiche. Die Discovery-Kosten von 200.000–400.000 HUF ersparen oft einen nachträglichen Scope-Creep von 20–50 Mio. HUF.