RISE with SAP Cost Optimisation Tactics: Where the Real Savings Are

Reduce BTP credits to actual consumption — not SAP's theoretical maximum

SAP BTP (Business Technology Platform) credits are the component of RISE where overpayment is most systematic and most correctable. SAP's sales teams are trained to size BTP credits generously — their commission structure rewards larger deals, and BTP credits are the most opaque component of the bundle, making oversizing harder to detect.

The right-sizing process requires three steps. First, map your actual BTP use cases: list every integration, extension, analytics, or automation workload you plan to run on BTP in the 5-year contract window. Be honest about what you will realistically implement versus what is theoretical. Second, translate use cases to BTP service consumption: work with your technical architect or an independent BTP specialist to estimate actual credit consumption per service type. Third, compare your mapped consumption against SAP's proposed credit volume. The typical finding is that SAP has proposed 2–3× the credits your mapped use cases require.

The commercial outcome of right-sizing: remove excess credits from the initial deal, negotiate a defined credit expansion mechanism (add credits at pre-agreed unit pricing as consumption grows), and structure a multi-year rollover provision for credits consumed unevenly across the contract period. On a €10M RISE deal where BTP represents 15% of the total, right-sizing from 3× to 1.5× consumption reduces the BTP component by 50% — a saving of approximately €750K over 5 years.

Challenge every user count and type in SAP's RISE proposal

S/4HANA Cloud Private Edition pricing is fundamentally driven by named users and their licence types. Professional users are the most expensive — typically 5–10× the cost of Limited Professional, Employee, or Functional users. SAP's RISE proposals almost invariably start from USMM or LAW data that reflects the ECC landscape — an environment that has accumulated user access over years of system growth, departmental additions, and project-based assignments.

The rationalisation process identifies four categories of user cost reduction:

• Inactive users: Users who have not logged in for 90+ days in ECC. These should be removed from the S/4HANA user count entirely.
• Over-classified users: Users assigned Professional licences based on role breadth, where a Limited Professional or Employee licence covers their actual transaction footprint in S/4HANA.
• Digital Access candidates: Users who primarily create documents (Orders, Deliveries, Invoices) through workflow or automation — these may be better covered by Digital Access documents than named user licences.
• Role redesign opportunities: S/4HANA's role design differs from ECC. Some ECC Professional roles can be split into multiple S/4HANA roles at lower-tier pricing without any functional loss.

The combined impact of rationalisation across these four categories typically reduces the named user cost component of RISE by 15–30%. On a large RISE deal where user licences represent €6M of the total TCV, that is €900K–€1.8M in savings over 5 years.

Price your RISE infrastructure against Azure, AWS, and GCP in competition

Infrastructure is the component of RISE where SAP has the least pricing authority — because it is ultimately delivered by a third-party hyperscaler, and that hyperscaler competes for your business. Enterprises that accept SAP's first infrastructure pricing — derived from a single hyperscaler assumption — forgo the savings that competitive RFP delivers.

The benchmarking process: specify your infrastructure requirements (compute size, storage, networking, availability zone, DR configuration) based on your S/4HANA sizing exercise. Submit those requirements to all three hyperscalers simultaneously. Request pricing for both committed-use pricing (1-year, 3-year, 5-year terms) and on-demand pricing. Evaluate the proposals against: headline cost, included services, hyperscaler-specific RISE incentive programmes, and DR/failover commitments.

Infrastructure benchmarking consistently identifies savings of 12–18% versus SAP's initial infrastructure assumption. Additionally, both Azure and AWS operate RISE-specific incentive programmes that can contribute €200K–€500K in additional value on larger deals through funded proof-of-value engagements, migration assistance, and marketplace credits.

Maximise the value you extract from the 22% Enterprise Support rate

SAP Enterprise Support at 22% of NLV annually is a fixed rate that SAP rarely reduces in absolute terms. For a RISE deal with €5M NLV, that is €1.1M per year — €5.5M over 5 years. The cost optimisation approach for Enterprise Support is not to reduce the rate (which is nearly impossible), but to: (a) reduce the NLV base through user reclassification and BTP right-sizing, which automatically reduces the support cost; (b) negotiate premium support credits that offset the cost; and (c) extract SLA improvements and escalation rights that increase the value of the support you are paying for.

Support credit negotiations should target: additional Technical Quality Manager hours, preferred escalation routing, reduced response time SLAs for P1 incidents, and credits against future renewal pricing. Our SAP support cost reduction service covers this in detail for enterprises where support is the highest-cost RISE component.

Right-size and correctly structure migration assistance to maximise value

RISE migration costs — the SI implementation work, data migration, integration rewriting, and testing — are not formally part of the SAP contract, but SAP has direct influence over them through its implementation partner relationships and migration assistance credit programmes. The cost optimisation opportunity here operates at two levels.

At the SAP level: negotiate maximum migration assistance credits, structured as financial offsets against the RISE contract TCV rather than service credits that must be consumed through SAP-specified channels. Credits structured against TCV reduce your actual cash outflow. Credits that must be consumed through named services at SAP's standard rates are worth materially less.

At the SI level: the choice of implementation partner has a significant impact on migration cost. SAP RISE contracts sometimes include preferred partner provisions — challenge these and retain competitive SI selection rights. Three competing SI proposals on an identical statement of work typically produce a 15–25% cost range, representing significant savings on what is often the largest single cost component of the RISE programme.

Build a corrected Total Cost of Ownership model before comparing any pricing

All five tactics above are more powerful when deployed within a correctly constructed TCO model. The most common cost optimisation failure is enterprises comparing RISE pricing against the wrong baseline — typically their existing annual SAP maintenance invoice. That comparison is structurally misleading.

A correct TCO model for RISE includes: current on-premise software licence cost, current maintenance cost (including both SAP Enterprise Support and any third-party maintenance), current infrastructure cost (hardware, data centre, networking), current internal IT labour cost for SAP operations, projected migration cost (one-time), and projected RISE annual cost over 5 years (including escalators). Each line item should be costed independently before any RISE pricing comparison.

The corrected TCO model often shows that RISE is genuinely economical versus the on-premise alternative — but the savings are smaller than SAP's sales pitch suggests, and the distribution of cost across years is different. That difference is negotiating ammunition: if SAP's 5-year TCO advantage is €3M but achievable in RISE Year 4–5 only, the enterprise has legitimate grounds to demand front-loaded RISE cost reductions to make the economics work across the entire contract term.