SAP S/4HANA Migration: Der Leitfaden für den Mittelstand (Ansätze, Ablauf, Fristen bis 2033)

SAP beendet die Mainstream-Wartung für SAP ECC am 31. Dezember 2027. Damit bekommt die SAP S/4HANA Migration in vielen Unternehmen einen festen Termin. Ein Projekt im Mittelstand braucht meist zwölf bis 24 Monate, das Zeitfenster für einen Wechsel ohne kostenpflichtige Verlängerung schließt sich also in diesem Jahr. Verlängerungen bis 2030 und 2033 gibt es, sie kosten Aufschlag und knüpfen Bedingungen an den Betrieb, die Sie kennen sollten, bevor Sie sie einplanen.

Dieser Leitfaden erklärt, welche Fristen gelten, wie sich Greenfield, Brownfield und Selective Data Transition unterscheiden, wie ein Projekt in sieben Schritten abläuft und wo Mittelständler Zeit und Geld verlieren. Er ist für IT-Leiter und Geschäftsführer geschrieben, die eine Entscheidung vorbereiten.

Was ist die SAP S/4HANA Migration?

Die SAP S/4HANA Migration ist der Wechsel von einem bestehenden SAP-ERP-System, meist SAP ECC 6.0 als Teil der SAP Business Suite 7, auf die aktuelle Produktgeneration SAP S/4HANA. Dahinter steckt mehr als ein Release-Upgrade: neue Datenbank, vereinfachtes Datenmodell, neue Oberfläche und in einigen Bereichen andere Prozesse.

S/4HANA läuft ausschließlich auf der In-Memory-Datenbank SAP HANA. Betreiben Sie Ihr SAP-System heute noch auf Oracle, IBM Db2 oder Microsoft SQL Server, wechseln Sie deshalb zwingend die Datenbank. Bei einer Systemkonvertierung erledigt der Software Update Manager das in einem Durchgang mit der eigentlichen Umstellung, sofern das System bereits auf Unicode läuft. Andernfalls planen Sie die Unicode-Umstellung als eigenen Schritt vorab ein.

Die technische Seite davon ist planbar. Schwieriger ist die Frage, wie viel vom bestehenden System mitkommen soll: alle Daten, alle Eigenentwicklungen, alle gewachsenen Prozesse? Oder nur das, was das Unternehmen in fünf Jahren noch braucht? An dieser Frage hängen Ansatz, Dauer und Budget.

Was unterscheidet SAP S/4HANA von SAP ECC?

Der größte Unterschied liegt im Datenmodell. S/4HANA führt Finanzbuchhaltung und Controlling in einer Tabelle zusammen, dem Universal Journal. Der Geschäftspartner wird zum führenden Stammdatenobjekt, über das Sie Debitoren und Kreditoren pflegen. Die bisherigen Kunden- und Lieferantenstämme bleiben im Hintergrund erhalten und laufen über die Customer Vendor Integration synchron. Viele Aggregat- und Indextabellen entfallen, weil HANA die Summen bei jeder Abfrage neu berechnet. Das beschleunigt Reporting und Abschlüsse. Eigenentwicklungen, die auf den alten Tabellen aufsetzen, müssen Sie allerdings anpassen.

Die zweite sichtbare Änderung ist die Oberfläche. SAP Fiori bringt rollenbasierte Apps im Browser, die klassische SAP GUI bleibt für viele Transaktionen verfügbar. Für die Fachbereiche ist das ein Gewinn. Für die IT bedeutet es ein neues Berechtigungskonzept, weil Fiori-Apps ihre Berechtigungen über Business-Kataloge in den Rollen beziehen und Apps viele Transaktionen ersetzen.

Drittens vereinfacht SAP den Funktionsumfang. Die sogenannten Simplification Items beschreiben, welche Funktionen und Komponenten entfallen, einen Nachfolger bekommen oder anders arbeiten. Drei Beispiele treffen den Mittelstand fast immer. Das klassische Lagerverwaltungsmodul LE-WM ersetzt SAP durch Extended Warehouse Management oder das schlankere Stock Room Management. Das Kreditmanagement aus SD wandert in das SAP Credit Management aus FSCM. SAP HCM läuft nur noch als eigenes Nachfolgeprodukt SAP HCM for SAP S/4HANA (H4S4) weiter.

