Die technische Grundlage ist der eigentliche Bruch mit der Vergangenheit. Klassische ERP-Systeme trennen die Daten für das Tagesgeschäft (Transaktionen) und die Daten für Auswertungen (Analytik) in separate Tabellen und oft sogar in separate Systeme — Reporting läuft nachts in Batches. SAP S/4HANA hingegen hält die Daten komplett im Arbeitsspeicher (In-Memory) und spaltenorientiert, sodass Transaktion und Auswertung auf demselben Datenbestand in Echtzeit stattfinden. Das ermöglicht ein radikal vereinfachtes Datenmodell: Wo ECC in der Finanzbuchhaltung Dutzende Aggregats- und Index-Tabellen pflegte, führt S/4HANA das Universal Journal (Tabelle ACDOCA) als eine einzige Quelle der Wahrheit für Finanzwesen und Controlling.
Für Anwenderinnen und Anwender ist die sichtbarste Neuerung die SAP-Fiori-Oberfläche: rollenbasierte, web- und mobiltaugliche Kacheln statt der klassischen SAP-GUI-Transaktionscodes. Hinzu kommen eingebettete Analytik, ein wachsendes Angebot an KI- und Automatisierungsfunktionen (in jüngeren Releases unter anderem über den KI-Assistenten Joule) sowie die Auslagerung von Erweiterungen auf die SAP Business Technology Platform (BTP). Das Ziel dahinter trägt einen eigenen Namen: Clean Core — der ERP-Kern soll möglichst standardnah und unmodifiziert bleiben, damit Updates und Cloud-Betrieb dauerhaft funktionieren.
Der Begriff „In-Memory“ wird oft als Marketing missverstanden, hat aber konkrete betriebswirtschaftliche Folgen. Weil aggregierte Kennzahlen nicht mehr vorberechnet und gespeichert, sondern bei Bedarf direkt aus den Belegen errechnet werden, entfällt ein großer Teil der Redundanz. Monatsabschlüsse, Bestandsbewertungen oder Deckungsbeitragsrechnungen lassen sich potenziell auf Knopfdruck und auf der jeweils aktuellen Datenbasis durchführen, statt auf einem Stand von gestern Nacht. Das verändert weniger die einzelne Buchung als vielmehr die Steuerungslogik eines Unternehmens: Management-Reporting wird vom periodischen Rückblick zum laufenden Instrument.
Gleichzeitig ist diese Architektur anspruchsvoll. S/4HANA setzt zwingend die HANA-Datenbank voraus — andere Datenbanken werden nicht unterstützt. Wer von ECC kommt, wechselt also nicht nur die Anwendung, sondern in aller Regel auch die Datenbankplattform, häufig den Server- und Hosting-Ansatz und nicht selten das Bedienkonzept. Genau diese Bündelung macht den Umstieg zu einem Transformationsprojekt und nicht zu einem reinen technischen Upgrade.
Ein zweiter, oft unterschätzter Effekt des vereinfachten Datenmodells betrifft die Datenhaltung selbst. Indem redundante Aggregat- und Indextabellen entfallen, schrumpft der Datenbestand vieler Systeme spürbar, was wiederum Wartung, Backup und Performance erleichtert. Diese Verschlankung ist allerdings kein Selbstläufer: Sie wirkt nur dann, wenn die migrierten Daten sauber sind. Wer Altlasten und Dubletten unbesehen übernimmt, verschenkt einen guten Teil des architektonischen Vorteils — ein erster Hinweis darauf, dass die Datenqualität in jedem S/4HANA-Vorhaben eine zentrale Rolle spielt, lange bevor über Funktionen oder Oberflächen gesprochen wird.
SAP ECC ist über Jahrzehnte in tausenden Unternehmen tief in die Prozesse eingewachsen. Diese Systeme sind oft stark angepasst, hochverfügbar und geschäftskritisch — und genau deshalb schwer abzulösen. Der angekündigte Wartungshorizont für ECC (siehe Kapitel 03) macht den Wechsel jedoch für den Großteil der Bestandskunden zur Frage des „Wann“, nicht des „Ob“. Das erklärt, warum S/4HANA 2026 weniger als einzelnes Produkt diskutiert wird, sondern als Migrationswelle eines kompletten Marktsegments.
Dieser Beitrag ordnet S/4HANA herstellerneutral ein: Editionen und Betriebsmodelle (Kapitel 02), der Planungsrahmen rund um das ECC-Wartungsende (Kapitel 03), die Migrationsstrategien Greenfield, Brownfield und Bluefield (Kapitel 04), die oft unterschätzten Gesamtkosten (Kapitel 05), der ehrliche Marktvergleich mit Microsoft Dynamics, Oracle und Mittelstands-ERP (Kapitel 06), die Eignung im gehobenen Mittelstand (Kapitel 07), Risiken und Stärken (Kapitel 08), ein praxistauglicher Fahrplan (Kapitel 09) und häufige Fragen (Kapitel 10). Ziel ist nicht, für oder gegen SAP zu werben, sondern eine fundierte Entscheidungsgrundlage zu liefern.
Die drei Editionen unterscheiden sich vor allem im Spannungsfeld zwischen Standardisierung und Individualisierung sowie in der Frage, wer den Betrieb verantwortet.
Die S/4HANA Cloud Public Edition ist ein echtes mehrmandantenfähiges SaaS-Modell. SAP betreibt das System, liefert in festen Zyklen neue Releases und gibt einen weitgehend standardisierten Funktionsumfang vor. Eigene Erweiterungen sind nur über definierte, „cloud-konforme“ Schnittstellen möglich (Clean Core). Vorteile sind schnellere Einführung, niedrigerer Betriebsaufwand und planbare Updates; der Preis ist eine geringe Individualisierbarkeit und der Zwang, eigene Prozesse an den Standard anzupassen.
Die S/4HANA Cloud Private Edition ist im Kern das vollwertige, hochgradig anpassbare S/4HANA, das jedoch in einer dedizierten Cloud-Umgebung betrieben wird (häufig auf einer Hyperscaler-Infrastruktur, gemanagt durch SAP oder einen Partner). Sie spricht Unternehmen an, die viele bestehende Anpassungen mitnehmen müssen und mehr Kontrolle über Release-Zeitpunkte wollen, aber dennoch nicht selbst Rechenzentren betreiben möchten.
Die On-Premise-Edition wird im eigenen oder einem dedizierten Rechenzentrum betrieben und klassisch lizenziert. Sie bietet maximale Datenhoheit, volle Kontrolle über Anpassungen und Update-Zeitpunkte — und verlangt im Gegenzug den höchsten Eigenaufwand für Infrastruktur, Betrieb und Wartung. Sie ist typisch für stark regulierte Branchen oder Konzerne mit eigener IT-Tiefe.
RISE und GROW sind keine eigenen Editionen, sondern kommerzielle Programme und Bündel, die SAP um die Editionen herum geschnürt hat. Sie sorgen regelmäßig für Verwirrung, weil sie technische und vertragliche Ebenen vermischen.
RISE with SAP ist das Angebot für die Transformation bestehender (meist ECC-)Kunden. Es bündelt in der Regel die S/4HANA Cloud Private Edition mit Infrastruktur, Betrieb, Tools und Migrationsunterstützung in einem Abonnement — gedacht als „Business Transformation as a Service“. GROW with SAP adressiert dagegen Neukunden und den Mid-Market mit der Public Edition und einem auf schnelle Standardeinführung ausgelegten Paket aus Software, Best-Practice-Prozessen und Aktivierungsleistungen.
Eine grobe Faustregel hilft beim ersten Sortieren: Wer überwiegend Standardprozesse fährt, wenig zwingende Eigenentwicklung hat und Wert auf geringen Betriebsaufwand legt, fühlt sich in der Public Edition oft gut aufgehoben. Wer dagegen über Jahre gewachsene, geschäftskritische Eigenentwicklungen besitzt oder die Kontrolle über Release-Zeitpunkte braucht, landet eher bei der Private Edition oder On-Premise. Diese Entscheidung sollte aber nicht aus dem Bauch, sondern aus einer dokumentierten Bewertung von Prozessen, Anpassungstiefe, Datenschutzanforderungen und TCO fallen — sie ist später nur mit erheblichem Aufwand revidierbar.
Wichtig ist außerdem, die Editionswahl nicht mit der Migrationsstrategie zu verwechseln. Beide Entscheidungen hängen zusammen, sind aber nicht identisch: Die Edition legt fest, wie das System künftig betrieben und angepasst wird, die Migrationsstrategie (Kapitel 04), wie man von der Ausgangslage dorthin gelangt. So kann ein Unternehmen die Public Edition anstreben und sie über einen Greenfield-Neuaufbau erreichen, während ein anderes die Private Edition wählt und sein bestehendes ECC per Brownfield konvertiert. Werden beide Fragen sauber getrennt und bewusst beantwortet, sinkt das Risiko, sich frühzeitig in eine Sackgasse zu manövrieren.
Auch das Thema Datenhoheit verdient differenzierte Betrachtung. Cloud-Editionen bedeuten nicht automatisch einen Verlust an Souveränität, ebenso wenig wie On-Premise automatisch volle Sicherheit garantiert. Entscheidend sind die konkreten vertraglichen und technischen Rahmenbedingungen: Wo liegen die Daten, wer hat Zugriff, wie ist die Verschlüsselung geregelt, welche Zertifizierungen liegen vor. Gerade in regulierten Branchen lohnt es sich, diese Punkte vor der Editionsentscheidung mit den eigenen Datenschutz- und Compliance-Verantwortlichen abzustimmen, statt sie nachträglich auf eine bereits getroffene Wahl draufzusatteln.
SAP hat das Ende der Mainstream-Wartung für die Kernanwendungen der Business Suite (ECC) auf das Jahr 2027 terminiert, mit der Option einer kostenpflichtigen erweiterten Wartung, die je nach Konstellation näherungsweise bis etwa 2030 reicht. Diese Daten sollten als grober Planungsrahmen verstanden werden, nicht als in Stein gemeißelte, für jeden Vertrag identische Zusage: Fristen, Bedingungen und Aufschläge sind in der Vergangenheit angepasst worden und hängen vom konkreten Release, Wartungsvertrag und gewählten Programm ab. Verlässlich ist daher nur eine Aussage: Der Bestand muss sich auf einen Übergang vorbereiten, und der zeitliche Korridor ist endlich.
Das Wartungsende bedeutet nicht, dass ein ECC-System am Stichtag aufhört zu funktionieren. Es bedeutet, dass es ohne erweiterte Wartung keine regulären Sicherheits- und gesetzlichen Anpassungen mehr erhält. Für ein geschäftskritisches System, das Steuerlogik, Compliance-Vorgaben und sicherheitsrelevante Korrekturen braucht, ist das ein erhebliches Risiko. Hinzu kommt ein praktischer Engpass: Je näher der Korridor rückt, desto knapper werden erfahrene Beratungskapazitäten und desto voller die Projektpipelines. Wer früh plant, hat die größere Auswahl an Partnern, Personal und Zeitfenstern.
Gleichzeitig ist der Migrationsdruck kein Grund für Hektik. Ein überstürztes Projekt ohne saubere Prozess- und Datenbasis ist oft teurer und riskanter als ein gut vorbereiteter Umstieg mit etwas mehr Vorlauf. Sinnvoll ist, die eigene Ausgangslage früh zu analysieren (Readiness-Check, Anpassungsinventur, Datenqualität), daraus einen realistischen Zeit- und Budgetrahmen abzuleiten und die erweiterte Wartung gegebenenfalls bewusst als Puffer einzukalkulieren — als bezahlte Verlängerung des Entscheidungsfensters, nicht als Dauerlösung.
Beim Greenfield-Ansatz wird S/4HANA als neues System aufgesetzt, Prozesse werden anhand von Best Practices neu modelliert, und nur ausgewählte Stammdaten und Salden werden übernommen. Der Charme liegt im sauberen Neuanfang: Altlasten, historisch gewachsene Eigenentwicklungen und obsolete Prozesse fallen weg, das System startet standardnah und damit gut wartbar. Der Preis ist ein höherer Aufwand im Prozess-Redesign und im Change Management — die Organisation muss sich auf neue Abläufe einlassen. Greenfield passt besonders, wenn die Altprozesse ohnehin reformbedürftig sind oder die Public Edition mit ihrem Standardanspruch das Ziel ist.
Beim Brownfield-Ansatz (Systemkonvertierung) wird das bestehende ECC-System technisch nach S/4HANA überführt: Prozesse, Anpassungen und historische Daten bleiben weitgehend erhalten, die Architektur wird auf HANA und das neue Datenmodell umgestellt. Vorteil ist die größere Kontinuität und der oft kürzere Projektzeitraum, weil das Rad nicht neu erfunden wird. Nachteil ist, dass man Altlasten mitnimmt: technische Schulden, nicht mehr benötigte Anpassungen und veraltete Prozesse wandern mit ins neue System — und gefährden mittelfristig das Clean-Core-Ziel. Brownfield passt, wenn die bestehenden Prozesse gut sind und Eigenentwicklung geschäftskritisch ist.
Der Bluefield-Ansatz (oft als „selektive Datenmigration“ oder hybrider Weg bezeichnet) kombiniert beides: Man setzt ein neues S/4HANA auf, übernimmt aber gezielt ausgewählte Prozesse, Anpassungen und historische Daten aus dem Altsystem. So lassen sich bewährte Teile retten und Ballast abwerfen, ohne komplett bei null zu starten. Der Ansatz ist mächtig, aber anspruchsvoll: Er verlangt eine klare Entscheidung darüber, was übernommen wird und was nicht, sowie geeignete Migrationswerkzeuge. Bluefield passt für Organisationen, die selektiv modernisieren wollen und die Komplexität eines differenzierten Vorgehens beherrschen.
In der Praxis sind die Übergänge fließend, und reale Projekte mischen die Ansätze häufig. Ein Unternehmen kann etwa den Finanzbereich greenfield-artig neu aufsetzen, weil dort ohnehin Reformbedarf besteht, während es die gut funktionierende Logistik weitgehend konvertiert. Entscheidend ist weniger das Etikett als die zugrunde liegende Logik: Wie viel Erneuerung will und braucht die Organisation, wie viel Kontinuität ist geschäftskritisch, und welches Risiko ist sie bereit zu tragen? Eine fundierte Antwort entsteht erst nach einer ehrlichen Bestandsaufnahme, nicht aus einer methodischen Vorliebe.
Eine in der Praxis verbreitete Faustregel besagt, dass die gesamten Projektkosten einer S/4HANA-Einführung das Drei- bis Fünffache der reinen Lizenz- bzw. Abokosten erreichen können. Diese Spanne ist keine exakte Zahl, sondern eine Erfahrungs-Orientierung — der tatsächliche Faktor hängt stark von Migrationsstrategie, Anpassungstiefe, Datenqualität und Organisationsreife ab. Entscheidend ist die Botschaft dahinter: Wer nur die Software-Konditionen verhandelt und die Umsetzung „nebenbei“ einplant, unterschätzt das Projekt strukturell.
Zu den oft übersehenen Kostenblöcken gehören:
Eine saubere TCO-Betrachtung trennt zwei Dimensionen. Die Projektkosten fallen einmalig für die Einführung an (Beratung, Migration, Schulung). Die laufenden Kosten begleiten den Betrieb dauerhaft: Abogebühren oder Wartung, Infrastruktur, internes Betriebsteam, regelmäßige Release-Adaptionen und Weiterentwicklung. Cloud-Editionen verschieben das Verhältnis tendenziell weg von hohen Anfangsinvestitionen hin zu planbaren, aber dauerhaften Abokosten — über mehrere Jahre summiert sich das. Beide Dimensionen gehören über einen realistischen Zeithorizont (typischerweise mehrere Jahre) zusammen betrachtet, sonst täuscht der erste Eindruck.
Echte Hebel liegen weniger im Drücken der Lizenzkonditionen als in der Vorbereitung: Eine ehrliche Anpassungsinventur reduziert Aufwand (jede nicht migrierte Eigenentwicklung spart Geld), gute Datenqualität verkürzt die Migration, und konsequente Standardnutzung senkt sowohl Projekt- als auch spätere Betriebskosten. Falsch gespart wird dagegen typischerweise an Tests, Schulung und Change Management — genau dort, wo unterlassene Investitionen sich später als Produktivitätsverlust, Fehler und Akzeptanzprobleme rächen.
Bei der Budgetierung empfiehlt sich, neben den genannten Blöcken auch die internen Personalkosten ehrlich zu beziffern. Sie tauchen in keinem Angebot eines Beratungshauses auf, sind aber real: Projektleitung, Key User, Fachbereichsverantwortliche und IT binden über Monate erhebliche Arbeitszeit, die andernorts fehlt. Wer diese Kapazität nicht freistellt, finanziert sie unsichtbar über Überstunden, verschobene Aufgaben und sinkende Datenqualität — meist teurer als eine geplante Entlastung. Eine belastbare TCO-Rechnung macht deshalb auch den internen Aufwand sichtbar, statt ihn als kostenlos zu behandeln.
Ein zweiter, häufig vernachlässigter Posten ist der Betrieb nach dem Go-live. Mit der Produktivsetzung endet das Projekt, nicht aber die Investition: Release-Wechsel müssen eingearbeitet, Erweiterungen gepflegt, Anwender weiter geschult und neue Anforderungen umgesetzt werden. Cloud-Editionen verlagern hier Aufwand zum Anbieter, schaffen aber dauerhafte Abokosten; On-Premise spart Abogebühren, verlangt aber ein eigenes, kontinuierlich gepflegtes Betriebsteam. Welche Variante über fünf bis sieben Jahre günstiger ist, lässt sich nur durch eine vollständige Lebenszyklus-Betrachtung beantworten — nicht durch den Vergleich der Anfangsangebote.
Im oberen Marktsegment konkurriert S/4HANA vor allem mit Microsoft Dynamics 365 und Oracle (Oracle Fusion Cloud ERP sowie NetSuite im Mid-Market). Microsoft punktet häufig mit enger Integration in das Microsoft-Ökosystem (Microsoft 365, Power Platform, Azure), einer oft als zugänglicher empfundenen Oberfläche und einer im Mittelstand starken Partnerlandschaft. Oracle bringt eine konsequente Cloud-Architektur und breite Suite-Abdeckung mit. SAP S/4HANA wiederum gilt traditionell als stark bei komplexen, branchentiefen und international vielschichtigen Prozessen — etwa in Fertigung, Supply Chain und konzernweitem Finanzwesen — und besitzt die größte installierte Basis im DACH-Großkundensegment.
S/4HANA spielt seine Stärken aus, wenn mehrere dieser Faktoren zusammenkommen: hohe Prozesskomplexität, internationale Mehrgesellschaftsstrukturen mit anspruchsvollen Konsolidierungs- und Compliance-Anforderungen, tiefe Fertigungs- oder Supply-Chain-Prozesse, eine bereits vorhandene SAP-Landschaft (insbesondere ein abzulösendes ECC) und die Bereitschaft, in ein langfristiges, strategisches Kernsystem zu investieren. In diesen Konstellationen ist die Funktionstiefe ein echter Vorteil, und der hohe Aufwand rechnet sich über die Lebensdauer.
Umgekehrt ist S/4HANA für viele kleine und mittlere Unternehmen schlicht überdimensioniert — und das sollte man offen sagen. Wenn die Prozesse überschaubar und weitgehend standardisierbar sind, das Budget für ein mehrstelliges Beratungsvolumen fehlt, keine eigene IT-Tiefe vorhanden ist oder schlicht eine schlanke, schnell nutzbare Lösung gesucht wird, ist ein spezialisiertes Mittelstands-ERP oder eine schlankere Cloud-Suite (auch aus dem SAP-Portfolio, etwa SAP Business One für kleinere Unternehmen, oder Wettbewerbsprodukte) in aller Regel die wirtschaftlichere und schneller wirksame Wahl. Eine ERP-Entscheidung sollte dem tatsächlichen Bedarf folgen, nicht dem Markennamen.
Der gehobene Mittelstand ist für SAP ein strategisch wichtiges Wachstumssegment, und Programme wie GROW with SAP (Public Edition) sind erkennbar darauf zugeschnitten, diesen Unternehmen einen schnelleren, standardisierten Einstieg zu bieten. Viele dieser Firmen betreiben bereits SAP (oft ECC) und stehen vor derselben Migrationsfrage wie Konzerne — nur mit kleinerer IT-Mannschaft und engerem Budget. Für sie ist die Editionswahl besonders folgenreich: Die Public Edition verspricht geringeren Betriebsaufwand, verlangt aber die Bereitschaft, eigene Prozesse an den Standard anzupassen.
Hier liegt der entscheidende kulturelle Punkt. Mittelständische Unternehmen verstehen ihre individuellen Prozesse häufig als Wettbewerbsvorteil — und tun sich entsprechend schwer, diese zugunsten des SAP-Standards aufzugeben. Doch jede beibehaltene Eigenheit erhöht Aufwand und Betriebskosten und gefährdet die Update-Fähigkeit (Clean Core). Erfolgreiche Mittelstandsprojekte trennen daher konsequent zwischen den wenigen Prozessen, die wirklich differenzieren und Individualität rechtfertigen, und der Mehrheit der Prozesse, die ohne Schaden standardisiert werden können. Diese Übung ist anstrengend, aber sie ist der eigentliche Hebel für ein wirtschaftliches Projekt.
Mittelständler unterschätzen häufig, wie viel internes Engagement ein S/4HANA-Projekt bindet: Fachbereiche müssen Prozesse beschreiben, Tests durchführen und neue Abläufe lernen, parallel zum Tagesgeschäft. Externe Beratung kann viel abnehmen, aber nicht die Entscheidungen und das Prozesswissen. Wer hier keine Kapazitäten freistellt, riskiert Verzögerungen, schlechte Datenqualität und Akzeptanzprobleme. Eine ehrliche Ressourcenplanung — inklusive der Frage, ob das Projekt überhaupt jetzt gestemmt werden kann — gehört zu den ersten Schritten und nicht ans Ende.
Eng damit verbunden ist die Wahl des richtigen Umsetzungspartners. Gerade im Mittelstand entscheidet die Qualität des Beratungs- und Implementierungspartners oft stärker über den Projekterfolg als die Edition selbst. Hilfreich sind Partner mit nachweisbarer Erfahrung in der eigenen Branche und Unternehmensgröße, die nicht nur das System kennen, sondern auch die typischen Prozesse und die Realität knapper interner Ressourcen. Ein Partner, der konsequent zum Standard rät und individuelle Sonderwünsche kritisch hinterfragt, schützt das Budget besser als einer, der jeden Wunsch erfüllt — auch wenn das im Verkaufsgespräch zunächst weniger angenehm klingt.
Schließlich lohnt sich für den gehobenen Mittelstand ein nüchterner Blick auf die Alternativen. Nicht jedes SAP-Bestandsunternehmen muss zwingend bei SAP bleiben; ein ERP-Wechsel ist ein guter Anlass, den Markt herstellerneutral zu sichten. Für viele bleibt S/4HANA die naheliegende und sinnvolle Wahl, gerade wenn bereits SAP-Know-how und -Prozesse vorhanden sind. Andere stellen fest, dass ein schlankeres System ihren Bedarf besser trifft. Diese Frage offen zu prüfen, statt sie aus Gewohnheit zu überspringen, ist Teil einer seriösen Entscheidungsvorbereitung.
Die gefährlichste Falle heißt Customizing. In der ECC-Welt war es üblich, das System bis ins Detail an eigene Wünsche anzupassen — mit der Folge, dass Updates aufwendig und riskant wurden und sogenannte technische Schulden entstanden. S/4HANA setzt dem das Clean-Core-Prinzip entgegen: Der Kern bleibt standardnah, Erweiterungen wandern auf die BTP und nutzen definierte Schnittstellen. Wer diese Disziplin aufgibt und den Kern wieder „zubaut“, verliert genau die Vorteile (einfache Updates, Cloud-Fähigkeit), für die man die Transformation eigentlich angegangen ist. Die Versuchung ist real, weil jeder Fachbereich seine Sonderwünsche für unverzichtbar hält — das Gegenmittel ist eine starke Governance, die Erweiterungen kritisch hinterfragt.
Der zweite große Risikoblock ist das Change Management. Ein ERP-Wechsel verändert Arbeitsweisen, Oberflächen und Verantwortlichkeiten — und Menschen reagieren auf Veränderung mit Skepsis. Projekte, die Schulung, Kommunikation und Einbindung der Fachbereiche als Nebensache behandeln, ernten nach dem Go-live Produktivitätseinbrüche, Workarounds und Frust. Erfolgreiche Einführungen investieren früh in Akzeptanz: Key User werden eingebunden, der Nutzen wird greifbar gemacht, und es gibt eine ehrliche Hypercare-Phase, in der Probleme ernst genommen und schnell gelöst werden. Technik lässt sich projektieren, Akzeptanz muss man verdienen.
