Brownfield oder Greenfield: wie ihr den Weg nach SAP S/4HANA wählt
Die Frage klingt nach Geschmack und ist in Wahrheit eine Rechnung aus Eigenentwicklungen, Datenqualität und dem, was ihr an euren Prozessen noch verteidigen wollt.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Entschieden wird nach Bauchgefühl, obwohl die Zahlen im System liegen
Die Diskussion läuft in fast jedem Haus gleich ab. Der Fachbereich möchte den Neuanfang, weil die Prozesse seit Jahren als hakelig gelten. Die IT möchte die Konversion, weil sie den Bestand kennt und keine Lust auf zwei Jahre Parallelbetrieb hat. Die Geschäftsführung hört zwei Meinungen und entscheidet nach derjenigen, die überzeugender vorgetragen wird. Was in dieser Runde fehlt, sind die drei Zahlen, die im System stehen und in wenigen Tagen erhoben sind: wie viele eigene Objekte es gibt, wie viele davon im letzten Jahr überhaupt aufgerufen wurden und wie sauber die Stammdaten sind.
Falsch in Richtung Konversion entschieden heißt, dass ihr eure Prozessschulden mitnehmt. Alles, was heute umständlich ist, ist es nach dem Umstieg auch, nur auf einer neuen Oberfläche und mit einem Projekt im Rücken, das offiziell abgeschlossen ist. Der Nachbesserungsbedarf taucht dann als Folgeprojekt auf, für das im Budget nichts mehr steht, und das Argument, man habe doch gerade erst umgestellt, blockiert für die nächsten zwei Jahre jede Veränderung.
Falsch in Richtung Neuaufbau entschieden kostet früher und lauter. Ein neues System bedeutet, jeden Prozess noch einmal zu entscheiden, jede Schnittstelle neu anzubinden und historische Daten entweder zu übernehmen oder in einem lesenden Archiv zu halten. Wer das mit derselben Mannschaft macht, die nebenher den laufenden Betrieb trägt, verschiebt den Termin zweimal. Und der Termin ist bei diesem Thema nicht frei wählbar, weil im Hintergrund die Wartungsfristen der SAP Business Suite 7 laufen.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Die Kriterien, an denen die Wahl tatsächlich hängt
Brownfield und Greenfield sind Marktbegriffe. SAP selbst spricht beim ersten Weg vom Conversion Approach, also der Überführung des bestehenden Systems, und beim zweiten von einer Neuimplementierung. Verglichen werden hier die Eigenschaften, die sich in eurem Projekt bemerkbar machen, nicht die Werbebotschaften zu beiden Wegen.
Konversion
das bestehende System wird mit Daten, Customizing und Historie nach SAP S/4HANA überführt, der Eigenbau kommt mit und wird angepasst
Neuaufbau
ein neues System wird auf dem Standard aufgesetzt, Prozesse werden neu entschieden und nur ausgewählte Daten wandern mit
| Entscheidungsfrage | Konversion | Neuaufbau |
|---|---|---|
| Wie schnell steht ein produktives System? | Stärke Customizing, Belegarten, Konditionen und Berichtswesen sind vorhanden und werden übernommen. Die Arbeit steckt in den technischen Anpassungen und im Test, nicht im erneuten Entscheiden fachlicher Fragen, die längst entschieden sind. | Schwäche Jeder Prozess wird noch einmal aufgenommen, entschieden und eingerichtet. Selbst mit vorkonfigurierten Inhalten bleibt die Abstimmung im Fachbereich der bestimmende Posten, und der lässt sich kaum durch mehr Personal verkürzen. |
| Was passiert mit Prozessen, die niemand mehr begründen kann? | Schwäche Sie kommen mit. Das Verfahren fragt nicht, ob eine Einstellung sinnvoll ist, sondern ob sie technisch überführbar ist. Aufräumen ist möglich, aber es ist zusätzliche Arbeit im selben Projekt und wird deshalb gern verschoben. | Stärke Was nicht ausdrücklich neu eingerichtet wird, gibt es nicht mehr. Das ist der eigentliche Ertrag dieses Wegs und zugleich der Grund, warum er im Fachbereich so viel Zeit kostet. |
| Wie geht der Weg mit Eigenentwicklungen um? | Kommt darauf an Der Bestand wandert mit und muss auf die geänderten Datenmodelle angepasst werden, etwa dort, wo direkt auf entfallene Summentabellen zugegriffen wird. Das ist zäh, aber gut planbar, weil sich die betroffenen Stellen im System auflisten lassen. | Kommt darauf an Nichts kommt automatisch mit, jede Erweiterung wird bewusst neu gebaut oder gestrichen. Das ergibt einen sauberen Stand, verlagert aber den gesamten Aufwand nach vorn und trifft ausgerechnet die Objekte, die im Tagesgeschäft gebraucht werden. |
| Wie steht es um Belege und Auswertbarkeit der Historie? | Stärke Die Bewegungsdaten bleiben im System und lassen sich weiter auswerten. Für Prüfungen, Rückfragen und Jahresvergleiche ist das der bequemste Zustand, weil niemand ein zweites System öffnen muss. | Schwäche Übernommen werden üblicherweise Stammdaten, Bestände und offene Posten. Für alles Ältere braucht ihr eine Lösung, sei es ein lesender Zugriff auf das Altsystem oder ein Archiv, und beides will betrieben und im Zweifel geprüft werden. |
| Wie stark belastet der Weg den laufenden Betrieb? | Kommt darauf an Die Belastung ist hoch, aber zeitlich gebündelt: Testzyklen und die Umstellung selbst fallen auf wenige Wochenenden. Dazwischen arbeiten die Fachbereiche weitgehend normal weiter. | Schwäche Die Fachbereiche stellen über Monate hinweg Personen für Aufnahme, Entscheidung und Test ab, und zwar genau die, die auch im Tagesgeschäft unentbehrlich sind. Diese Doppelbelastung ist der häufigste Grund für Terminverschiebungen. |
| Wie nah ist das Ergebnis am Standard? | Kommt darauf an So nah, wie euer Ausgangssystem es war. Der Umstieg bringt zwar die neuen Datenmodelle mit, an der Zahl eurer Sonderwege ändert er aber von sich aus nichts. | Stärke Ihr startet auf dem Standard und weicht nur ab, wo es jemand ausdrücklich beantragt. Das erleichtert spätere Aktualisierungen erheblich, weil weniger eigener Code an SAP-Objekten hängt. |
Wie schnell steht ein produktives System?
Customizing, Belegarten, Konditionen und Berichtswesen sind vorhanden und werden übernommen. Die Arbeit steckt in den technischen Anpassungen und im Test, nicht im erneuten Entscheiden fachlicher Fragen, die längst entschieden sind.
Jeder Prozess wird noch einmal aufgenommen, entschieden und eingerichtet. Selbst mit vorkonfigurierten Inhalten bleibt die Abstimmung im Fachbereich der bestimmende Posten, und der lässt sich kaum durch mehr Personal verkürzen.
Was passiert mit Prozessen, die niemand mehr begründen kann?
Sie kommen mit. Das Verfahren fragt nicht, ob eine Einstellung sinnvoll ist, sondern ob sie technisch überführbar ist. Aufräumen ist möglich, aber es ist zusätzliche Arbeit im selben Projekt und wird deshalb gern verschoben.
Was nicht ausdrücklich neu eingerichtet wird, gibt es nicht mehr. Das ist der eigentliche Ertrag dieses Wegs und zugleich der Grund, warum er im Fachbereich so viel Zeit kostet.
Wie geht der Weg mit Eigenentwicklungen um?
Der Bestand wandert mit und muss auf die geänderten Datenmodelle angepasst werden, etwa dort, wo direkt auf entfallene Summentabellen zugegriffen wird. Das ist zäh, aber gut planbar, weil sich die betroffenen Stellen im System auflisten lassen.
Nichts kommt automatisch mit, jede Erweiterung wird bewusst neu gebaut oder gestrichen. Das ergibt einen sauberen Stand, verlagert aber den gesamten Aufwand nach vorn und trifft ausgerechnet die Objekte, die im Tagesgeschäft gebraucht werden.
Wie steht es um Belege und Auswertbarkeit der Historie?
Die Bewegungsdaten bleiben im System und lassen sich weiter auswerten. Für Prüfungen, Rückfragen und Jahresvergleiche ist das der bequemste Zustand, weil niemand ein zweites System öffnen muss.
Übernommen werden üblicherweise Stammdaten, Bestände und offene Posten. Für alles Ältere braucht ihr eine Lösung, sei es ein lesender Zugriff auf das Altsystem oder ein Archiv, und beides will betrieben und im Zweifel geprüft werden.
Wie stark belastet der Weg den laufenden Betrieb?
Die Belastung ist hoch, aber zeitlich gebündelt: Testzyklen und die Umstellung selbst fallen auf wenige Wochenenden. Dazwischen arbeiten die Fachbereiche weitgehend normal weiter.
Die Fachbereiche stellen über Monate hinweg Personen für Aufnahme, Entscheidung und Test ab, und zwar genau die, die auch im Tagesgeschäft unentbehrlich sind. Diese Doppelbelastung ist der häufigste Grund für Terminverschiebungen.
Wie nah ist das Ergebnis am Standard?
So nah, wie euer Ausgangssystem es war. Der Umstieg bringt zwar die neuen Datenmodelle mit, an der Zahl eurer Sonderwege ändert er aber von sich aus nichts.
Ihr startet auf dem Standard und weicht nur ab, wo es jemand ausdrücklich beantragt. Das erleichtert spätere Aktualisierungen erheblich, weil weniger eigener Code an SAP-Objekten hängt.
Was passt wann
- Wenn eure Prozesse im Kern tragen, der Eigenbau überschaubar ist und der Wartungsstatus in absehbarer Zeit geklärt sein soll
- nehmt die Konversion und plant das Aufräumen als eigenen Schritt danach ein, sonst passiert es nicht.
- Wenn mehrere Systeme zusammengeführt werden, das Customizing über Jahre gewachsen ist und niemand mehr die Gründe kennt
- baut neu auf und legt vorher fest, wie lange ihr das Altsystem für Auskünfte weiterlaufen lasst.
- Wenn der Fachbereich neu anfangen will, aber niemand die Kapazität dafür freistellen kann
- entscheidet euch für die Konversion, denn ein Neuaufbau ohne verfügbare Fachleute wird zur Kopie des Alten, nur teurer.
Fünf Fragen, und der Weg steht fest
- 01 Ist die Customer Vendor Integration eingeführt? Ohne sie kommt die Konversion gar nicht erst in Frage.
- 02 Wie viel eures Eigenbaus wurde im letzten Jahr tatsächlich aufgerufen?
- 03 Wie viele Dubletten und Sonderfälle stecken in den Kunden- und Lieferantenstämmen?
- 04 Für wie viele Abweichungen vom Standard gibt es heute noch ein geschäftliches Argument?
- 05 Sollen mehrere Systeme oder Mandanten zusammengeführt werden? Dann ist es kein Konvertierungsprojekt.
Sechs Erhebungen, nach denen die Wahl feststeht
Keine dieser Erhebungen braucht ein Beratungsprojekt. Sie lassen sich im vorhandenen System oder in einer Kopie davon durchführen, und danach ist die Diskussion in aller Regel entschieden, weil sich zwei bis drei Punkte deutlich in dieselbe Richtung neigen.
Zuerst die harte Bedingung prüfen
Die Prüfungen vor der Konvertierung und das Konvertierungsverfahren selbst kontrollieren, ob die Customer Vendor Integration vollständig eingeführt ist. Ein System ohne CVI wird für den Übergang abgelehnt. Diese Prüfung gehört an den Anfang, weil sie im ungünstigen Fall ein eigenes Vorprojekt auslöst und damit den Zeitplan beider Wege verschiebt.
Den eigenen Codebestand zählen und nach Nutzung sortieren
Interessant ist nicht die Gesamtzahl der Z-Objekte, sondern der Anteil, der im letzten Geschäftsjahr tatsächlich aufgerufen wurde. Erfahrungsgemäß liegt zwischen beiden Zahlen ein erheblicher Abstand, und er ist das stärkste Argument in der Diskussion: Was niemand mehr benutzt, muss weder konvertiert noch nachgebaut werden.
Die Datenqualität an den Stellen messen, die weh tun
Zählt Dubletten in den Kunden- und Lieferantenstämmen, Betriebe, die beides zugleich sind, unterschiedliche Nummernkreise für dasselbe Gegenüber und Sätze ohne Pflichtfelder. Diese Fälle laufen beim Zusammenführen zum Geschäftspartner auf, unabhängig vom gewählten Weg. Der Unterschied ist nur, ob ihr sie im Altsystem oder in der Übernahme aufräumt.
Prüfen, welche Prozesse ihr wirklich verteidigen wollt
Geht die Liste eurer Abweichungen vom Standard durch und markiert die, für die es ein geschäftliches Argument gibt, das jemand heute noch nennen kann. Bleibt wenig übrig, spricht das für den Neuaufbau. Bleibt viel übrig und ist es fachlich begründet, tragt ihr das in beiden Wegen mit, und die Konversion ist dann der kürzere.
Die Landschaft mitdenken, nicht nur das ERP
Wenn mehrere Systeme oder mehrere Mandanten zusammengeführt werden sollen, ist das keine Konvertierungsaufgabe mehr, denn das Verfahren führt ein System in ein Zielsystem über. Die Konsolidierung mehrerer Stände ist ein eigener Vorgang, und sie verschiebt die Rechnung deutlich in Richtung Neuaufbau.
Den Termin von hinten aufziehen
Für die Kernanwendungen der SAP Business Suite 7 leistet SAP Mainstream Maintenance bis Ende 2027, danach gibt es optional bis Ende 2030 eine erweiterte Wartung gegen Aufschlag. Rechnet vom gewünschten Wartungsstatus rückwärts über Testphasen, Jahresabschluss und Urlaubszeiten. Wer damit unter zwölf Monate kommt, hat den Neuaufbau faktisch bereits ausgeschlossen.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Was sich in beiden Wegen ohnehin ändert
Ein Teil der Arbeit fällt an, egal wie ihr euch entscheidet, und genau dieser Teil wird beim Vergleich der beiden Wege regelmäßig übersehen. Der Geschäftspartner ist in SAP S/4HANA das führende und obligatorische Objekt, in dem die früher getrennten Debitoren- und Kreditorenstämme zusammenlaufen. Für Anwender heißt das, dass die Pflege über die Transaktion BP läuft, und die gewohnten Einstiege XD01, VD01, XK01 oder MK01 dort nicht mehr eigenständig existieren, sondern umgeleitet werden.
Im Rechnungswesen liegt die zweite Änderung, die beide Wege betrifft. Das Universal Journal in der Tabelle ACDOCA ist der gemeinsame Belegspeicher, interne und externe Sicht lesen aus derselben Quelle, und die früheren Summensätze in Hauptbuch, Controlling, Material Ledger, Anlagenbuchhaltung sowie Kreditoren- und Debitorenbuchhaltung sind ebenso entfallen wie die Indextabellen, die bestimmte Selektionen beschleunigt haben. Jede Auswertung und jeder Report, der auf diese Tabellen zugreift, ist damit ein Fall für eure Liste, unabhängig vom gewählten Weg.
Dazu kommt das Material Ledger. Es ist in SAP S/4HANA verpflichtend, Teil des Standards und in allen S/4HANA-Systemen automatisch aktiv. Bei der Konvertierung eines bestehenden Systems wird es während der Migration aktiviert, sofern es nicht ohnehin schon läuft. Kommen später Werke hinzu, muss es für diese Bewertungskreise über die Transaktion OMX1 von Hand aktiviert werden. Die Istkalkulation samt Actual Cost Component Split bleibt dagegen optional, und dieser Unterschied ist in Projektrunden oft der Punkt, an dem sich Aufregung in Arbeit auflöst.
Die Simplification List ist eure Aufgabenliste, nicht eure Lektüre
SAP führt die funktionalen Änderungen je Release in der Simplification List. Für SAP S/4HANA 2025 liegt sie in einer Fassung vom Februar 2026 vor und deckt On-Premise und die Private-Variante gemeinsam ab. SAP schreibt sie laufend fort, prüft die Versionsangabe deshalb auf dem Deckblatt eures Exemplars. Das Dokument ist mehrere hundert Seiten stark, und der übliche Fehler besteht darin, es lesen zu wollen.
Sinnvoller ist der umgekehrte Weg. Ihr geht von euren eigenen Objekten und Prozessen aus und schlagt gezielt nach, was zu ihnen dort steht. Jeder Eintrag folgt demselben Muster: Beschreibung der Änderung, betroffene Geschäftsprozesse, Empfehlung und die zugehörige SAP Note. Diese Notes sind die verbindliche Quelle, sie sind allerdings nur mit einem S-User einsehbar, weshalb sie auf Projektseite jemand mit Zugang aufbereiten muss.
Für den Vergleich der beiden Wege ist die Liste doppelt wertvoll. Sie zeigt euch bei der Konversion, welche Anpassungen unvermeidlich sind, und sie zeigt euch beim Neuaufbau, welche Funktionen ihr im Zielbild gar nicht mehr in der gewohnten Form einplanen könnt. In beiden Fällen ersetzt sie die Vermutung durch eine Zeile mit Quellenangabe, und das verändert den Ton in Entscheidungsrunden spürbar.
Die Mischform und warum sie so oft gewählt wird
Zwischen beiden Wegen liegt eine Reihe von Mischformen. Der Grundgedanke ist immer derselbe: Ein System wird neu aufgesetzt, aber es startet nicht leer, sondern übernimmt ausgewählte Teile aus dem Bestand, etwa einzelne Buchungskreise, bestimmte Stammdatenbereiche oder eine begrenzte Historie. Für Häuser mit mehreren Gesellschaften ist das häufig der einzige Weg, der die Termine hält, ohne die gewachsenen Sonderwege eines einzelnen Standorts in die gemeinsame Zukunft zu tragen.
Der Preis dafür ist ein hoher Abstimmungsaufwand und die Notwendigkeit, für jeden Datenbereich einzeln zu entscheiden und diese Entscheidung auch zu dokumentieren. Was übernommen wird, muss fachlich geprüft und technisch abgeglichen werden, und was nicht übernommen wird, braucht eine Antwort auf die Frage, wo man es im Zweifel wiederfindet. Diese Fragen fallen bei den beiden reinen Wegen entweder gar nicht an oder nur einmal.
Für die Entscheidungsrunde ist wichtig, dass die Mischform kein dritter, bequemerer Weg ist. Sie erbt die Prozessdiskussion aus dem Neuaufbau und die Datendiskussion aus der Konversion. Wer sie wählt, sollte das tun, weil die Landschaft es erzwingt, und nicht, weil die Wahl zwischen zwei klaren Wegen unangenehm ist.
Was die Wahl an den Zielvarianten ändert und was nicht
Die Frage nach dem Weg wird gern mit der Frage nach dem Betriebsmodell vermischt, obwohl beide getrennt zu beantworten sind. Für den Betrieb im eigenen Rechenzentrum und für die Private-Variante ist das aktuelle Hauptrelease SAP S/4HANA 2025 beziehungsweise SAP S/4HANA Cloud Private Edition 2025, der derzeit dokumentierte Stand ist der Feature Pack Stack 1 vom Februar 2026. Die Public-Variante zählt nach einem eigenen Schema aus Jahr und Monat, dort führt SAP aktuell das Release 2608.
Für den Weg selbst folgt daraus vor allem eine Einschränkung: Eine Konversion überführt euer bestehendes System, und dieses Verfahren zielt auf die On-Premise- und Private-Welt. Wer auf die Public-Variante will, geht den Weg des Neuaufbaus, weil dort das Systemverhalten, die Erweiterbarkeit und der Aktualisierungstakt vom Standard vorgegeben sind. Diese Reihenfolge lohnt sich zu merken: Erst das Zielbild für Betrieb und Erweiterbarkeit, dann der Weg dorthin.
Bei den Namen ist derzeit Aufmerksamkeit gefragt. SAP führt die Private-Variante auf den Produktseiten inzwischen als SAP Cloud ERP Private, die Public-Variante läuft unter der Dachmarke SAP Cloud ERP. Die Produktnamen SAP S/4HANA Cloud Private Edition und SAP S/4HANA Cloud Public Edition bestehen daneben weiter und werden in der Produktdokumentation nach wie vor verwendet. In Angeboten und Projektpapieren treffen deshalb beide Bezeichnungen aufeinander, ohne dass ein Produktwechsel dahintersteckt.
Dazu passende Kurse
Wenn diese Abwägung ansteht und nicht alle im Projektteam denselben Kenntnisstand mitbringen, sind SAP-Kurse zum Umstieg auf S/4HANA der schnellste Weg zu einer gemeinsamen Grundlage.
Wer den eigenen Codebestand selbst beurteilen will, statt sich auf eine fremde Schätzung zu verlassen, findet bei cmt ABAP-Kurse für die Bewertung des Altbestands .
Wie sicher bist du beim Thema wirklich?
Lesen fühlt sich schnell nach Können an. Ein kurzer Test zeigt dir, was davon schon sitzt und wo sich ein Kurs lohnt. Kostenlos, ohne Anmeldung, mit einer Erklärung zu jeder Antwort.
Wo du genau das übst
Häufige Fragen
Ist die Konversion wirklich billiger als der Neuaufbau?
Was passiert, wenn wir die Customer Vendor Integration noch nicht eingeführt haben?
Können wir zuerst konvertieren und später aufräumen?
Wie lange dauert so ein Projekt?
Müssen wir für die Entscheidung schon wissen, ob wir in die Cloud gehen?
Deine Ansprechpartner
Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.
Yves Hoppe
Weiterbildung & Beratung
Hilft dir, aus dem SAP-Programm den passenden Kurs für deinen Stand zu finden.
Norbert Jansen
Beratung & Inhouse
Plant mit dir Inhouse-Trainings, die auf eure Abläufe und euren Datenbestand zugeschnitten sind.
Die Entscheidung mit dem eigenen System durchspielen
In den S/4HANA-Kursen bei cmt seht ihr an den integrierten Geschäftsprozessen, was sich gegenüber eurem heutigen Stand ändert, und könnt danach beurteilen, welcher Weg zu eurem Haus passt. Die Kurse laufen in Präsenz und Live-Online.