How to Use This Assessment

Work through each of the 20 questions below. Each item includes three answer options — flagged red (RISE risk), amber (context-dependent), or green (on-premise advantage) — followed by independent expert commentary from Redress Compliance's SAP practice. There is no scoring algorithm: the questions are designed to surface the right conversations with your board and sourcing team, not produce a simple number.

If you answer predominantly red, you should approach a RISE transition with significant caution and independent advisory support before signing anything. If you answer predominantly green, on-premise S/4HANA with third-party support may offer a better long-term TCO. Most organisations land in the amber zone — meaning the outcome depends almost entirely on negotiation quality, not the choice of deployment model per se.

Red — signals RISE risk or on-premise advantage
Amber — context-dependent; requires deeper analysis
Green — favours or reduces risk in this option

Section 1: Strategic Timing & ECC Deadline

Question 01
Are you still running SAP ECC and relying on mainstream SAP support beyond December 2027?
Yes — no migration plan yet In planning — timeline unclear No — already on S/4HANA
SAP's mainstream support for ECC ends on 31 December 2027. Optional extended maintenance runs to 2030 but at additional cost and with reduced scope. Customers using the 2027 deadline as justification for a rushed RISE decision are handing SAP enormous negotiating leverage. If your project timeline is genuinely constrained, you have less room to push back on price, terms, or contract structure. Build in at least 6–9 months of pre-signature advisory and due diligence — even if that compresses the implementation timeline. Panic buying is the most expensive form of SAP procurement.
Question 02
Has SAP cited the 2027 ECC deadline as the primary reason you should move to RISE rather than on-premise S/4HANA?
Yes — heavily emphasised Mentioned but not the focus No — deployment model discussed neutrally
SAP sales teams are incentivised to close RISE, not on-premise S/4HANA conversions. If the 2027 deadline dominates the conversation, treat this as a negotiating posture rather than neutral advice. On-premise S/4HANA remains a fully supported path — SAP simply innovates there at a slower pace post-2027. Third-party support from providers such as Rimini Street extends ECC support economics while you plan a considered migration. The deadline is real, but the urgency to choose RISE specifically is manufactured.
Question 03
Is your organisation planning a greenfield S/4HANA implementation (clean-slate, new processes) rather than a brownfield system conversion?
No — heavy brownfield with complex customisations Hybrid approach under evaluation Yes — greenfield, standardised processes
RISE is structurally better suited to greenfield implementations where the organisation is willing to adopt SAP standard processes with minimal custom development. Brownfield conversions that carry decades of ABAP customisation into the cloud environment face a harder path: RISE restricts kernel-level modifications, and migrating complex custom code to BTP extensions adds cost and timeline risk that is rarely fully modelled in initial RISE business cases. Greenfield organisations moving to RISE can realise genuine value; brownfield organisations should model the extension cost before committing.

Section 2: Licensing Model & FUE Exposure

Question 04
Do you have a clear, independently verified count of your Full Use Equivalents (FUEs) and role classifications across all business units?
No — SAP's estimates are the only baseline Partial view — some business units unclear Yes — independently verified count available
FUE is the unit SAP uses to price RISE subscriptions. A single Advanced user (FUE weight 1.0) costs significantly more than a Self-Service user (weight 0.1). If you allow SAP to define your FUE baseline, you will almost certainly be oversized. Audit your actual user population, challenge every Advanced classification, and reclassify casual users as Self-Service or Core before any pricing conversation. Mid-sized enterprises that conduct a pre-negotiation FUE audit routinely reduce their SAP-quoted baseline by 15–30%, translating directly into lower annual subscription cost.
Question 05
Have you modelled whether purchasing to the next FUE pricing tier would be cheaper than your current volume estimate?
No — not aware this is an option Aware but not yet modelled Yes — tier optimisation included in business case
SAP's FUE pricing uses steep volume tiers. A customer needing 4,800 FUEs may pay more than a customer contracting for 5,001 FUEs because the higher volume unlocks a lower per-unit rate. This counterintuitive dynamic is well-documented but rarely surfaced by SAP account executives. Always model the cost at your estimated volume, at the next tier ceiling, and at a conservative upside scenario. The difference can exceed €400,000 annually at enterprise scale. Independently mapping your volume against published tier thresholds is a one-day exercise with material ROI.
Question 06
Does your business case model the full 5-year and 10-year TCO of RISE versus on-premise S/4HANA, including all infrastructure, support, BTP, and upgrade costs?
No — only Year 1 subscription cost compared 5-year model exists but BTP costs not included Yes — full 10-year multi-scenario TCO completed
RISE Year 1 cost is almost always lower than the on-premise capital alternative when the comparison ignores infrastructure refresh, upgrade projects, and internal IT headcount. The economics frequently reverse by Year 4–6 as subscription fees compound and BTP consumption charges accumulate. A rigorous TCO model must include on-premise hardware refresh cycles (typically every 4–5 years), annual SAP maintenance at 22%, third-party support alternatives at 14–18%, and RISE annual price escalation clauses. Organisations that build a proper multi-year model before signing are significantly better positioned to negotiate terms and make an informed deployment choice.