Einige Altfunktionen liefen nach der Umstellung noch eine Zeit lang im Compatibility Scope weiter. Für die meisten dieser Compatibility Packs sind die Nutzungsrechte am 31. Mai 2026 ausgelaufen, On-Premise ebenso wie in SAP Cloud ERP Private. Nur Ausnahmen wie Customer Service, LE-TRA und Teile von PP-PI dürfen Sie bis Ende 2030 nutzen.

Welche Betriebsformen stehen zur Wahl?

Mit der Migration steht auch die Betriebsform zur Entscheidung. SAP bietet S/4HANA On-Premise und zwei Cloud-Varianten an, die seit 2025 neue Namen tragen. In vielen Verträgen und Angeboten stehen noch die alten Bezeichnungen.

Die Betriebsform beeinflusst den Migrationsansatz direkt. In die Public Cloud führt nur die Neuimplementierung, die private Cloud und On-Premise lassen alle drei Ansätze zu. Verwechseln Sie dabei die alte SAP Business Suite 7 nicht mit der neuen SAP Business Suite, unter der SAP seit 2025 Cloud ERP, Business Data Cloud und Joule bündelt. Grundlagen zu den Bereitstellungsmodellen erklärt unser Beitrag zu Cloud Computing. Für SAP Business ByDesign gilt ein eigener Weg: SAP verkauft es seit dem 20. April 2026 nicht mehr an Neukunden, betreibt es für Bestandskunden mindestens bis 2032 weiter und nennt SAP Cloud ERP als Zielsystem.

Klären Sie früh, was mit Ihren bezahlten ECC-Lizenzen passiert. Bleiben Sie On-Premise, rechnet SAP sie über eine Contract Conversion oder eine Product Conversion auf S/4HANA-Lizenzen an. Bei RISE with SAP endet der Lizenzvertrag, und der Lizenzwert fließt über ein Anrechnungsmodell in die Subskription ein. Lassen Sie sich beide Varianten mit Zahlen vorrechnen, bevor Sie die Betriebsform entscheiden.

Was bringt der Umstieg außer Wartungssicherheit?

Der greifbarste Nutzen liegt im Finanzwesen und im Reporting. Weil das Universal Journal alle Buchungen in einer Tabelle hält, entfallen Abstimmungen zwischen FI und CO, Nachtläufe für Auswertungen und viele Zwischentabellen. Abschlüsse werden schneller, Auswertungen laufen auf aktuellen Daten. In der Logistik läuft die Disposition mit MRP Live deutlich schneller als der klassische Planungslauf, und Extended Warehouse Management lässt sich direkt im Kern des Systems betreiben.

Neue Funktionen entwickelt SAP nur noch für S/4HANA und die Cloud-Editionen: Fiori-Apps für die Fachbereiche, eingebettete Analysen und Anschlussmöglichkeiten für Prozessautomatisierung. Den KI-Assistenten Joule bietet SAP für SAP Cloud ERP und SAP Cloud ERP Private an, für On-Premise-Systeme derzeit nicht. Das gehört in die Entscheidung über die Betriebsform.

Diese Vorteile stellen sich allerdings nicht von allein ein. Eine rein technische Konvertierung liefert zunächst dasselbe System auf einer neuen Datenbank. Der Nutzen kommt, wenn Fachbereiche ihre Prozesse auf den neuen Standard umstellen und alte Umgehungslösungen abschaffen. Nehmen Sie diese Prozessänderungen mit Verantwortlichen und Terminen in den Projektplan auf.

Wann müssen Unternehmen auf SAP S/4HANA umstellen?

