SAP S/4HANA Migration: Build & Migration – Vom Blueprint zur lauffähigen Lösung

movisco Transition Strategie – Wo stehen wir?

Diese Serie begleitet die S/4HANA Migration als End-to-End-Reise entlang der movisco Transition Strategie.

Teil 1 beschreibt Einordnung & Mindset.

Teil 2 vertieft das Assessment und lieferte die Entscheidungsgrundlage.

Teil 3 zeigt: Wie wird aus Assessment-Erkenntnis ein verbindliches, umsetzbares Zielbild.

Teil 4 zeigt: Wie wird ein verbindlicher Blueprint in konfiguriertes System, bereinigten Custom Code und migrierte Daten überführt?

Teil 5 zeigt: Wie wird aus einem fertig gebauten System ein produktiv laufendes – sicher, kontrolliert und mit klarem Fallback?

Kernaussage

Die Realize-Phase ist der Moment der Wahrheit: Hier zeigt sich, ob Blueprint-Entscheidungen tragfähig waren.

Wer Realize als reines Coding-Projekt begreift, scheitert. Wer sie als gesteuertes, iteratives Transformationsprogramm mit klaren Qualitätsgates führt, gewinnt nachhaltig.

Der entscheidende Unterschied: Kontinuierliche Qualitätssicherung, wellenbasiertes Vorgehen und ein konsequentes Transportmanagement – von Sprint 1 bis zum letzten Transport vor dem Cutover.

Zentrale Ergebnisse dieses Teils

Realize-Phase strukturiert nach SAP Activate: Sprints, Backlogs, Qualitätsgates
Customizing-Vorgehen: client-abhängig vs. client-unabhängig, transportiert und dokumentiert
Custom Code Migration: ATC-getriebene Bereinigung, RAP-Modernisierung, Clean-Core-Konformität
Datenmigration: iteratives Vorgehen mit S/4HANA Migration Cockpit und Mock-Konvertierungen
Integrationsentwicklung: von der Spezifikation zum produktiven iFlow in der SAP Integration Suite
Transportmanagement mit ChaRM: lückenloser Audit-Trail von DEV bis PRD
Checkliste und KPIs für die Build-Phase als Go-Forward-Kriterien zur Test-Phase

1. Vom Blueprint zur Realize-Phase: Was sich ändert

Das Assessment hat entschieden. Der Blueprint hat gestaltet. Jetzt beginnt die Realize-Phase – und damit ein fundamentaler Modewechsel im Projekt:

Vergleichstabelle der Blueprint- und Realize-Phase einer SAP S/4HANA-Migration. Gegenübergestellt werden Planung und Konzeption sowie deren Umsetzung durch Customizing, Datenmigration, Integrationen und Governance.

Der Blueprint bleibt das verbindliche Referenzdokument. Jede Abweichung im Realize – ob aus technischen Gründen, geänderten Anforderungen oder neuem Wissen – wird im Blueprint nachgeführt und durch das Architecture Board freigegeben. Ungesteuerter Scope Creep ist der häufigste Risikotreiber in dieser Phase.

Rückbezug zu Teil 3: Der Blueprint hat Clean-Core-Guardrails, SoD-Regeln und Integrationsmuster definiert. In der Realize-Phase werden diese nicht neu verhandelt – sie werden umgesetzt. Ausnahmen benötigen Architecture-Board-Freigabe und eine dokumentierte Begründung.

2. SAP Activate in der Realize-Phase: Sprints, Backlogs, Qualitätsgates

SAP Activate ist das bevorzugte Vorgehensmodell für S/4HANA-Projekte. Die Realize-Phase gliedert sich in iterative Sprints mit klaren Artefakten, Backlogs und Qualitätsgates. Das verhindert "Big Bang"-Übergaben und schafft Transparenz über Fortschritt und Risiken.

Phasengliederung der Realize-Phase

Übersicht der Realize-Phase nach SAP Activate mit Sprint 0, Core Sprints, Integration Sprint, Data Migration Sprint und Cutover Sprint einschließlich Ziele und zentraler Artefakte.

Werkzeuge der Steuerung