Need an independent SAP RISE vs on-premise TCO model?

We've built 500+ independent SAP commercial models. Buyer side only, no SAP relationship.
Request a Review →

Section 3: Customisation & Technical Architecture

Question 07
Does your current SAP landscape include significant custom ABAP development, third-party bolt-ons, or deep kernel-level modifications?
Yes — extensive custom code and modifications Moderate — some custom code, mostly standard No — largely vanilla SAP configuration
RISE with SAP restricts direct access to the SAP application kernel. Custom modifications that run natively on-premise must be rebuilt as BTP extensions, side-by-side add-ons, or abandoned entirely. SAP's own custom code analysis tools (ABAP Test Cockpit, Custom Code Migration Worklist) give a quantitative view of remediation scope, but the commercial cost of BTP extension development is rarely included in vendor-provided RISE business cases. For organisations with 500+ active custom programs, the extension rework cost can exceed the subscription savings over five years. Get this modelled independently before signing.
Question 08
Have you identified all third-party systems that integrate with your current SAP environment and assessed their Digital Access / indirect access implications under RISE?
No — integration landscape not fully mapped Partially mapped — major integrations known Yes — full integration inventory with DA impact assessed
A common RISE misconception is that moving to the cloud eliminates indirect access risk. In reality, SAP's Digital Access licensing model follows the customer into RISE. High-volume document creation triggered by third-party systems — IoT platforms, e-commerce engines, EDI hubs — can require additional Digital Access licence purchases that are not included in the base FUE subscription. At enterprise scale, undisclosed DA exposure running to millions of documents per year can add €1M+ in annual licence cost. Map every integration that creates, reads, updates, or deletes SAP documents before your pricing baseline is set.
Question 09
Is your organisation planning to use SAP Business Technology Platform (BTP) heavily for extensions, integrations, or analytics workloads?
Yes — BTP is central to our architecture plan Moderate — some BTP use planned No — minimal BTP dependency anticipated
RISE subscriptions include a baseline allocation of BTP credits, but enterprise usage patterns routinely exceed this allocation. BTP overage charges are priced per consumption unit and can escalate unpredictably as analytics, integrations, and AI workloads scale. SAP does not proactively alert customers when BTP credits approach exhaustion — you receive an invoice. Negotiate a hard BTP consumption cap and overage notification threshold into your RISE contract, and build BTP consumption into your Year 2–5 cost model with a 30–40% buffer. The included allocation is a marketing number, not a realistic enterprise baseline.

Architecture Reality Check

Of the 500+ SAP engagements Redress Compliance has conducted, the organisations most likely to overspend on RISE are those with complex integration landscapes, significant custom code debt, and a business case that was built using SAP's own modelling tools. An independent technical and commercial review conducted before heads of terms are signed consistently identifies 20–35% in avoidable spend.

Section 4: Contract Risk & Vendor Lock-In