Für die meisten SAP-Kunden endet die Mainstream-Wartung für SAP ECC 6.0 am 31. Dezember 2027. Danach gibt es zwei kostenpflichtige Verlängerungen: die Extended Maintenance bis Ende 2030 und, unter engen Bedingungen, eine Übergangslösung bis Ende 2033. Beide kosten Aufschlag und enden an einem festen Datum.

Welche Fristen gelten: 2027, 2030 oder 2033?

Die Übergangslösung bis 2033 richtet sich laut SAP ausdrücklich an die größten und komplexesten Kunden, und die Bedingungen zeigen, warum. Datenbankwechsel und Cloud-Umzug müssen bis Ende 2030 erledigt sein, nur die Umstellung auf S/4HANA selbst darf warten. Manche Mittelstandssysteme liegen zudem unter der Größenvorgabe von 2 Terabyte und kommen für die Option gar nicht infrage.

Für die Planung hilft eine Rückwärtsrechnung. Planen Sie für ein Migrationsprojekt im Mittelstand zwölf bis 24 Monate ein. Gut vorbereitete Konvertierungen kleiner Systeme schaffen es auch in unter einem Jahr, Neuimplementierungen mit neuen Prozessen brauchen eher länger. Für einen Go-Live vor Ende 2027 bleibt damit nur ein Start in diesem Jahr, in den meisten Fällen als Konvertierung. Bei einem späteren Start planen Sie den Aufschlag für die Extended Maintenance für ein bis zwei Jahre ein und setzen das Projekt trotzdem 2026 auf. Sonst rückt der Go-Live an das Ende der Extended Maintenance, wo sich Verzögerungen nicht mehr auffangen lassen. Rechnen Sie außerdem mit knappen Beratern, weil 2026 und 2027 viele Projekte gleichzeitig starten.

Wie weit der Markt ist, zeigt der DSAG-Investitionsreport 2026. Von den 198 Befragten aus Anwenderunternehmen setzen 54 Prozent noch SAP ECC oder die alte Business Suite ein, 56 Prozent betreiben bereits S/4HANA On-Premise. Von denjenigen, die weiter in SAP ECC investieren, wollen 37 Prozent bis Ende 2027 umstellen, fast die Hälfte plant den Wechsel bis Ende 2030, und 4 Prozent peilen die Übergangsoption bis 2033 an.

Warum forciert SAP den Umstieg?

SAP pflegt mit ECC und S/4HANA zwei Produktlinien parallel, und neue Funktionen entstehen nur noch in der neuen. Joule und die meisten Fiori-Neuerungen erreichen ECC-Kunden nicht mehr, und für die Business Data Cloud liefert SAP fertige Datenprodukte nur aus S/4HANA und den Cloud-Anwendungen. Gleichzeitig verschiebt SAP sein Geschäftsmodell auf Subskriptionen, vermutlich der Grund, warum die Übergangsoption bis 2033 an einen RISE-Vertrag gebunden ist.

Für Ihre Entscheidung folgt daraus ein Punkt, der in Terminplänen gern untergeht: Mit der Option 2033 entscheiden Sie sich faktisch für die private Cloud und ein Subskriptionsmodell. Wollen Sie den Systembetrieb an SAP abgeben und von Lizenz auf Subskription wechseln? Beides verändert Ihr laufendes Budget und Ihre Abhängigkeit von SAP, also klären Sie es, bevor die Option in den Zeitplan wandert.

Welcher Migrationsansatz passt: Greenfield, Brownfield oder Selective Data Transition?

Drei Wege führen nach S/4HANA: die Neuimplementierung (Greenfield), die Systemkonvertierung (Brownfield) und die selektive Datenübernahme (Selective Data Transition, von SNP als Bluefield vermarktet). Die Wahl hängt davon ab, wie viel vom bestehenden System Sie behalten wollen und wie viel Zeit bis zum Go-Live bleibt.

Greenfield: Wann lohnt sich die Neuimplementierung?

Beim Greenfield-Ansatz bauen Sie ein neues S/4HANA-System auf und richten die Prozesse nach dem SAP-Standard ein (Fit-to-Standard). Aus dem Altsystem übernehmen Sie nur die Stammdaten und offenen Posten, die Sie tatsächlich brauchen. Historische Belege bleiben im alten System oder in einem Archiv mit Lesezugriff.

