Eine SAP S/4HANA Brownfield Migration (auch System Conversion von SAP ECC nach S/4HANA) gilt als schneller Weg in die S/4-Welt: Prozesse bleiben weitgehend bestehen und historische Daten werden übernommen. Genau deshalb wird Brownfield oft als „technisches Upgrade“ geplant.
In der Praxis ist eine Conversion jedoch mehr als Technik. Sie berührt den Kern von Finance, die Datenqualität, Custom Code, Integrationen, Berechtigungen und die Stabilität des Monatsabschlusses. Wer diese Themen früh und strukturiert angeht, reduziert Test- und Go-Live-Risiken deutlich – und sorgt für sauberes Reporting, stabile Abschlüsse und bessere Performance.
Brownfield passt gut, wenn:
Die häufigsten Stolpersteine:
Erfolgsprinzip:
Brownfield ist schnell – wenn Finance-Risiken, Datenqualität und Custom Code früh in ein klares Vorgehen und eine robuste Teststrategie übersetzt werden.
Bei einer Brownfield Migration handelt es sich um die System Conversion eines bestehenden SAP ECC Systems nach SAP S/4HANA. Im Gegensatz zu Greenfield werden typischerweise Customizing, Stammdaten und Transaktionshistorie weitgehend übernommen.Vorteile: schnellere Umsetzung, Kontinuität, weniger Prozessneudesign
Nachteil: historische Altlasten und Inkonsistenzen werden ebenfalls mitgenommen – und führen in S/4HANA häufig zu Problemen, die vorher „kaschiert“ waren.
In vielen ECC-Systemen haben sich über Jahre Workarounds, Sonderfälle und inkonsistente Stammdaten etabliert. Operativ hat das funktioniert, weil sich Fachbereiche angepasst haben.
In S/4HANA greifen jedoch häufig strengere Konsistenzlogiken, neue Prüfungen und ein transparenteres Datenmodell (z. B. Universal Journal). Eine Conversion wirkt daher wie ein Röntgengerät: Fehler werden im integrierten Test, in Abstimmungen oder im Monatsabschluss plötzlich sichtbar.
Typische Symptome im Projekt:
Best Practice: Datenqualität nicht erst „in Tests“ behandeln, sondern früh als eigenes Arbeitspaket planen (Ownership, Regeln, Maßnahmen, Nachverfolgung).
Ein besonders typischer Problemcluster in Brownfield-Projekten sind historische FI-AA-Daten: Anlagen werden über Jahre durch Org-Änderungen, Systemanpassungen oder frühere Migrationen „mitgeschleppt“. Dadurch entstehen u. a.:
In S/4HANA kann das schnell in Abschreibungsläufen, im Closing, bei Audit-Anforderungen oder bei FI/CO-Abstimmungen auffallen.
Archivierung als Hebel: weniger Volumen, weniger Komplexität
Ein Archivierungsprojekt vor der Conversion kann sinnvoll sein, wenn das Datenvolumen hoch ist oder die Historie unnötig viel Komplexität mitbringt. Weniger Daten bedeutet häufig:
Ein weiterer kritischer Punkt ist die Finanzarchitektur im Ausgangssystem – besonders bei historisch gewachsenen NewGL- und Ledger-Setups. Häufige Ausgangslagen:
Das macht eine Conversion riskant, weil Erfolg nicht nur „technisch“ ist. Entscheidend ist, ob nach Go-Live:
Empfehlung: Ledger-/Bewertungslogik früh analysieren, dokumentieren und in einen klaren Zielzustand überführen – bevor die Conversion die Themen verschärft.
Brownfield wird gern als „minimaler Change“ verkauft – aber Z-Entwicklungen sind oft der Haupthebel für Risiken und Budget. ECC-Landschaften enthalten häufig:
In S/4HANA ändern sich Datenmodelle und Zugriffspfade. Dadurch kann schon eine kleine Abhängigkeit Prozesse brechen oder Performance verschlechtern.
Praxisregel: Nicht „alles prüfen“, sondern früh priorisieren:
Viele Brownfield-Projekte verlieren Zeit, weil Tests zu spät oder zu unstrukturiert geplant werden. Auch wenn Prozesse „gleich bleiben“, kann sich das Systemverhalten ändern – besonders in:
Eine robuste Teststrategie ist daher kein Add-on, sondern Voraussetzung für einen stabilen Go-Live. Und der Cutover muss realistisch sein: Qualität entsteht nicht durch Tempo, sondern durch stabile kritische Abläufe.
Auch bei Brownfield merken Anwender Veränderungen: Fiori, Rollen, Suche, Felder, Navigation, Benutzerführung. Wenn Kommunikation nur „alles bleibt wie früher“ sagt, entsteht nach Go-Live unnötige Reibung.
Schlanker Enablement-Ansatz:
1) Finance & Daten (vor Build/Test)
2) Technik & Custom Code
3) Test & Cutover
4) Adoption & Betrieb
Eine SAP S/4HANA Brownfield Migration ist ein starker Weg, wenn Geschwindigkeit, Kontinuität und die Übernahme historischer Daten wichtig sind. Der Erfolg hängt jedoch davon ab, ob typische Risiken früh entschärft werden: Datenqualität ist der Kern, FI-AA Altlasten sind ein häufiger Hebel für Probleme, und Ledger/NewGL-Logik muss vorab sauber verstanden und in einen Zielzustand gebracht werden. Dazu kommen Custom Code und Integrationen als „leise“ Showstopper.
Wer diese Themen strukturiert vorbereitet und mit einer belastbaren Test- und Cutover-Logik verbindet, erreicht eine stabile System Conversion – und eine S/4HANA-Basis, die im Betrieb wirklich trägt.