SAP Cloud ALM: Anforderungs- und Testmanagement, Deployment-Tracking, Prozessmonitoring – zentrales Projektkockpit
SAP Solution Manager / Focused Build: Alternative zu Cloud ALM; ChaRM für Transportsteuerung, Testmanagement mit CBTA
Backlog-Disziplin: Jede Anforderung hat Akzeptanzkriterien, Blueprint-Referenz und Testfall – kein Transport ohne beides
Sprint Review: Fachbereich nimmt Ergebnisse ab, nicht nur IT – Process Owner ist Pflicht-Teilnehmer

3. Systemlandschaft: Die Infrastruktur der Realize-Phase

Eine stabile, klar definierte Systemlandschaft ist die Voraussetzung für ein geordnetes Realize. Chaos in der Landschaft erzeugt Chaos im Transport.

Übersicht der SAP-S/4HANA-Systemlandschaft in der Realize-Phase mit den Systemen DEV, QAS/INT, PRE/Staging, PRD und Sandbox sowie deren Aufgaben im Build-, Test- und Go-Live-Prozess.

Praxisregel: Ein System-Refresh von PRD auf QAS vor jedem Migrationstest ist keine Kür – er ist Pflicht. Nur mit produktionsnahen Daten lassen sich realistische Laufzeiten, Fehlerquoten und Downtime-Fenster messen.

4. Customizing: Prozesse konfigurieren statt programmieren

Customizing ist die SAP-Standardmethode, um Prozesse an Unternehmensanforderungen anzupassen – ohne Custom Code. In der Realize-Phase wird Customizing systematisch, transportiert und dokumentiert durchgeführt.

Client-abhängiges vs. client-unabhängiges Customizing

Vergleich von client-abhängigem und client-unabhängigem Customizing in SAP S/4HANA mit typischen Konfigurationsobjekten sowie deren Auswirkungen auf Transportmanagement und Systemkonfiguration.

Customizing-Prinzipien in der Realize-Phase

Kein manuelles Customizing in QAS oder PRD: Ausnahmslos über Transportaufträge aus DEV – jede manuelle Änderung in höheren Systemen ist ein Audit-Risiko
Customizing-Dokumentation im Blueprint nachhalten: Änderungen an Blueprint-Entscheidungen werden versioniert; kein "Still im Hintergrund anpassen"
SPRO-Struktur als Leitfaden: Konfiguration folgt der SAP-Implementierungsleitfaden-Struktur; Abweichungen werden begründet dokumentiert
Konfigurationstests unmittelbar nach Transport: Jedes Customizing-Paket wird in QAS sofort durch den zuständigen Process Owner geprüft

5. Custom Code Migration: Bereinigen, modernisieren, absichern

Der ATC-Backlog aus dem Assessment definiert den Arbeitsvorrat. Die Realize-Phase ist keine Zeit für neue Custom-Code-Diskussionen – sie ist die Zeit für saubere Umsetzung des beschlossenen Portfolio-Backlogs.

Dreistufiger Migrationsprozess

ATC-Pflichtlauf vor jedem Transport: Kein Objekt verlässt DEV mit offenen ATC-Fehlern der Kategorie 1 oder 2. ATC-Warnungen (Kategorie 3) sind dokumentiert und priorisiert.
Portfolio-Backlog abarbeiten: Eliminieren → Ersetzen → Modernisieren (In-App/Side-by-Side) in dieser Reihenfolge. Neue Entwicklungen starten immer mit RAP-Prüfung.
Clean-Core-Freigabe vor Go-Live: Keine offenen Kategorie-1-Findings; Architecture Board hat alle Ausnahmen (approved exceptions) formell freigegeben.

ABAP Modernisierung: Von klassisch zu ABAP Cloud

Vergleich zwischen klassischem ABAP und ABAP Cloud mit dem RESTful Application Programming Model (RAP). Die Grafik zeigt den Wandel von direktem Datenbankzugriff, USER-EXITs und Dynpro-Anwendungen hin zu CDS-Views, BAdIs, Fiori-Apps, REST/OData-Schnittstellen und modularer, testbarer Entwicklung.

