Zurueck zum Blog
BTP FinOps

CPEA vs. BTPEA: Was Sie ueber die zwei Credit-Modelle wissen muessen

CPEA BTPEA SAP BTP Credit-Modell Contract Governance

SAP BTP wird über vier Vertragsmodelle konsumiert. Zwei davon, CPEA und BTPEA, funktionieren nach derselben Grundlogik: Vorab-Kauf von Credits, flexible Nutzung über einen definierten Servicekatalog, Volumenrabatte. Und doch unterscheiden sie sich in einem Punkt, der für die langfristige Steuerung erheblich ist: dem Service-Scope und der Frage, welche Services in Zukunft noch zur Verfügung stehen werden.

Wer heute einen BTP-Vertrag verhandelt oder eine bestehende CPEA-Vereinbarung verlängert, trifft an diesem Steuerungsmoment eine Entscheidung, die die gesamte Governance-Struktur über die nächste Vertragslaufzeit prägt.


1. Entstehungsgeschichte: Warum BTPEA CPEA ergänzt, nicht ersetzt

CPEA, das Cloud Platform Enterprise Agreement, ist das ältere der beiden Modelle. Es wurde als Commit-to-Consume-Vertrag eingeführt und bietet Zugang zu einem historisch gewachsenen Katalog von rund 85 bis 90 BTP-Services. Kunden kaufen vorab ein jährliches Credit-Budget und verbrauchen dieses flexibel über die verfügbaren Services.

Das Modell funktioniert. Für viele Bestandskunden, die ihren BTP-Einsatz auf einem stabilen Set von Services betreiben, bleibt CPEA eine valide Wahl. Dennoch stieß es an eine strukturelle Grenze: Der Katalog wächst nicht mehr mit. Neue Services, die SAP nach der CPEA-Einführung entwickelt hat, sind nicht in dieses Modell aufgenommen worden.

BTPEA, das BTP Enterprise Agreement, wurde 2024 als strategisches Nachfolgemodell eingeführt. Es löst CPEA nicht ab, sondern ergänzt es. Bestandskunden auf CPEA können ihren Vertrag weiterlaufen lassen. Neukunden starten heute in der Regel mit BTPEA (Quelle: ASUG, SAP Experts Detail New SAP BTP Enterprise Agreement).

Dieser Steuerungsmoment zwischen "altem Weg" und "neuem Standardmodell" betrifft alle Unternehmen, die eine BTP-Renewal-Entscheidung vor sich haben.


2. Service-Scope: Breitere Abdeckung in CPEA, neuere Services in BTPEA

Der auffälligste Unterschied zwischen den beiden Modellen ist der Servicekatalog.

CPEA bietet eine breite historische Abdeckung: Der Katalog ist über Jahre gewachsen und enthält auch Services, die in neueren Versionen des SAP-Portfolios eine geringere Rolle spielen. Für Kunden, die auf diesem Legacy-Scope aufgebaut haben, ist das ein Vorteil. Die Services, auf die ihre Prozesse aufbauen, sind vorhanden und ihr Einsatz ist im Vertrag gesichert.

BTPEA hat einen anderen Ausgangspunkt: Low-Adoption-Services wurden aus dem Katalog entfernt. Dafür sind alle Services enthalten, die SAP seit der BTPEA-Einführung neu in das Programm aufgenommen hat. Wer neue SAP-Technologien im BTP-Ökosystem einsetzen möchte, kommt an BTPEA nicht vorbei.

In der Praxis bedeutet das: Kein Modell ist per se breiter oder schmaler. CPEA ist breiter in der Tiefe des Legacy-Angebots. BTPEA ist breiter in der Zukunftsrichtung. Welches Modell passt, hängt davon ab, welche Services ein Unternehmen heute nutzt und welche es in den nächsten drei bis fünf Jahren einsetzen möchte.


3. SAP Analytics Cloud: Der prominenteste Neuzugang in BTPEA

SAP Analytics Cloud (SAC) ist das anschaulichste Beispiel für die strategische Richtung von BTPEA. SAC, die Plattform für Business Intelligence, Planning und Predictive Analytics, ist nicht Teil des CPEA-Katalogs. Sie wurde erst mit der Einführung von BTPEA in das Enterprise-Agreement-Modell aufgenommen (Quelle: ASUG, SAP Experts Detail New SAP BTP Enterprise Agreement).

Was das für CPEA-Kunden bedeutet: Wer SAP Analytics Cloud über ein Enterprise Agreement konsumieren möchte, benötigt BTPEA. Wer SAC über eine separate Subscription betreibt oder plant, kann auf CPEA bleiben, trägt dann aber zwei separate Vertragsstrukturen.