Das Ergebnis ist ein sauberes System ohne Altlasten. Dafür dauert Greenfield in der Regel am längsten und kostet am meisten, weil Sie jede Eigenentwicklung, jede Schnittstelle und jeden Prozess neu bewerten. Die Fachbereiche leben später mit veränderten Abläufen. Sinnvoll ist der Ansatz für stark angepasste Altsysteme, nach Fusionen mit mehreren ERP-Welten und immer dann, wenn die Public Cloud das Ziel ist, denn dorthin führt nur die Neuimplementierung.

Brownfield: Wann passt die Systemkonvertierung?

Bei der System Conversion wandeln Sie das bestehende ECC-System technisch in ein S/4HANA-System um. Der Software Update Manager (SUM) übernimmt das in einem Durchgang. Mit der Database Migration Option (DMO) zieht er die Datenbank auf SAP HANA um, falls sie noch nicht darauf läuft. Dann installiert er die S/4HANA-Software und überführt die Daten in die neuen Strukturen. Danach folgen Nacharbeiten, allen voran die Migration der Finanzdaten in das Universal Journal. Daten, Customizing, Historie und Eigenentwicklungen bleiben erhalten.

Das macht Brownfield zum schnellsten Weg mit dem geringsten Umgewöhnungsaufwand. Ganz ohne Vorarbeit geht es trotzdem nicht. Vor der Konvertierung müssen Sie die Geschäftspartner eingeführt, die Simplification Items abgearbeitet und den Custom Code auf S/4HANA-Verträglichkeit geprüft haben. Der Simplification Item Check muss ohne Fehler durchlaufen, sonst bricht der SUM ab. Seit dem Ende der Compatibility Packs gehört außerdem die Ablösung von LE-WM und SD-Kreditmanagement in den Konvertierungsumfang, was den Zeitvorteil verkleinert. Und Sie nehmen alles mit, auch das, was schon in ECC niemand mehr verstanden hat. Brownfield passt zu standardnahen Systemen mit einem Mandanten, guter Datenqualität und Zeitdruck bis 2027.

Selective Data Transition: Wann brauchen Sie den Mittelweg?

Die Selective Data Transition verbindet beide Ansätze. Sie bauen ein neues oder technisch konvertiertes Zielsystem ohne Bewegungsdaten auf und übernehmen anschließend gezielt, was Sie brauchen. Das können bestimmte Buchungskreise sein, nur die Belege der letzten Jahre oder mehrere ECC-Systeme, die in einem aufgehen. Dafür brauchen Sie spezialisierte Werkzeuge und Partner mit Erfahrung darin. SAP bietet das selbst über sein DMLT-Team an und bildet mit SNP, Natuvion und cbs die SAP S/4HANA Selective Data Transition Engagement.

Der Vorteil liegt in der Flexibilität: Sie gestalten Prozesse dort neu, wo es sich lohnt, behalten Historie, wo Sie sie brauchen, und organisieren den Umstieg gesellschaftsweise in Wellen. Dafür ist der Ansatz komplexer und in der Regel teurer als eine reine Konvertierung. Er lohnt sich bei großen Datenmengen, bei Konsolidierungen und wenn der Betrieb nur kurze Stillstände verträgt.

Welcher Ansatz passt zu welcher Ausgangslage?

Die Tabelle zeigt, womit Sie die Bewertung beginnen sollten. Sie ersetzt keine Analyse des eigenen Systems.

Wie bereiten Sie die SAP S/4HANA Migration vor?

Die Vorbereitung entscheidet mit über Dauer und Kosten, unabhängig vom Ansatz. Sechs Bausteine gehören in jede Vorbereitungsphase.

Wenn Sie mehrere Punkte verneinen, zeigt Ihnen die Liste den Umfang der Vorbereitungsphase. Diese Punkte arbeiten Sie in der Vorbereitung ab, den Projektstart müssen Sie dafür nicht verschieben.

