CPEA vs. BTPEA: What You Need to Know About the Two Credit Models
SAP BTP is consumed through four contract models. Two of them, CPEA and BTPEA, share the same core logic: upfront purchase of credits, flexible consumption across a defined service catalog, and volume discounts. Yet they differ in one way that matters enormously for long-term governance: service scope, and specifically which services will still be available down the road.
Whether you are negotiating a new BTP contract today or renewing an existing CPEA agreement, this is a governance moment that shapes your entire governance structure for the next contract term.
1. Background: Why BTPEA Extends CPEA Rather Than Replacing It
CPEA, the Cloud Platform Enterprise Agreement, is the older of the two models. Introduced as a commit-to-consume contract, it provides access to a historically grown catalog of roughly 85 to 90 BTP services. Customers purchase an annual credit budget upfront and draw it down flexibly across available services.
The model works. For many existing customers running BTP on a stable set of services, CPEA remains a valid choice. But it hit a structural ceiling: the catalog stopped growing. New services that SAP developed after CPEA's introduction have not been added to the model.
BTPEA, the BTP Enterprise Agreement, was introduced in 2024 as the strategic successor model. It does not retire CPEA; it extends it. Existing CPEA customers can let their contracts run to term. New customers typically start with BTPEA today (Source: ASUG, SAP Experts Detail New SAP BTP Enterprise Agreement).
This governance moment between the "legacy path" and the "new standard model" applies to every organization facing a BTP renewal decision.
2. Service Scope: Broader Historical Coverage in CPEA, Newer Services in BTPEA
The most visible difference between the two models is the service catalog.
CPEA offers broad historical coverage: the catalog has grown over years and includes services that play a smaller role in newer versions of the SAP portfolio. For customers who have built their processes on this legacy scope, that is an advantage. The services their workflows depend on are present and covered by the contract.
BTPEA starts from a different premise: low-adoption services were removed from the catalog. In their place, every service SAP has introduced since BTPEA's launch is included. If you want to use new SAP technologies within the BTP ecosystem, BTPEA is the only path.
In practice, neither model is simply broader or narrower. CPEA is deeper in legacy coverage. BTPEA points further forward. Which model fits depends on which services your organization uses today and which it plans to use over the next three to five years.
3. SAP Analytics Cloud: The Most Prominent Addition in BTPEA
SAP Analytics Cloud (SAC) is the clearest illustration of BTPEA's strategic direction. SAC, the platform for business intelligence, planning, and predictive analytics, is not part of the CPEA catalog. It was only brought into the enterprise agreement model with the introduction of BTPEA (Source: ASUG, SAP Experts Detail New SAP BTP Enterprise Agreement).
What this means for CPEA customers: if you want to consume SAP Analytics Cloud under an enterprise agreement, you need BTPEA. If you run SAC through a separate subscription, or plan to, you can stay on CPEA, but you will then carry two separate contract structures.
Beyond SAP Analytics Cloud, BTPEA includes new AI services from the SAP AI portfolio and further additions that SAP continues to expand. The SAP Discovery Center Service Catalog (https://discovery-center.cloud.sap/) shows in real time which services are available under which model. That catalog is one of the most important references for any governance moment around model selection and renewal preparation.
4. Deprecation Policy: Group 1 and Group 2 Services in BTPEA
BTPEA introduces a structured deprecation policy that CPEA does not have in this form. It divides services into two groups and defines different rules for how long a service remains available after a deprecation notice.
Group 1 (Core Services) are services for which SAP guarantees support through the end of the current contract term. You can run these services in production without expecting a forced migration mid-contract. This protection mirrors the basic commitment CPEA customers have across their entire service scope.
Group 2 (Innovation Services) are newer or low-adoption services that SAP can remove from the catalog or transition to Group 1 with at least six months' advance notice (Source: ASUG, SAP Experts Detail New SAP BTP Enterprise Agreement). Those six months are not a buffer for relaxed planning; they are the window in which migration planning must begin.
For infrastructure governance, this has a direct implication: every productive deployment on a BTPEA service should document from day one which group that service belongs to. This is not a one-time setup task; it is part of ongoing deprecation monitoring.
Two services relevant to many BTP customers recently came under deprecation pressure: SAP Datasphere and SAP Analytics Cloud showed deprecation warnings in certain BTP Cockpit instances referencing an end-of-2025 date (SAP KBA 3630656, SAP KBA 3632353). The migration path for Datasphere points toward SAP Business Data Cloud. Customers running Datasphere in production should verify the current status of these announcements, as SAP migration plans continue to evolve.
5. What Migration Requires, and What It Does Not
Migrating from CPEA to BTPEA is technically less disruptive than many expect. The Global Account, all subaccounts, running services, and all configurations remain unchanged. Only the new commercial terms are activated on the existing Global Account (Source: ASUG, SAP Experts Detail New SAP BTP Enterprise Agreement).
The technical side is manageable. The commercial side demands more care.
First, the new contract establishes a new pricing baseline. BTPEA terms may differ from your existing CPEA terms. A precise side-by-side comparison of both pricing structures is a required step before any migration decision.
Second, services included in your current CPEA contract but not carried over to BTPEA must be continued as separate subscriptions if you still need them. This primarily affects legacy services with lower adoption rates. A comparison of your current service inventory against the BTPEA catalog in the Discovery Center will show you exactly which services fall into this category.
Third, timing matters. Migrations typically happen during renewal negotiations. A running CPEA contract is not simply converted; it runs to the end of its term. The governance moment for a migration decision is therefore the renewal window, not the middle of an active contract.
6. Decision Framework: A Checklist for Existing Customers
Choosing between CPEA and BTPEA is not an abstract model preference. It is a concrete governance decision with consequences for service availability, cost, and governance overhead. The following checklist structures the relevant questions.
Service Analysis
Which BTP services are you actively using today? Are those services included in the CPEA catalog? Are any of them absent from the BTPEA catalog and would need to be continued as separate subscriptions?
Forward Planning
Do you plan to use SAP Analytics Cloud under an enterprise agreement? Do you want to include new SAP AI services or other BTPEA-exclusive additions in your platform strategy? Is future-readiness a strategic criterion for your model selection?
Deprecation Risk
Are you running productive workloads on services that would potentially fall into Group 2 under BTPEA? Do you have deprecation monitoring in place that notifies you in time before a service is retired?
Commercial Comparison
Are the BTPEA terms at your current renewal point more favorable, comparable, or more expensive than your existing CPEA terms? Are there services that would fall outside the credit pool after a model migration and need to be sourced separately, increasing total cost?
Timing
When does your current contract term end? Is there enough lead time for a thorough analysis, or would a migration decision be made under time pressure?
If your service analysis shows that all actively used services are available in your existing CPEA catalog, you have no need for BTPEA-exclusive services, and renewal terms are comparable, there is no compelling reason to act. CPEA continues to run, and SAP has not announced a retirement of the model.
If, on the other hand, SAP Analytics Cloud, new AI services, or other BTPEA-exclusive additions are relevant to your platform strategy over the next few years, the next renewal is the right governance moment for a migration decision.
Conclusion
CPEA and BTPEA solve the same problem: flexible BTP consumption from a pre-purchased credit budget. The difference is service scope and strategic direction.
CPEA is the proven model for customers with a stable service mix and no immediate need for new SAP additions. BTPEA is the strategic standard for new customers and for existing customers who want to use SAP Analytics Cloud, new AI services, or future innovation services under an enterprise agreement.
All four governance moment areas, usage, entitlements, infrastructure, and cost, matter in both models. The difference is the deprecation policy: in BTPEA, monitoring Group 2 services is a structural governance requirement that does not exist in CPEA in the same way.
Treating the model selection as a one-time purchasing decision means discovering, over the course of the contract, that the real governance work begins afterward.
Next Steps
If you want to understand how your current BTP contract model aligns with your actual usage, and which governance moments to address before your next renewal, a Contract Check is a good starting point. In four weeks, you get a clear picture of your current contract situation and a solid basis for your next decision.
Request a Contract Check | BTP FinOps Hub
Further reading: Understanding Capacity Units and Deprecation Groups | BTP Credit Expiration and Overage Mechanics
Next Steps
If you would like your current contract reviewed for risks and available commercial levers: the FinOptory Contract Check is a fixed-price engagement that delivers a structured basis within four weeks.
This article is part of our topic hub on BTP FinOps and credit governance. To have one specific contract assessed, the FinOptory Contract Check delivers a structured basis within four weeks.
ASUG: SAP Experts Detail New BTPEA
Last updated: July 2026