Wichtig: Nicht jede Entwicklung muss sofort vollständig auf RAP umgestellt werden. In Brownfield-Szenarien ist ein pragmatischer Ansatz realistisch: USER-EXITs mit Architecture-Board-Freigabe bleiben, werden aber als technische Schuld im Backlog geführt und im laufenden Betrieb sukzessive abgelöst. Ziel ist ein Clean-Core-konformes System am Go-Live-Tag – nicht ein theoretisch perfektes System, das nie fertig wird.

6. Datenmigration: Iterativ, gemessen und produktionsnah

Datenmigration ist kein einmaliges Ereignis – sie ist ein iterativer Prozess mit mehreren Mock-Läufen, messbaren Qualitätskriterien und einem klaren Abbruchkriterium. Wer erst am Ende merkt, dass die Daten nicht stimmen, verliert das Go-Live-Fenster.

S/4HANA Migration Cockpit: Das zentrale Werkzeug

Vergleich der Migrationsansätze im SAP S/4HANA Migration Cockpit: Staging-Tabellen, Direct Transfer und Migration Object Modeler mit ihren jeweiligen Einsatzszenarien für die Datenmigration.

Iterationsplan: Von Mock 1 bis zur Produktivmigration

Übersicht des iterativen Datenmigrationsprozesses in einer SAP-S/4HANA-Migration mit den Phasen Mock 1, Mock 2, Mock 3 (Dress Rehearsal) und Produktivmigration einschließlich Ziele und Erfolgskriterien.

SUM/DMO und nZDM: Technische Migrationspfade für Brownfield

Für Brownfield- und Selective-Data-Transition-Szenarien wird die Migration über den Software Update Manager (SUM) mit der Database Migration Option (DMO) durchgeführt. Folgende Optionen stehen zur Verfügung:

Standard-DMO: Einphasige technische Konvertierung; einfach, aber mit vollständiger Downtime
nZDM (Near-Zero Downtime Method): Verkürzt Downtime durch Pre-Processing-Schritte vor dem eigentlichen Upgrade; geeignet für Systeme mit > 1 TB
ZDO (Zero Downtime Option): Vollständig unterbrechungsfreie Konvertierung; nur für spezifische Systemkonfigurationen; erheblicher Aufwand
Downtime-optimized Conversion: Kombination aus SUM-Mechanismen; Ziel: Downtime unter 4 Stunden für mittelgroße Systeme

SAP ILM in der Datenmigration

Bevor die Produktivmigration gestartet wird, müssen die im Blueprint festgelegten Archivierungsobjekte abgearbeitet sein. ILM-Regeln für Aufbewahrungsfristen und DSGVO-konforme Löschung sind vor dem ersten Mock-Lauf im System aktiv – sonst migrieren wir Daten, die wir eigentlich hätten löschen sollen.

7. Integrationsentwicklung: Von der Spezifikation zum produktiven iFlow

Im Blueprint wurden alle Schnittstellen inventarisiert und Zielmuster definiert. In der Realize-Phase werden sie gebaut – systematisch, dokumentiert und mit eingebettetem Monitoring.

Entwicklungsprozess je Schnittstelle

Spezifikation aus Blueprint übernehmen: Schnittstellentyp, Payload-Struktur, Fehlerbehandlung, Security (OAuth2/API-Key), SLA
Integration Flow (iFlow) in SAP CPI entwickeln: Adapter konfigurieren, Mapping definieren, Transformationen implementieren
Unit-Test des iFlow: Synthetische Testdaten, Positivfall und Negativfall (Timeout, Fehler-Response)
Integrationstest in QAS: Reale Gegensysteme, produktionsnahe Datenmengen, End-to-End-Durchlauf
Monitoring-Konfiguration: Alerting bei Fehler, Message-Log aktivieren, Dashboards in Cloud ALM

API-Management: Kontrolle über den Schnittstellenverkehr

SAP API Management (Teil der Integration Suite): Zentrales Gateway für alle API-Zugriffe; Rate Limiting, Authentifizierung, Versionierung
SAP API Business Hub: Katalog aller freigegebenen APIs; Entwickler finden APIs, ohne Systemzugriff zu benötigen
SAP Event Mesh: Eventbasierte Kommunikation für asynchrone Szenarien (z. B. Bestellereignis → Logistikprozess); entkoppelt Systeme temporal