Question 10
Have you reviewed the RISE contract's auto-renewal provisions and understood the notice period required to prevent automatic renewal?
No — contract not reviewed independently Partially reviewed — legal team has seen headline terms Yes — auto-renewal terms negotiated and notice period confirmed
Standard RISE contracts include auto-renewal clauses that trigger unless written notice is provided 6–12 months before the term end date. Missing this window locks you into another full term — typically 3 years — at whatever price SAP sets at renewal. Enterprise procurement teams with strong vendor management practices build renewal notification dates into their governance calendars at contract signature. Negotiate the notice period down to 90 days and ensure termination rights are unambiguous. This is a non-trivial negotiation point; SAP's standard terms favour the vendor by design.
Question 11
Has your legal team reviewed the RISE contract's termination-for-convenience provisions and confirmed your obligations if you wish to exit early?
No — standard SAP terms accepted without review Reviewed but not fully negotiated Yes — termination provisions independently negotiated
RISE contracts do not typically permit termination for convenience during the committed term. Early exit requires payment of all remaining subscription fees as a penalty. For a 5-year RISE commitment at €4M annually, early termination in Year 2 can expose the customer to €12M in residual liability. This is not theoretical: business acquisitions, divestments, and strategic pivots routinely create pressure to exit ERP commitments ahead of schedule. Negotiate a material change-of-control clause, a partial divestment accommodation, and a genuine termination-for-convenience right with defined penalty caps.
Question 12
Have you verified that your existing perpetual SAP licences are being surrendered rather than simply dormant under the RISE contract?
No — licence fate not confirmed in writing Informally discussed but not in contract Yes — perpetual licence treatment confirmed contractually
When organisations move to RISE, SAP typically requires perpetual on-premise licences to be surrendered as part of the conversion. This eliminates the fallback option of returning to on-premise operation if RISE does not deliver expected value. Some organisations have successfully negotiated a licence "parking" arrangement where perpetual rights are retained for a defined period. If SAP insists on full surrender, ensure you receive a clearly defined conversion credit that genuinely offsets historical maintenance payments. The perpetual licence is a real asset; surrendering it without appropriate credit is a negotiating failure.
Question 13
Does the RISE contract include explicit data portability rights and SAP obligations to support your data extraction and migration to an alternative environment if you exit?
No — data portability not addressed in contract General language included but no specific obligations Yes — specific data export SLAs and exit assistance defined
SAP's standard RISE terms provide limited data portability assurances. At contract termination, data may only be accessible for 30 days, and SAP assistance with extraction, transformation, and migration to an alternative environment is not guaranteed beyond basic file exports. For a complex S/4HANA implementation with years of transactional data, this creates significant operational risk at exit. Negotiate specific data extraction SLAs, a minimum 90-day post-termination data access window, and defined SAP obligations to provide migration support including API access and technical documentation for your specific system configuration.

Section 5: Pricing & Annual Escalation

Question 14
Does your RISE contract contain an annual price escalation cap, and have you modelled the compounding impact of SAP's typical 5–7% annual increase over your full term?
No cap — SAP can increase at will at renewal CPI cap included but compounding not modelled Explicit cap ≤3% p.a. with compounding modelled
SAP has historically increased list prices by 5–7% annually and has applied additional escalation through rebranding and packaging changes (the 2025 "Cloud ERP Private" relaunch being the most recent example). Without a contractual cap on annual price increases within your committed term and at renewal, your Year 3 and Year 4 costs are unknown at the point of signing. Negotiate a fixed in-term price with a CPI-linked cap at renewal, capped at no more than 3–4% per annum. Model this cap compounding over a 10-year horizon against on-premise maintenance at 22%: the result is often closer than initial presentations suggest.
Question 15
Has SAP offered conversion credits for your existing on-premise licences and maintenance payments, and have these been independently valued?
No credit offered — or credit is a token gesture Credit offered but not independently validated Credit independently valued and confirmed as fair
Conversion credits are one of the most frequently manipulated elements of RISE negotiations. SAP may offer a credit that appears significant but is structured as a discount on inflated list prices, or applied to a higher FUE count than your actual requirement. To validate a conversion credit, calculate the net present value of your remaining maintenance obligations (typically 22% of net licence value annually), and compare this against the RISE credit on a like-for-like basis. Benchmarked mid-market RISE deals at 300–500 FUE typically achieve 35–45% off list price inclusive of conversion credit. If your offer is below this range, negotiate harder or bring independent advisors into the room.
Question 16
Have you evaluated whether cloud infrastructure costs within RISE represent fair market value, or whether SAP is applying a significant mark-up over hyperscaler list pricing?
No — infrastructure cost opaque within RISE bundle Some visibility but not line-by-line breakdown Fully benchmarked against comparable AWS/Azure/GCP pricing
RISE bundles SAP application software, managed services, and cloud infrastructure (typically on AWS, Azure, or Google Cloud) into a single subscription fee. SAP does not disclose its own hyperscaler pricing or the mark-up applied to infrastructure costs. In our experience across 500+ engagements, SAP's effective infrastructure charge within RISE exceeds comparable hyperscaler list pricing by 20–35%, and hyperscaler list pricing itself includes significant enterprise discount potential that SAP does not pass through. For organisations with significant data volumes and compute requirements, independently provisioning infrastructure and taking SAP software as a separate licence can be materially cheaper — though this requires on-premise or private cloud deployment.

Download our SAP Audit Defence Framework.

Independent negotiation tools, contract review templates, and benchmark data for SAP buyers.
Download Free →

Section 6: On-Premise S/4HANA Considerations

