Brownfield Greenfield Migration richtig planen

Eine Brownfield Greenfield Migration ist keine reine Systementscheidung. Sie legt fest, wie stark ein Unternehmen Prozesse, Daten, Berechtigungen und Schnittstellen im Zuge der S/4HANA-Transformation verändert. Wer die Wahl allein über Zeitplan oder Lizenzkosten trifft, verschiebt Risiken häufig in Tests, Cutover und den späteren Betrieb. Entscheidend ist daher nicht, welches Vorgehen grundsätzlich besser ist, sondern welches Vorgehen zur Ausgangslage, zum Zielbild und zur verfügbaren Steuerungsfähigkeit passt.

Was Brownfield und Greenfield praktisch unterscheidet

Bei einer Brownfield-Migration wird das bestehende SAP-System technisch und funktional nach S/4HANA überführt. Historische Stamm- und Bewegungsdaten, etablierte Prozesse, Custom Code und viele Integrationen bleiben grundsätzlich erhalten. Anpassungen sind dennoch erforderlich, etwa bei nicht mehr unterstützten Funktionen, Datenmodelländerungen oder der Bereinigung kundeneigener Entwicklungen.

Der Vorteil liegt in der Kontinuität. Fachbereiche arbeiten weitgehend mit bekannten Abläufen weiter, die Transformationsdauer kann geringer sein, und die Übernahme historischer Daten erleichtert Auswertungen. Das ist besonders relevant, wenn der Betrieb wenig Unterbrechung toleriert oder wenn regulatorische Nachweis- und Aufbewahrungspflichten auf gewachsenen Datenbeständen beruhen.

Greenfield beginnt dagegen mit einem neu aufgesetzten S/4HANA-System und einem fachlich definierten Zielprozess. Daten werden gezielt migriert, Prozesse neu modelliert und Integrationen nach dem neuen Architekturprinzip aufgebaut. Das schafft Raum, komplexe Sonderlösungen zu reduzieren und ein konsistenteres Rollen- und Berechtigungsmodell einzuführen.

Dieser Neustart kostet jedoch Steuerungsaufwand. Jeder Prozess, der nicht bewusst entschieden wird, bleibt offen. Jede Datenübernahme braucht klare Kriterien. Und jede Abweichung vom Standard muss fachlich begründet, dokumentiert und in der Betriebsorganisation verankert werden. Greenfield ist deshalb kein automatischer Qualitätsgewinn, sondern eine Transformation mit höherem Gestaltungsanspruch.

Die Brownfield Greenfield Migration anhand von Kriterien entscheiden

Die richtige Entscheidung entsteht aus einer strukturierten Bewertung, nicht aus einer Präferenz für ein bestimmtes Projektmodell. Ausgangspunkt ist die Frage, ob das bestehende System die künftigen Geschäftsanforderungen noch abbilden kann oder ob seine Struktur den Betrieb dauerhaft belastet.

Für Brownfield spricht häufig eine stabile Prozesslandschaft mit begrenztem Veränderungsbedarf. Das gilt etwa für Unternehmen, deren Kernprozesse im Einkauf, in der Produktion oder im Finanzwesen fachlich tragfähig sind und deren Integrationen zuverlässig laufen. Auch ein hoher Bedarf an vollständiger Historie kann das Brownfield-Vorgehen stützen. Dabei sollte allerdings genau geprüft werden, ob historische Daten tatsächlich operativ benötigt werden oder ob revisionssicheres Reporting über ein separates Konzept möglich ist.

Greenfield ist häufig sinnvoll, wenn Prozessvarianten über Jahre unkontrolliert gewachsen sind, Verantwortlichkeiten nicht eindeutig sind oder das Berechtigungsmodell erhebliche Risiken birgt. Gleiches gilt, wenn mehrere Altsysteme konsolidiert werden sollen und kein einheitliches Datenmodell existiert. In diesen Fällen würde eine reine technische Konvertierung bestehende Komplexität in die neue Plattform übertragen.