Übersicht typischer Integrationsszenarien in einer SAP-S/4HANA-Migration mit der SAP Integration Suite. Die Grafik zeigt die Umsetzung synchroner und asynchroner Schnittstellen, Inbound- und Outbound-iFlows sowie API- und Event-basierte Integrationen.

8. Wellenbasierte Umsetzung: Komplexität beherrschbar machen

Große S/4HANA-Projekte werden nicht in einem Go-Live realisiert. Eine durchdachte Wellenplanung reduziert Risiken, erlaubt frühzeitiges Lernen und schafft Momentum durch sichtbare Zwischenerfolge.

Kriterien für die Wellenbildung

Prozessabhängigkeiten: Welche Prozesse müssen zuerst stehen (z. B. Finanzgrundkonfiguration vor allen anderen Modulen)?
Risikogewichtung: Einfache, standardnahe Prozesse in Welle 1; komplexe, custom-intensive in späteren Wellen
Organisationsstruktur: Pilotwerk oder Pilotland in Welle 1 – lernen, bevor der Rollout beginnt
Datenabhängigkeiten: Stammdaten (Material, Debitor, Kreditor) immer vor Bewegungsdaten bereitstellen
Integrationsreihenfolge: Interne Schnittstellen vor externen Partnersystemen – interne Fehler sind leichter zu beheben

Übersicht einer wellenbasierten SAP-S/4HANA-Migration mit Foundation, Pilot-, Rollout- und Erweiterungswellen sowie den jeweiligen Go-Live-Kriterien und Projektzielen.

9. Transportmanagement: Geordneter Weg von DEV bis PRD

Transportchaos ist eine der häufigsten Ursachen für Go-Live-Krisen. Ein konsequentes, werkzeuggestütztes Transportmanagement ist kein bürokratischer Overhead – es ist Risikomanagement.

ChaRM: Change Request Management im Solution Manager

Normaler Change: Standardpfad für geplante Entwicklungen; durchläuft DEV → QAS → Freigabe → PRD mit dokumentiertem Genehmigungsprozess
Urgent Change: Für kritische Produktivkorrekturen; verkürzter Genehmigungsprozess mit Eskalation; Pflicht: Dokumentation und Nachtest
Release Management: Transporte werden zu Releases gebündelt; kein Einzel-Transport nach PRD außerhalb eines freigegebenen Releases
Audit Trail: Jeder Transport ist mit Anforderung, Entwickler, Tester und Freigeber dokumentiert – DSGVO- und SOX-konform

Transport-Qualitätsgates

Darstellung des Transportmanagements einer SAP-S/4HANA-Migration mit ChaRM, Transportpfaden von DEV bis PRD sowie Qualitätsgates für Freigabe, Tests und Go-Live.

Goldene Regel: Kein Transport nach PRD ohne dokumentierte Testabnahme und Steering-Committee-Freigabe. Ausnahmen (Urgent Change) werden protokolliert, nachgetestet und im nächsten Sprint regulär nachgeführt.

10. Change Management in der Realize-Phase: Momentum halten

Change Management endet nicht mit dem Blueprint. In der Realize-Phase entscheidet sich, ob die Belegschaft das neue System als Chance oder als Bedrohung erlebt. Sichtbare Fortschritte und frühzeitiges Einbinden der Key User sind die wirksamsten Hebel.

Enablement-Maßnahmen parallel zur Entwicklung

Key-User-Schulung in Sprints: Key User begleiten Sprints aktiv; sie testen nicht nur, sondern verstehen die Lösung von innen – das schafft Multiplikatoren
Sandbox für Exploration: Offener Sandbox-Zugang für Fachbereiche; eigenständiges Ausprobieren reduziert Berührungsängste mit Fiori-Apps
Schulungsunterlagen iterativ erstellen: Kein Big-Bang-Schulungsprojekt am Ende; Dokumentation entsteht sprint-begleitend in Cloud ALM oder SharePoint
Kommunikationsrhythmus: Monatlicher Status-Newsletter an alle Betroffenen; Steering-Committee-Updates; transparente Projektampel
Superuser-Netzwerk: Pro Fachbereich einen Superuser benennen; dieser ist erste Anlaufstelle nach Go-Live und entlastet den Support