Question 17
Does your organisation have the internal IT infrastructure, staffing, and security capability to operate on-premise S/4HANA effectively over the next 7–10 years?
No — IT team lacks cloud or ERP operations capability Partial capability — would require augmentation Yes — strong internal IT with ERP operations experience
On-premise S/4HANA is not a zero-effort deployment model. It requires maintained infrastructure, a qualified Basis team, a defined upgrade cadence, and security patching capability. Organisations whose IT teams have eroded over years of managed services or whose data centres are already scheduled for decommission face a genuine capability gap that makes on-premise less viable. However, "we lack IT capability" is not a reason to accept RISE at any price — it is a reason to explore hosted or managed private cloud S/4HANA alternatives, which can provide similar operational simplicity to RISE with considerably more commercial flexibility.
Question 18
Have you considered third-party SAP support providers as an alternative to SAP's own 22% annual maintenance for an on-premise S/4HANA deployment?
No — assumed SAP support is the only option Aware but not yet evaluated commercially Yes — third-party support evaluated and included in TCO
SAP's annual maintenance fee of 22% of net licence value represents one of the highest support costs in enterprise software. Third-party support providers typically charge 14–18% of the same base for equivalent or superior support coverage, including support for older releases and custom code — areas where SAP's own support is increasingly limited. Switching to third-party support on an on-premise S/4HANA deployment can reduce annual support cost by 25–35% while extending the viable life of the deployment. This is a legitimate lever in the RISE vs on-premise business case that SAP's own advisors will never surface.
Question 19
Have you assessed your organisation's data residency, sovereignty, and regulatory compliance requirements and confirmed they are met by your preferred RISE hyperscaler region?
No — compliance requirements not mapped to RISE architecture Partially assessed — some jurisdictions reviewed Yes — full compliance mapping completed and confirmed
RISE data residency is constrained by SAP's hyperscaler region availability. Organisations in regulated sectors — financial services, healthcare, defence — or operating in jurisdictions with strict data localisation requirements (Germany, UAE, India, China) must verify that their required data residency configuration is contractually guaranteed within RISE, not merely operationally intended. GDPR cross-border transfer mechanisms, SCCs, and equivalency decisions must also be confirmed for EU-based organisations. Data sovereignty gaps can create a hard stop for RISE adoption in regulated industries, making on-premise or local private cloud the only compliant option.
Question 20
Are you approaching this procurement at quarter-end or year-end for SAP, and have you leveraged this timing to maximise commercial concessions?
No — signing when SAP says it is ready Aware of timing but not actively using it as leverage Yes — timing strategy is part of negotiation plan
SAP's fiscal year ends 31 December. Quarter-end pressure points are March, June, September, and December. SAP account executives operating against aggressive cloud revenue targets have significantly more authority to offer price reductions, additional BTP credits, extended payment terms, and favourable contract language in the final two weeks of each quarter. This is one of the most reliably effective and underutilised levers available to SAP buyers. If your procurement timeline is flexible, align your signature date with a quarter-end. If SAP pushes for urgency outside this window, treat the urgency as a negotiating tactic rather than a genuine commercial constraint.

Summary: What Your Answers Tell You

If your answers skewed predominantly red, the commercial and operational risks of a RISE commitment are material and should be stress-tested by independent advisors before heads of terms are agreed. Signing a 5-year RISE contract at standard list pricing without addressing the items flagged red in this assessment is the most expensive mistake we see SAP buyers make.

If your answers are predominantly amber, the deployment model decision is less important than the commercial terms you negotiate. Both RISE and on-premise S/4HANA can deliver strong value — the differentiator is the quality of your pre-signature advisory, the rigour of your FUE baseline, and the commercial protections you negotiate into the contract.

If your answers are predominantly green, on-premise S/4HANA with third-party support and a self-managed upgrade cadence may represent the most cost-effective long-term path, particularly for organisations with strong internal IT capability, significant custom code investment, and a genuinely competitive TCO model.

Factor Favours RISE Favours On-Premise
Customisation depth Low — standardised processes High — extensive ABAP
IT operations capability Limited internal IT staff Strong Basis & infrastructure team
Data residency requirements Flexible / standard jurisdictions Strict localisation / regulated sector
Implementation approach Greenfield / clean-slate Brownfield / system conversion
Contract flexibility needed Long-term commitment acceptable M&A active / frequent structural change
BTP dependency Minimal BTP use planned Heavy extension & integration requirements
Support cost preference Bundled, predictable subscription Third-party support at 14–18%
Innovation cadence Quarterly cloud updates preferred Controlled upgrade schedule preferred

The Redress Compliance Position

We are deployment-model neutral. We have helped organisations negotiate industry-leading RISE deals and we have helped organisations avoid RISE entirely and implement on-premise S/4HANA at materially lower 10-year TCO. The right answer depends on your specific commercial position, technical landscape, regulatory environment, and internal capability — not on SAP's fiscal year targets. What we consistently find is that the organisations that achieve the best outcomes are those that engage independent advisory before the heads of terms conversation, not after.