Eine Zwischenform kann angemessen sein. Selektive Datenmigrationen, die schrittweise Ablösung einzelner Gesellschaften oder Prozesse sowie gezielte Neuimplementierungen erlauben es, Risiko und Veränderungskapazität zu verteilen. Dieses Vorgehen verlangt aber eine besonders klare Architektur- und Governance-Entscheidung. Andernfalls entsteht eine Parallelwelt aus alten und neuen Regeln, deren Betrieb langfristig aufwendiger ist als eine klar abgegrenzte Migration.

Prozessreife vor Systemhistorie bewerten

Viele Programme überschätzen die Bedeutung der technischen Ausgangslage und unterschätzen die Prozessreife. Ein System kann technisch gut wartbar sein, während die fachlichen Abläufe von manuellen Umgehungen, uneinheitlichen Stammdaten oder lokalen Sonderregeln geprägt sind. In einem solchen Fall schützt Brownfield zwar den Zeitplan, aber nicht zwingend die spätere Betriebsfähigkeit.

Umgekehrt ist ein Greenfield-Ansatz nicht erforderlich, nur weil Custom Code vorhanden ist. Entscheidend ist, welche Entwicklungen geschäftskritisch sind, welche durch Standardfunktionen ersetzt werden können und welche Schnittstellen reale Wertschöpfung unterstützen. Eine belastbare Analyse des Custom Codes, der Prozessnutzung und der Datenqualität schafft hierfür eine bessere Entscheidungsgrundlage als pauschale Zielbilder.

Daten, Rollen und Integrationen als Risikofaktoren

Die Migration scheitert selten an einem einzelnen technischen Objekt. Kritisch wird sie dort, wo Datenverantwortung, fachliche Regeln und Systemgrenzen nicht zusammenpassen. Das betrifft vor allem Stammdaten, offene Posten, Materialbewegungen, Kunden- und Lieferanteninformationen sowie die Zuordnung von Belegen zu Organisationseinheiten.

Für Brownfield müssen Unternehmen früh klären, welche Datenbereinigungen vor der Konvertierung erforderlich sind. Eine technische Migration überträgt Datenbestände nicht automatisch in fachlich nutzbare Qualität. Dubletten, inkonsistente Klassifikationen und unvollständige Pflichtfelder wirken nach dem Go-Live weiter - häufig erst sichtbar, wenn Folgeprozesse oder Analysen betroffen sind.

Im Greenfield-Vorgehen liegt der Schwerpunkt auf Migrationsregeln. Welche Daten werden übernommen? Welche Historie bleibt im Altsystem verfügbar? Wer bestätigt die fachliche Richtigkeit der Zuordnung und die Vollständigkeit der Ladeergebnisse? Diese Entscheidungen benötigen Datenverantwortliche mit nachvollziehbaren Freigaben. Ohne sie wird aus einer Datenmigration eine technische Übertragung ohne belastbaren fachlichen Nachweis.

Berechtigungen sollten nicht als nachgelagerter Arbeitsschritt behandelt werden. Besonders bei einer Neuimplementierung ist die Chance groß, Rollen nach tatsächlichen Aufgaben, Funktionstrennung und Genehmigungswegen aufzubauen. Im Brownfield-Fall ist eine Übernahme bestehender Rollen nur dann vertretbar, wenn kritische Berechtigungen geprüft und nicht mehr benötigte Zugriffe bereinigt wurden. Das schützt nicht nur die Informationssicherheit, sondern erleichtert auch revisionssicheres Reporting.

Auch Integrationen benötigen eine eigene Entscheidungslogik. Schnittstellen zu Lager, Produktion, CRM, BI, Banken oder externen Plattformen dürfen nicht allein auf technische Erreichbarkeit getestet werden. Maßgeblich ist, ob Geschäftsvorfälle vollständig, korrekt und rechtzeitig über Systemgrenzen hinweg verarbeitet werden. Datenflussanalysen machen Abhängigkeiten sichtbar und helfen, Verantwortlichkeiten für Fehlerklärung und Monitoring vor dem Go-Live festzulegen.

Tests und Cutover auf das Migrationsmodell ausrichten