Berechtigungs-Rollout vorbereiten

Fiori Business Roles aus dem Blueprint werden in der Realize-Phase konfiguriert, mit Testusern geprüft und mit dem SoD-Konzept abgeglichen. Produktive User-IDs und Rollenzuweisungen werden erst im Cutover aktiviert – nie in einer früheren Phase.

11. Typische Fehler in der Realize-Phase

Die folgenden Fehlerbilder sind in realen S/4HANA-Projekten wiederholt beobachtet worden. Jedes ist vermeidbar – wenn es bekannt ist.

Fehler 1: Blueprint wird nicht mehr gelesen

Projektmuster: Das Blueprint-Dokument wird nach dem Kickoff der Realize-Phase nicht mehr aktiv genutzt. Entwickler und Konfigurationsberater arbeiten "aus dem Kopf" oder auf Basis mündlicher Absprachen. Folge: Architektur-Inkonsistenzen, doppelte Entwicklungen, widersprüchliche Konfigurationen. Das System ist technisch lauffähig, aber nicht das, was entschieden wurde. Gegenmassnahme: Blueprint ist Pflichtlektüre für jeden neuen Sprint. Architecture Board verifiziert bei jedem Sprint Review die Blueprint-Konformität. Abweichungen werden im Architecture Decision Log nachgehalten.

Fehler 2: Datenmigration als letzter Sprint

Projektmuster: Datenmigration wird als "kann man am Ende machen" behandelt. Der erste produktionsnahe Testlauf findet vier Wochen vor dem geplanten Go-Live statt. Folge: Die Fehlerquote aus dem ersten Mock ist so hoch, dass das Go-Live-Datum gefährdet ist. Datenbereinigung unter Zeitdruck führt zu Flüchtigkeitsfehlern, die im Produktivbetrieb sichtbar werden. Gegenmassnahme: Mock 1 beginnt im zweiten Sprint der Realize-Phase – nicht im letzten. Drei vollständige Mock-Läufe mit steigendem Reifegrad sind Pflicht. Abbruchkriterium: Fehlerquote > 5 % im Mock 3 stoppt den Go-Live.

Fehler 3: Scope Creep ohne Governance

Projektmuster: Fachbereiche entdecken in Sprints neue Anforderungen. Diese werden "als kleine Ergänzung" ohne formalen Change-Request eingebaut. Die Liste der "kleinen Ergänzungen" wächst auf 80+ Items. Folge: Projektbudget und -zeitplan explodieren. Qualität sinkt, weil ungeplante Entwicklungen weniger getestet werden. Das ursprüngliche Zielbild ist nicht mehr erkennbar. Gegenmassnahme: Jede neue Anforderung in der Realize-Phase durchläuft das Change-Management-Verfahren (SAP Activate: Change Request). Bewertung: Aufwand, Blueprint-Konformität, Einfluss auf Timeline. Steering Committee entscheidet über Aufnahme oder Verschiebung in Phase 2.

Fehler 4: Transportchaos kurz vor Go-Live

Projektmuster: Alle Teams transportieren in den letzten zwei Wochen vor Go-Live gleichzeitig. Transporte überschreiben sich gegenseitig. Niemand hat den Überblick, welche Objekte in welchem System stehen. Folge: Kritische Konfiguration geht verloren. Fehler, die in QAS behoben waren, tauchen in PRD wieder auf. Cutover muss verschoben werden. Gegenmassnahme: Transport-Freeze zwei Wochen vor dem geplanten Cutover: Nur noch freigegebene Cutover-Transporte. Alle anderen Entwicklungen gehen in Welle 2 oder Post-Go-Live-Backlog. ChaRM-Disziplin gilt ab Sprint 1, nicht erst am Ende.

Fehler 5: Key User werden erst am Ende eingebunden

