Clean Core ist eine Architekturregel, keine Produktvorgabe. Wann SAP BTP passt, wann eine unabhängige Plattform und wie Sie die Entscheidung vor den Umzügen bis 2030 treffen.
Das Wichtigste in Kürze
- Clean Core verlangt, dass Erweiterungen den ERP-Kern nicht verändern und über freigegebene Schnittstellen zugreifen.
- SAP empfiehlt für Erweiterungen neben dem Kern die SAP BTP. Das Prinzip lässt sich auch mit einer anderen Plattform umsetzen.
- Die Wahl hängt von Betriebsort, Datenhoheit, Anteil der Nicht-SAP-Systeme und Kostenmodell ab.
- Durch die Fristen für 2030 wird die Plattformfrage für ECC-Kunden jetzt akut, weil Eigenentwicklungen und Java-Anwendungen umziehen müssen.
SAP Clean Core ohne BTP ist möglich: Clean Core verlangt, dass Erweiterungen den ERP-Kern nicht verändern und über freigegebene Schnittstellen zugreifen. SAP empfiehlt für Erweiterungen neben dem Kern die SAP Business Technology Platform. Das Prinzip lässt sich aber ebenso mit einer anderen Plattform umsetzen, die SAP über Standardschnittstellen anbindet.
Was bedeutet Clean Core?
Clean Core bedeutet, dass der ERP-Kern so nah wie möglich am SAP-Standard bleibt. Erweiterungen greifen nur über von SAP freigegebene Schnittstellen und Erweiterungspunkte zu, statt den Kern zu modifizieren. So bleibt das System updatefähig, und Erweiterungen überstehen Releasewechsel, ohne bei jedem Upgrade erneut angepasst zu werden.
SAP unterscheidet dabei zwei Wege: Erweiterungen im System selbst mit dem Entwicklungsmodell ABAP Cloud und Erweiterungen neben dem System, sogenannte Side-by-Side-Erweiterungen. Für die zweite Variante empfiehlt SAP die BTP. Beide Wege haben dasselbe Ziel: Der Kern bleibt updatefähig. Genau an dieser Stelle setzt die Frage nach Alternativen an.
Was bedeutet Clean Core für Unternehmen, die noch auf ECC sind?
Für ECC-Kunden ist Clean Core kein Thema für später. Jede Erweiterung, die heute neu entsteht, sollte bereits so gebaut werden, dass sie den Kern nicht verändert und über Standardschnittstellen zugreift. Sonst entsteht bis zur Conversion neuer Ballast, der vor 2030 wieder bereinigt werden muss.
Praktisch heißt das: Neue Anforderungen aus den Fachbereichen landen nicht mehr automatisch als Z-Programm im ECC. Sie werden zuerst daraufhin geprüft, ob sie neben dem ERP umgesetzt werden können. Diese Regel kostet am Anfang Disziplin und spart in der Conversion Zeit.
Warum wird die Plattformfrage durch 2030 dringend?
Die Fristen für 2030 zwingen viele ECC-Kunden, Anwendungen umzuziehen, bevor sie über S/4HANA entschieden haben. Java-Anwendungen auf NetWeaver AS Java 7.5 brauchen bis Ende 2030 ein neues Zuhause, und Eigenentwicklungen sollten vor einer Conversion aus dem Kern. Wohin sie gehen, ist eine Plattformentscheidung, die Ihre Architektur auf Jahre prägt.
SAP selbst empfiehlt, die Transformation zu SAP Cloud ERP mit den passenden Lösungen der SAP Autonomous Suite bis Ende 2030 abzuschließen (SAP News Center, 7.10.2026). Den Überblick über alle Fristen gibt SAP Drittdatenbank 2030. Wer die Plattformentscheidung unter Zeitdruck trifft, landet oft bei der Plattform, die der Implementierungspartner gerade anbietet. Besser ist es, die Kriterien vorher festzulegen und die anstehenden Umzüge daran auszurichten. Wie Sie Eigenentwicklungen dafür sortieren, zeigt SAP Eigenentwicklungen entkoppeln.
Ein weiterer Treiber ist KI. Agenten, die auf SAP-Daten zugreifen, brauchen eine Plattform mit Freigabelogik und Protokoll. Wer die Erweiterungsplattform jetzt wählt, sollte prüfen, ob dort auch KI-Agenten unter eigener Kontrolle laufen können. Was dabei heute schon auf ECC möglich ist, zeigt KI für SAP ECC.
Ist SAP Clean Core ohne BTP möglich?
Ja. Clean Core ist ein Architekturprinzip, keine exklusive Produktvorgabe. Ob eine Erweiterung auf BTP oder auf einer anderen Plattform läuft, ist zweitrangig. Es zählt, ob sie den ERP-Kern unverändert lässt und nur über freigegebene Schnittstellen zugreift. SAP empfiehlt für Side-by-Side-Erweiterungen die BTP, weil sie am tiefsten in die eigenen Produkte integriert ist.
Wenn ein Unternehmen tief in der SAP-Cloud-Strategie bleibt, kann BTP ein guter Fit sein. Eine unabhängige Plattform wird dort relevant, wo Erweiterungen systemübergreifend laufen, On-Premise- oder Hybrid-Betrieb gefordert ist und Prozesse nicht an der Grenze des SAP-Ökosystems enden.
Für BTP sprechen die enge Integration in SAP-Dienste und vorgefertigte Inhalte für SAP-Szenarien. Gegen eine reine BTP-Strategie spricht in manchen Unternehmen der Betriebsort: BTP wird als Cloud-Dienst betrieben, wer Erweiterungen im eigenen Rechenzentrum halten muss, braucht eine Alternative. Dazu kommt die Abhängigkeit von einem Anbieter, gerade wenn viele Nicht-SAP-Systeme beteiligt sind.
Ehrlich ist auch: Eine unabhängige Plattform ersetzt nicht jede BTP-Funktion. Wer gezielt SAP-Dienste nutzt, die nur auf BTP angeboten werden, braucht BTP dafür weiterhin. Die Frage lautet deshalb selten entweder oder, sondern welche Erweiterung wohin gehört.
Nach welchen Kriterien wählen Sie die Erweiterungsplattform?
Wählen Sie die Plattform nach Ihren Betriebs- und Architekturanforderungen, nicht nach dem Logo auf der Rechnung. Die wichtigsten Kriterien sind Betriebsort und Datenhoheit, der Anteil angebundener Nicht-SAP-Systeme, das Kostenmodell bei wachsender Nutzung und die Frage, wer Anwendungen künftig baut und betreibt.
| Kriterium | Leitfrage | Worauf Sie achten sollten |
| Betriebsort | On-premises, Cloud oder beides? | BTP läuft als Cloud-Dienst; eine Pflicht zum Eigenbetrieb schließt sie aus |
| Datenhoheit | Wo liegen Daten, Protokolle und KI-Eingaben? | Rechenzentrumsstandorte und Zugriffsrechte vertraglich klären |
| Nicht-SAP-Systeme | Wie viele Fremdsysteme hängen an den Prozessen? | Anbindungen für Fremdsysteme gleichwertig prüfen |
| Kosten | Wie wachsen die Kosten mit Nutzern, Anwendungen und Aufrufen? | Szenario für drei Jahre rechnen |
| Entwicklung und Betrieb | Wer baut und pflegt die Anwendungen? | Kompetenzen im eigenen Team und beim Partner |
| KI | Wo laufen KI-Agenten, und wie werden Freigaben gesteuert? | Freigabe und Protokoll als Pflichtanforderung |
Gewichten Sie die Kriterien vor dem ersten Anbietergespräch. Sonst bestimmt die Präsentation des Anbieters, welche Kriterien wichtig erscheinen.
Für wen eignet sich eine Plattform ohne BTP-Zwang?
Eine Plattform ohne BTP-Zwang eignet sich vor allem für Unternehmen, die SAP on-premise betreiben und ihre Erweiterungen im eigenen Rechenzentrum oder in einer EU-Cloud halten wollen. Ebenso passt sie zu heterogenen Landschaften, in denen Prozesse SAP und Nicht-SAP-Systeme verbinden, etwa ein Fertigungsleitsystem oder ein Lieferantenportal.
Ein Beispiel aus der Produktion: Eine Rückmelde-App für die Fertigung liest Aufträge aus ECC, holt Maschinendaten aus dem Fertigungsleitsystem und schreibt Rückmeldungen zurück. Die App gehört weder in den ERP-Kern noch zwingend in eine SAP-Cloud. Sie gehört dorthin, wo beide Systeme gleichberechtigt angebunden sind.
Für mittelständische Unternehmen kommt ein praktischer Punkt hinzu: Kleine IT-Teams können nicht mehrere Entwicklungsmodelle parallel beherrschen. Eine Plattform, auf der SAP- und Nicht-SAP-Anwendungen mit denselben Werkzeugen entstehen, senkt den Schulungsaufwand und die Abhängigkeit von einzelnen Spezialisten.
Lassen sich BTP und andere Plattformen kombinieren?
Ja, und in vielen Landschaften ist das der realistische Weg. Wichtig ist eine klare Regel, welche Erweiterung wohin gehört, etwa: SAP-nahe Szenarien mit vorgefertigten SAP-Inhalten auf BTP, prozessübergreifende Anwendungen mit vielen Fremdsystemen auf einer unabhängigen Plattform. Ohne diese Regel entsteht ein Wildwuchs, der Clean Core wieder untergräbt.
Eine solche Regel kann einfach sein: Erweiterungen, die nur SAP-Daten nutzen und SAP-Standardinhalte ergänzen, laufen auf BTP. Anwendungen mit Nutzern außerhalb des Unternehmens oder mit Fremdsystemen laufen auf der unabhängigen Plattform. Über Ausnahmen entscheidet ein Architekturgremium.
Welche Fehler sollten Sie bei der Plattformwahl vermeiden?
Der häufigste Fehler ist, die Plattform nach dem ersten Projekt auszuwählen statt nach der Gesamtarchitektur. Wer für den Ersatz des Portals eine Lösung wählt und für die KI-Agenten eine zweite, betreibt nach wenigen Jahren mehrere Plattformen mit jeweils eigenen Schnittstellen und Berechtigungen. Das ist das Gegenteil eines sauberen Kerns.
- Kosten nur für das erste Jahr rechnen, obwohl sie mit Nutzern und Anwendungen wachsen.
- Den Betrieb vergessen: Wer überwacht die Plattform, wer spielt Updates ein, wer reagiert bei Störungen?
- Nicht-SAP-Systeme unterschätzen, die später angebunden werden sollen.
- Die Fachbereiche erst beim Go-live einbeziehen statt bei der Auswahl.
Unsere Empfehlung
Treffen Sie die Plattformentscheidung, bevor Sie Java-Anwendungen und Eigenentwicklungen umziehen, nicht danach. Gewichten Sie die Kriterien aus der Tabelle gemeinsam mit IT und Fachbereich und legen Sie eine Regel fest, welche Erweiterung wohin gehört. Clean Core ist eine Architekturregel. Mit welcher Plattform Sie sie umsetzen, entscheiden Sie.
Simplifier ist eine solche unabhängige Plattform und versteht sich nicht als Gegenmodell zu BTP. Sie bindet SAP über Standardschnittstellen ohne BTP-Zwang an, verbindet Nicht-SAP-Systeme und liefert die Runtime für den Betrieb: Rollen, Freigaben, Audit Trail und Monitoring, auch für KI-Agenten. Betrieben wird on-premises oder in der EU-Cloud.
SAP 2030 Check: Sind wir betroffen und was müssen wir entscheiden?
Checkliste:
Rot, Gelb oder Grün? Der SAP 2030 Check zeigt Ihnen, wo Ihre SAP-Landschaft steht.
FAQ
Nein, Clean Core gilt auch im ECC – wer Eigenentwicklungen schon dort aus dem Kern löst und über freigegebene Schnittstellen anbindet, verkürzt die spätere S/4HANA-Conversion und startet direkt mit einem sauberen Kern.
SAP empfiehlt für Side-by-Side-Erweiterungen zwar die Business Technology Platform (BTP), doch das Clean-Core-Prinzip – Zugriff ausschließlich über freigegebene Schnittstellen – lässt sich ebenso auf anderen Plattformen einhalten, weshalb eine Nicht-SAP-Plattform der SAP-Strategie nicht widerspricht.
Ja, BTP lässt sich mit einer anderen Plattform kombinieren, da viele SAP-Landschaften ohnehin hybrid sind – entscheidend ist eine klare, dokumentierte Regel, welche Erweiterung auf welcher Plattform betrieben wird.
Bestehende Erweiterungen im ECC-Kern werden per Inventur in drei Kategorien sortiert – abschalten, im Kern behalten oder auf eine Zielplattform auslagern –, wobei die Auslagerungs-Kandidaten zu den ersten Anwendungen auf der neuen Plattform werden.