In welchen sieben Schritten läuft die SAP S/4HANA Migration ab?

SAP gibt mit der Methodik SAP Activate einen Phasenrahmen vor: Discover, Prepare, Explore, Realize, Deploy und Run. Die meisten Partner arbeiten danach. In der Praxis lässt sich ein Migrationsprojekt in sieben Schritte übersetzen.

Die Schritte sind für alle drei Ansätze gleich, ihr Gewicht verschiebt sich. Bei Brownfield dominieren die technischen Durchläufe und Tests, bei Greenfield die Prozessworkshops und die Datenmigration.

Wie migrieren Sie Daten und Eigenentwicklungen nach S/4HANA?

Bei einer Neuimplementierung ist die Datenmigration ein eigenes Teilprojekt neben dem Hauptprojekt, mit eigenem Zeitplan und eigenen Verantwortlichen. Sie klären zuerst, welche Stammdaten, offenen Posten und Bewegungsdaten das Zielsystem braucht und aus welchen Datenquellen sie kommen. Danach bereinigen Sie die Daten, ordnen sie den Datenstrukturen des neuen Datenmodells zu und laden sie in mehreren Testmigrationen. Jeden Testlauf nehmen die Geschäftsanwender in einem festen Validierungsprozess ab. Bei der Systemkonvertierung nimmt der SUM die Datenbank dagegen komplett mit. Die Arbeit liegt dort vorher in Bereinigung und Archivierung, weil jedes überflüssige Gigabyte die Downtime verlängert und die HANA-Datenbank vergrößert.

Was ist das SAP S/4HANA Migration Cockpit?

Das SAP S/4HANA Migration Cockpit ist das Standardwerkzeug von SAP für die Datenübernahme bei Neuimplementierungen, On-Premise wie in der Cloud. Es steckt seit S/4HANA 2020 in der Fiori-App „Migrate Your Data“ und ist im Lieferumfang enthalten. Die frühere Transaktion LTMC ist seit S/4HANA 2021 abgekündigt, neue Projekte lassen sich dort nicht mehr anlegen.

Das Cockpit bringt vordefinierte Migrationsobjekte mit, etwa für Geschäftspartner, Materialien, Anlagen, offene Posten oder Kostenstellen, inklusive Feldzuordnung und Prüfungen. Für die Befüllung gibt es zwei Wege: Staging-Tabellen, die Sie per Datei, ETL-Werkzeug oder SAP Data Services beladen, und den Direct Transfer, der Daten direkt aus einem angebundenen SAP-Quellsystem liest. Beide Wege wiederholen Sie in Testläufen, bis die Fehlerlisten leer sind.

Zwei Grenzen sollten Sie kennen. Erstens ist das Cockpit für Stammdaten und offene Bewegungsdaten gedacht, nicht für die komplette Historie; für alte Belege im neuen System brauchen Sie die Selective Data Transition. Zweitens bereinigt das Cockpit keine Daten. Es prüft Formate und Pflichtfelder, aber Dubletten und veraltete Lieferanten wandern hindurch, wenn sie vorher niemand aussortiert hat.

Wie sichern Sie die Datenqualität vor der Migration?

Datenbereinigung braucht einen Eigentümer pro Datenobjekt. Ohne einen Verantwortlichen für Materialstämme, Lieferanten und Kunden bleibt die Arbeit liegen, bis die erste Testmigration Fehlerlisten liefert. Benennen Sie deshalb pro Datenobjekt einen Verantwortlichen im Fachbereich und lassen Sie die Daten vor Projektstart analysieren, damit der Umfang der Bereinigung bekannt ist. Legen Sie Regeln fest, was Sie löschen, zusammenführen oder nachpflegen, und arbeiten Sie diese Liste ab, bevor die erste Testmigration läuft. Prüfen Sie außerdem, welche Altdaten Sie aus Datenschutzgründen gar nicht mehr übernehmen dürfen. Ein Löschkonzept gehört zur Migration dazu.

Was passiert mit Eigenentwicklungen?