Projektmuster: Key User werden zum ersten Mal im User Acceptance Test (UAT) zwei Wochen vor Go-Live mit dem System konfrontiert. Folge: Fundamentale Usability-Probleme werden spät entdeckt. Key User sind nicht Multiplikatoren, sondern Kritiker. Akzeptanz im Go-Live ist gering. Support-Aufwand in den ersten Wochen ist enorm. Gegenmassnahme: Key User nehmen ab Sprint 1 an Sprint Reviews teil. Sie testen in der Sandbox eigenständig. Sie erstellen Schulungsunterlagen mit. Sie sind Teilnehmer des Dress Rehearsal – nicht Zuschauer.

12. Checkliste Build & Migration: Quality Gate zur Test-Phase

Alle Punkte dieser Checkliste sollten erfüllt sein, bevor die formelle Test-Phase (Teil 5 der Serie) beginnt. Offene Punkte sind keine Kleinigkeiten – sie sind Risiken mit Namen.

Checkliste für den Abschluss der Build- und Migration-Phase einer SAP-S/4HANA-Migration mit Qualitätskriterien für Systemlandschaft, Datenmigration, Schnittstellen, Transporte, Berechtigungen und Go-Forward-Freigabe.

Tipp: Nutze die Checkliste als Agenda für das Phase-Gate-Meeting vor dem offiziellen Start der Test-Phase.

Offene Punkte werden nicht vertagt – sie werden mit Verantwortlichem und Datum versehen und als Risiko im Steering Committee eskaliert.

13. KPIs für Build & Migration: Messen, was zählt

Fortschritt ohne Messung ist Vermutung. Die folgenden Kennzahlen geben ein objektives Bild des Build-Fortschritts und sind Frühwarnindikatoren für Schieflagen.

Übersicht zentraler KPIs für die Build- und Realize-Phase einer SAP-S/4HANA-Migration, darunter ATC-Findings, Custom-Code-Anteil, Datenmigrationsqualität, Testfortschritt, Schnittstellen, Sprint-Velocity und Transportqualität.

Ausblick: Teil 5 – Test, Cutover & Go-Live

Im nächsten Teil der movisco Transition Strategie rückt die kritischste Phase des gesamten Projekts in den Fokus: Test, Cutover und Go-Live. Wir zeigen, wie ein strukturiertes Testkonzept (Unit, Integration, E2E, UAT, Performance) mit SAP Cloud ALM gesteuert wird, wie der Cutover-Plan mit realistischen Downtime-Fenstern und Fallback-Kriterien aufgebaut ist und was einen kontrollierten, ruhigen Go-Live von einem chaotischen unterscheidet.

Fazit: movisco Transition Strategie – Fazit Teil 4

Build & Migration ist die Phase, in der Entscheidungen Realität werden – und Qualitätsmängel sichtbar. Wer iterativ vorgeht (SAP Activate, Sprints, Mock-Konvertierungen), konsequent transportiert (ChaRM), sauber misst (ATC, Fehlerquoten, KPIs) und die Fachbereiche aktiv einbindet, legt das Fundament für einen stabilen Go-Live. Wer die Realize als reinen Coding-Sprint begreift und Qualitätsgates umgeht, schleppt die Risiken in die Test-Phase – und von dort direkt in den Cutover. Die movisco Transition Strategie behandelt Realize als gesteuertes Transformationsprogramm: mit Governance, Messpunkten und einer klaren Eskalationskultur, die Probleme früh sichtbar macht – bevor sie teuer werden.

Über den Autor

Marcel Peters

Marcel Peters ist Managing Consultant bei der movisco AG am Standort Bonn mit mehrjähriger Berufserfahrung in der Beratung von Banken und Versicherungen und hält einen Bachelor Professional of Trade and Commerce (CCI). Seine IT-Expertise umfasst vor allem die SAP Business Suite SAP S/4HANA, die Migration von SAP ECC / R3, die Implementierung von SAP FI/CO und SD/MM in Banken, die Stabilisierung und den Betrieb von SAP S/4HANA, sowie die fachliche und technische Beratung im Bereich FINREP-konformer Meldungen. Seine analytische Expertise basiert vor allem auf jahrelanger Erfahrung in den Bereichen HGB, IFRS 9 und IFRS 17.