SAP HANA Cloud is the publisher's cloud-native in-memory database. It sits under the RISE umbrella as the underlying engine, and sells as a standalone subscription for BTP, custom application development and analytical workloads. The commercial mechanics differ across the two surfaces.
HANA Cloud is sold under two distinct commercial constructs. Under RISE with SAP, HANA Cloud is the bundled database engine that powers the buyer's S/4HANA workload; the database is sized by SAP and prices are inside the RISE FUE bundle. As a standalone BTP service, HANA Cloud is sold separately by capacity (compute units and memory) and draws against the buyer's CPEA credit pool or runs on a Pay-As-You-Go basis.
The procurement implication is that the same underlying technology reads under two distinct contractual instruments. A buyer running both an S/4HANA workload under RISE and a custom BTP application using HANA Cloud will have two HANA commitments to size, two burn rates to track and two renewal cycles to plan.
The full read on the RISE bundle structure sits in Anatomy of the RISE bundle; the BTP read sits in BTP, the platform tour and CPEA credit design.
Inside RISE, HANA Cloud sizing is determined by SAP based on the buyer's FUE count, S/4HANA module mix, expected transaction volume and data retention requirements. The sizing arrives as part of the RISE proposal and is rarely the buyer's first choice.
The buyer-side methodology validates SAP's sizing against three independent reads: a benchmark against comparable S/4HANA workloads (drawn from the firm's case-study database), a workload analysis against the actual transaction profile, and a stress-test for peak demand (financial close, year-end, seasonal spikes). Where SAP's sizing reads materially above the validated number, the procurement negotiates the bundle composition.
The negotiation runs against the FUE count and the S/4HANA module mix, not against the HANA Cloud capacity directly. The bundled construct does not break out HANA Cloud as a line item with negotiable terms; the buyer's leverage runs through the wider RISE bundle architecture.
Standalone HANA Cloud on BTP is sold as a subscription against named capacity units. The buyer commits to a defined number of HANA Cloud compute units, memory blocks and storage allocations for the term. The unit consumption draws against the CPEA credit pool or runs on Pay-As-You-Go.
The sizing methodology for the standalone construct mirrors the RISE methodology in technique but differs in commercial position. The buyer has direct visibility into the unit consumption, can flex the commitment quarterly against the published rate card, and can repurpose unused credits across the wider BTP catalogue. The flexibility is the commercial value of the standalone construct.
Where the buyer's BTP application is a small extension on top of the RISE estate, the standalone HANA Cloud is usually the wrong construct; the BTP layer should run against the bundled HANA Cloud through SAP's published integration patterns.
HANA Cloud is hosted on the buyer's choice of hyperscaler (AWS, Microsoft Azure, Google Cloud Platform) and on a defined regional footprint. The data residency posture matters for the buyer in regulated industries and in jurisdictions where the data sovereignty rule is contractual.
The buyer's residency choice is not contractually free across all SAP tiers. The standalone HANA Cloud subscription is region-flexible. The RISE bundle is region-flexible at signing but is region-locked for the term unless the contract carries an explicit migration clause. The full reading sits in RISE hyperscaler choice and SAP data residency.
The EU Sovereign Cloud offering reads under separate commercial and contractual terms, with a regional restriction to specified European data centres and a Sovereign Cloud-specific certification. The procurement runs the residency decision before the sizing decision.
HANA Cloud renewal sits inside the wider SAP renewal posture. The buyer renews the standalone subscription against the validated burn and forecast read; the bundled instance renews inside the RISE renewal at the FUE level. The two cycles can run on different calendars and require distinct preparation timelines.
Where the buyer runs both, the Admodum methodology consolidates the HANA Cloud read across both cycles. The CFO sees one HANA Cloud spend picture; the architect sees one technology roadmap; the procurement runs both renewals against a single methodology.
The renewal engagement runs under one of three Admodum frameworks: fixed fee, contingency / gainshare or annual retainer.
Five checks for the buyer running into a HANA Cloud decision: name the surface (RISE-bundled, standalone-BTP, or both). Validate SAP's sizing against an independent benchmark. Anchor the residency decision before the sizing decision. Track the burn rate and the unit consumption quarterly. Open the next renewal on the buyer's read, not on SAP's proposal.
For the wider SAP reading, return to the SAP pillar, visit the SAP knowledge hub, or open a private conversation with a senior Admodum SAP advisor through /contact/.
A senior Admodum SAP advisor will run the methodology through with your CIO, CFO, procurement team or audit response team on a private call. The engagement runs as fixed fee, contingency or annual retainer. Active SAP audits route directly to the Audit Defence programme.