Brownfield und Greenfield verlangen unterschiedliche Testschwerpunkte. Bei Brownfield stehen die technische Konvertierung, die Funktionsfähigkeit bestehender Abläufe und die Auswirkungen von Anpassungen auf Schnittstellen im Vordergrund. Regressionstests sind hier zentral, weil kleine Änderungen große Wirkungen in etablierten Prozessketten auslösen können.

Greenfield benötigt stärker fachlich orientierte End-to-End-Tests. Zielprozesse, neue Rollen und Migrationsdaten müssen gemeinsam geprüft werden. Ein einzelner erfolgreicher Modultest reicht nicht aus, wenn ein Auftrag zwar angelegt werden kann, aber die Preisfindung, Lieferung, Fakturierung oder Buchung im Zusammenspiel scheitert.

Ein tragfähiges Testmanagement definiert daher Testobjekte, Testdaten, Verantwortliche, Eintritts- und Austrittskriterien sowie die Behandlung von Defects. Fachbereiche müssen ausreichend Zeit für Abnahme und erneute Tests erhalten. Werden Tests unter Terminruck verkürzt, zeigt sich das Risiko häufig erst im Cutover, wenn Korrekturen nur noch mit hohem Betriebsdruck möglich sind.

Der Cutover-Plan muss die gewählte Migrationsart konkret abbilden. Dazu gehören Sperrzeiten, Datenextraktion und -validierung, technische Umschaltungen, Freigaben, Rückfalloptionen und die Kommunikationswege für kritische Entscheidungen. Besonders wichtig ist ein klarer Entscheidungszeitpunkt: Wer bewertet anhand welcher Kennzahlen, ob der Go-Live erfolgen kann? Ein Cutover ohne dokumentierte Go-No-Go-Kriterien ist keine Steuerung, sondern eine Terminwette.

Governance schafft belastbare Entscheidungen

Die Wahl zwischen Brownfield und Greenfield betrifft IT, Fachbereiche, Datenmanagement, Informationssicherheit und gegebenenfalls Compliance gleichermaßen. Das Projekt benötigt deshalb ein Gremium, das Zielbild, Abweichungen, Risiken und Freigaben verbindlich steuert. Eine Lenkung allein über Statusberichte reicht nicht, wenn Datenübernahmen, Rollenentscheidungen oder Prozessstandards strittig sind.

Sinnvoll sind nachvollziehbare Entscheidungsunterlagen: Prozesslandkarte, Dateninventar, Integrationsübersicht, Risikoanalyse, Migrationsregeln und Testnachweise. Damit werden Entscheidungen auch dann belastbar, wenn Projektbeteiligte wechseln oder Prüfungen nach dem Go-Live Fragen zu Verantwortlichkeiten aufwerfen. Bei Anforderungen aus Datenschutz, NIS2 oder dem EU AI Act - etwa wenn KI-gestützte Funktionen oder sensible Datenflüsse betroffen sind - müssen technische Maßnahmen und rechtliche Einordnung abgestimmt erfolgen.

Messbarer Nutzen zeigt sich nicht allein im erfolgreichen Produktivstart. Entscheidend sind stabile Kernprozesse, nachvollziehbare Datenflüsse, beherrschbare Berechtigungen und eine Betriebsorganisation, die Störungen zügig einordnen und bearbeiten kann. Die Migration ist dann kein einmaliges IT-Ereignis, sondern eine kontrollierte Grundlage für den weiteren Betrieb.

Migrationsentscheidung fundiert vorbereiten

Quteco unterstützt SAP-Transformationsvorhaben mit Quick Checks, Workshops und operativer Projektbegleitung - von der Bewertung der Ausgangslage über Datenflussanalyse und Testmanagement bis zur Cutover-Planung. Eine strukturierte Standortbestimmung schafft vor der Richtungsentscheidung Transparenz über Prozessreife, Datenrisiken und technische Abhängigkeiten. Je früher diese Punkte geklärt sind, desto besser lässt sich der Go-Live als steuerbarer Übergang vorbereiten.