Die Sorge, dass Z-Entwicklungen bei der Migration verloren gehen, ist unbegründet. Bei der Konvertierung bleiben sie erhalten, bei der Neuimplementierung entscheiden Sie, was Sie nachbauen. Der Aufwand liegt in der Prüfung: Jede Entwicklung muss jemand gegen das neue Datenmodell testen und über ihre Zukunft entscheiden.

Der Prozess heißt bei SAP Custom Code Migration. Er beginnt mit der Bestandsaufnahme: Die Nutzungsstatistik aus dem ABAP Call Monitor zeigt, welche Entwicklungen die Anwender überhaupt noch aufrufen. Anschließend prüft das ABAP Test Cockpit den verbleibenden Code gegen die Simplification Database, die alle Änderungen des Datenmodells und der Schnittstellen kennt. Die Fiori-App „Custom Code Migration“ fasst die Ergebnisse zusammen und filtert sie nach Nutzung und Quick-Fix-Verfügbarkeit. Für viele Standardfälle liefert SAP halbautomatische Korrekturen (Quick Fixes), die Sie nach der technischen Konvertierung in den ABAP Development Tools anwenden. Seit 2025 hilft Joule für Entwickler bei der Anpassung, seit Mitte 2026 ergänzt um einen ersten Custom Code Migration Agent, der Prüfbefunde automatisiert abarbeitet. Beides gibt es für SAP Cloud ERP Private und die SAP Business Technology Platform, abgerechnet nach Verbrauch, für On-Premise-Systeme derzeit nicht.

Am Ende sortieren Sie jede Entwicklung in eine von drei Gruppen. Stilllegen, weil sie niemand nutzt oder der Standard sie ersetzt. Anpassen, weil Sie den Code weiter brauchen und nur technisch angleichen müssen. Oder neu bauen, weil die Funktion nach dem Clean-Core-Prinzip als Erweiterung auf der SAP Business Technology Platform oder als Key-User-Erweiterung besser aufgehoben ist. Die Fachbereiche entscheiden mit, weil nur die Anwender wissen, welche Reports sie noch nutzen.

Womit müssen Sie bei Aufwand, Kosten und Risiken rechnen?

Der Aufwand einer S/4HANA-Migration richtet sich vor allem nach dem Abstand zum Standard, kaum nach der Zahl der Nutzer. Ein System mit wenigen Eigenentwicklungen, sauberen Stammdaten und einem Mandanten lässt sich in Monaten konvertieren. Ein über zwanzig Jahre gewachsenes System mit hunderten Z-Programmen, mehreren Buchungskreisen und Dutzenden Schnittstellen braucht ein Mehrfaches davon, bei jedem Ansatz.

Die Kosten verteilen sich auf mehrere Blöcke, und das Angebot des Partners zeigt meist nur einen davon. Der größte Posten ist die Implementierung durch den Partner. Dazu kommen Lizenz oder Subskription, oft mit einer Vertragsumstellung, Infrastruktur oder Cloud-Betrieb, Schulung, Testumgebungen und bei spätem Start die Extended Maintenance. Intern binden Sie Key User über Monate für Workshops, Tests und Datenbereinigung. Lassen Sie sich die Personentage deshalb getrennt nach Partner und eigenem Haus ausweisen, sonst fehlt der interne Anteil im Budget. Vergleichen Sie außerdem die laufenden Kosten über fünf Jahre: Bei On-Premise zahlen Sie weiter Wartung auf den Lizenzwert, bei SAP Enterprise Support derzeit 22 Prozent, plus eigenen Betrieb. Bei RISE zahlen Sie eine Subskription, die Betrieb, Datenbank und Wartung enthält. Welche Größenordnungen dabei realistisch zusammenkommen, zeigt unsere Übersicht zu den Kosten einer S/4HANA-Migration im Mittelstand.

Wie viel Aufwand bedeutet die Migration?