Neben SAP Analytics Cloud enthält BTPEA neue KI-Services aus dem SAP AI Portfolio und weitere Additions, die SAP kontinuierlich ergänzt. Der SAP Discovery Center Service Catalog (https://discovery-center.cloud.sap/) zeigt tagesaktuell, welche Services in welchem Modell verfügbar sind. Dieser Katalog ist eine der wichtigsten Quellen für jeden Steuerungsmoment rund um Modellwahl und Renewal-Vorbereitung.


4. Deprecation Policy: Gruppe-1- und Gruppe-2-Services in BTPEA

BTPEA führt eine strukturierte Deprecation Policy ein, die CPEA in dieser Form nicht kennt. Sie teilt Services in zwei Gruppen ein und regelt unterschiedlich, wie lange ein Service nach einer Abkündigung noch genutzt werden kann.

Gruppe 1 (Core Services) sind Services, für die SAP den Support bis zum Ende der aktuellen Vertragslaufzeit garantiert. Kunden können diese Services produktiv einsetzen, ohne während der Laufzeit mit einer erzwungenen Migration rechnen zu müssen. Dieser Schutz entspricht der grundsätzlichen Zusage, die CPEA-Kunden für ihren gesamten Service-Scope haben.

Gruppe 2 (Innovation Services) sind neuere oder selten genutzte Services, die SAP mit einer Vorankündigungsfrist von mindestens 6 Monaten aus dem Katalog entfernen oder in Gruppe 1 überführen kann (Quelle: ASUG, SAP Experts Detail New SAP BTP Enterprise Agreement). Die 6 Monate sind kein Puffer für entspanntes Abwarten, sondern ein Zeitfenster, in dem eine Migrationsplanung eingeleitet werden muss.

Für den Steuerungsmoment im Bereich Infrastruktur hat das eine klare Konsequenz: Jedes produktive Deployment auf einem BTPEA-Service sollte von Beginn an dokumentieren, in welche Gruppe der betreffende Service fällt. Diese Dokumentation ist keine einmalige Einrichtungsaufgabe, sondern Bestandteil eines kontinuierlichen Deprecation-Monitorings.

Zwei Services, die für viele BTP-Kunden relevant sind, standen zuletzt unter Deprecation-Druck: SAP Datasphere und SAP Analytics Cloud zeigten in bestimmten BTP-Cockpit-Instanzen Deprecation-Warnungen mit Bezug auf das Jahresende 2025 (SAP KBA 3630656, SAP KBA 3632353). Der Migrationspfad für Datasphere führt in Richtung SAP Business Data Cloud. Kunden, die Datasphere produktiv einsetzen, sollten den aktuellen Stand dieser Ankündigungen prüfen, da sich SAP-Migrationspläne weiterentwickeln.


5. Was Migration erfordert und was sie nicht erfordert

Eine Migration von CPEA zu BTPEA ist technisch weniger aufwendig, als viele erwarten. Der Global Account, alle Subaccounts, die laufenden Services und alle Konfigurationen bleiben unverändert. Es werden lediglich die neuen kommerziellen Konditionen auf dem bestehenden Global Account aktiviert (Quelle: ASUG, SAP Experts Detail New SAP BTP Enterprise Agreement).

Die technische Seite ist damit überschaubar. Die kommerzielle Seite verlangt mehr Sorgfalt.

Erstens bildet der neue Vertrag eine neue Preisgrundlage. Die BTPEA-Konditionen können von den alten CPEA-Konditionen abweichen. Eine genaue Gegenüberstellung beider Preisstrukturen ist deshalb ein Pflichtschritt vor jeder Migrationsentscheidung.

Zweitens müssen Services, die im bestehenden CPEA-Vertrag enthalten sind, aber nicht in BTPEA aufgenommen wurden, als separate Subscriptions weitergeführt werden, wenn sie noch benötigt werden. Dieser Punkt betrifft vor allem Legacy-Services mit niedrigerer Adoptionsrate. Welche das konkret sind, zeigt eine Gegenüberstellung des aktuell genutzten Service-Inventars mit dem BTPEA-Katalog im Discovery Center.

Drittens ist der Zeitpunkt entscheidend. Migrationen finden in der Regel im Rahmen von Renewal-Verhandlungen statt. Ein laufender CPEA-Vertrag wird nicht einfach umgestellt, sondern läuft bis zum Ende seiner Laufzeit. Der Steuerungsmoment für eine Migrationsentscheidung ist deshalb das Renewal-Fenster, nicht der laufende Betrieb.


6. Entscheidungsrahmen: Checkliste für Bestandskunden

Die Entscheidung zwischen CPEA und BTPEA ist keine abstrakte Modellwahl, sondern eine konkrete Steuerungsentscheidung mit Auswirkungen auf Service-Verfügbarkeit, Kosten und Governance-Aufwand. Die folgende Checkliste strukturiert die relevanten Fragen.

Service-Analyse

Welche BTP-Services nutzen Sie heute aktiv? Sind diese Services im CPEA-Katalog enthalten? Gibt es darunter Services, die im BTPEA-Katalog nicht mehr verfügbar wären und als separate Subscription weitergeführt werden müssten?

Zukunftsplanung

Planen Sie den Einsatz von SAP Analytics Cloud über ein Enterprise Agreement? Wollen Sie neue SAP AI-Services oder andere BTPEA-exklusive Additions in Ihre Plattformstrategie einbeziehen? Ist Zukunftssicherheit bei der Modellwahl ein strategisches Kriterium?

Deprecation-Risiko

Betreiben Sie produktive Workloads auf Services, die in BTPEA potenziell in Gruppe 2 fallen würden? Haben Sie ein Deprecation-Monitoring etabliert, das Sie rechtzeitig über Abkündigungen informiert?

Kommerzieller Vergleich

Sind die BTPEA-Konditionen zum aktuellen Renewal-Zeitpunkt günstiger, gleichwertig oder teurer als die bestehenden CPEA-Konditionen? Gibt es Services, die durch eine Modellmigration aus dem Credit-Pool fallen und separat beschafft werden müssten, was die Gesamtkosten erhöhen würde?

Timing

Wann endet die aktuelle Vertragslaufzeit? Ist ausreichend Vorlauf für eine fundierte Analyse vorhanden, oder würde eine Migrationsentscheidung unter Zeitdruck getroffen?

Wenn die Service-Analyse ergibt, dass alle aktiv genutzten Services im bestehenden CPEA-Katalog vorhanden sind, keine neuen BTPEA-exklusiven Services benötigt werden und die Renewal-Konditionen vergleichbar sind, gibt es keinen zwingenden Handlungsbedarf. CPEA läuft weiter, SAP hat keine Abkündigung des Modells kommuniziert.

Wenn hingegen SAP Analytics Cloud, neue AI-Services oder andere BTPEA-exklusive Additions für die Plattformstrategie der nächsten Jahre relevant sind, ist die nächste Renewal der richtige Steuerungsmoment für eine Migrationsentscheidung.


Fazit

CPEA und BTPEA lösen dieselbe Aufgabe: BTP-Nutzung über ein vorab gekauftes Credit-Budget flexibel zu konsumieren. Der Unterschied liegt im Service-Scope und in der Zukunftsausrichtung des Modells.

CPEA ist das bewährte Modell für Kunden mit stabilem Service-Mix und keinem unmittelbaren Bedarf an neuen SAP-Additions. BTPEA ist das strategische Standardmodell für Neukunden und für Bestandskunden, die SAP Analytics Cloud, neue AI-Services oder künftige Innovations-Services über ein Enterprise Agreement nutzen möchten.

Die vier Steuerungsmomente-Bereiche Nutzung, Berechtigungen, Infrastruktur und Kosten spielen in beiden Modellen eine Rolle. Der Unterschied liegt in der Deprecation Policy: In BTPEA ist das Monitoring von Gruppe-2-Services eine strukturelle Governance-Anforderung, die in CPEA so nicht besteht.

Wer die Modellwahl als einmalige Kaufentscheidung behandelt, wird über die Vertragslaufzeit feststellen, dass die eigentliche Steuerungsarbeit danach beginnt.


Nächste Schritte

Wenn Sie wissen möchten, wie Ihr aktuelles BTP-Vertragsmodell zu Ihrer tatsächlichen Nutzung passt und welche Steuerungsmomente Sie vor dem nächsten Renewal strukturiert angehen sollten, lohnt ein Vertragscheck. In vier Wochen erhalten Sie Klarheit über Ihre aktuelle Vertragssituation und eine fundierte Entscheidungsgrundlage.

Vertragscheck anfragen | Zur BTP FinOps Hub-Page


Weiterführend: Capacity Units und Depreciation Groups verstehen | BTP Credit-Verfall und Overage-Mechanik

Naechste Schritte

Wenn Sie Ihren aktuellen Vertrag auf Risiken und verfuegbare kommerzielle Hebel pruefen lassen moechten: Der FinOptory Vertragscheck ist ein Festpreis-Engagement, das in vier Wochen eine strukturierte Grundlage liefert.

Dieser Beitrag gehört zum Themen-Hub BTP FinOps und Credit-Steuerung. Für die Bewertung eines konkreten Vertrags liefert der FinOptory Vertragscheck in vier Wochen eine strukturierte Grundlage.

Bernhard Maendle
Verfasst von Bernhard Maendle Managing Consultant, FinOptory fuer SAP

Zuletzt aktualisiert: Juli 2026