Die wichtigsten Aufwandstreiber sind der Anteil an Custom Code, die Datenqualität, die Zahl der Schnittstellen zu Drittsystemen und die Zahl der Buchungskreise und Länder mit eigenen gesetzlichen Anforderungen. Hinzu kommen Add-ons ohne S/4HANA-Freigabe, das Berechtigungskonzept und der Schulungsbedarf. Der Readiness Check macht die ersten vier messbar, die übrigen gehören in die Partnergespräche vor dem Angebot.

Ein Punkt verdient besondere Aufmerksamkeit: die Berechtigungen. Alte Rollen lassen sich nicht eins zu eins übernehmen, weil Fiori-Apps ihre Berechtigungen über Business-Kataloge beziehen und Apps viele Transaktionen ersetzen. Setzen Sie das Berechtigungskonzept deshalb schon in Schritt 3 auf die Liste, mit einem eigenen Verantwortlichen aus der SAP-Basis.

Welche typischen Fehler kosten Zeit und Geld?

Die Fehler wiederholen sich über Projekte hinweg. Schnittstellen tauchen zu spät im Projektplan auf, und im Integrationstest fehlt plötzlich die EDI-Anbindung des größten Kunden. Die Datenbereinigung wandert ans Projektende, weil sie im Tagesgeschäft keinen Owner hat. Die Fachbereiche sehen die neue Oberfläche zum ersten Mal im Anwendertest. Add-ons von Drittanbietern haben keine S/4HANA-Freigabe, und der Hersteller verspricht sie für das übernächste Quartal.

Zwei organisatorische Fehler kommen hinzu. Der erste ist ein Vertrag ohne klare Verantwortungsabgrenzung: Wer verantwortet die Datenmigration, wer den Custom Code, wer die Tests? Bleibt das offen, streiten Partner und interne IT im Cutover darüber. Der zweite ist fehlendes Change Management. S/4HANA verändert Abläufe, Oberflächen, Rollen und Zuständigkeiten. Führungskräfte müssen erklären, warum sich Arbeit ändert, und Key User brauchen Zeit, ihre Kollegen mitzunehmen. In vielen Häusern regelt außerdem eine Betriebsvereinbarung den Einsatz von SAP. Neue Module, Fiori-Rollen und Protokolle fallen unter die Mitbestimmung nach § 87 Absatz 1 Nummer 6 BetrVG, also gehört der Betriebsrat schon vor den Fit-to-Standard-Workshops an den Tisch. Ohne diese Begleitung arbeiten die Anwender mit den alten Umgehungslösungen weiter.

Wie finden Sie den passenden Partner für die SAP S/4HANA Migration?

Mit der Partnerwahl legen Sie fest, wer in den nächsten zwei Jahren mit Ihrem Kernsystem arbeitet und wer nach dem Go-Live erreichbar ist. Der Tagessatz ist dafür ein schwaches Kriterium. Sechs Fragen bringen mehr:

Im it-dock Anbieterverzeichnis führen aktuell 128 Dienstleister den Schwerpunkt SAP S/4HANA Migration, vom spezialisierten SAP-Beratungshaus bis zum Systemhaus mit eigenem SAP-Basis-Team. Für die Anbindung von Drittsystemen und EDI finden Sie dort außerdem Dienstleister mit Schwerpunkt ERP-nahe Integration. Wer sich die Vorauswahl abkürzen möchte, beschreibt sein Projekt im IT-Lotse und erhält eine Shortlist passender Anbieter, kostenlos und ohne Anmeldung.

Fazit: Welche drei Entscheidungen stehen jetzt an?

Ende 2027 erreicht SAP ECC das Wartungsende. Die Verlängerungen kosten Aufschlag, und die Option bis 2033 bindet Sie an einen RISE-Vertrag mit Mindestgröße und Support-Plan. Bis dahin müssen Sie den Migrationsansatz, die Betriebsform und den Partner festgelegt haben. Der Readiness Check, eine Analyse der Stammdaten und das Inventar der Eigenentwicklungen liefern die Zahlen dafür, und alle drei können Sie ohne Partnerentscheidung starten. Passende Dienstleister finden Sie über den Schwerpunkt SAP S/4HANA Migration im Anbieterverzeichnis.