RISE with SAP Migration Costs Cost Optimisation Tactics

Run an Independent Licence Baseline

SAP's RISE quote is based on assumptions about your current user population, licence scope, and system complexity. You have no obligation to accept those assumptions. Before RISE contract negotiation begins, run an independent baseline audit of your existing SAP environment (ECC, legacy, other systems). Count actual named users. Count actual functional user roles. Identify which integration scenarios exist today and which will be created during S/4HANA migration. Map indirect access exposure. This baseline becomes your negotiating anchor — the factual denominator against which SAP's RISE quote is sized.

The mechanics are straightforward: SAP will propose a RISE user count, BTP commitment, and support scope. Your baseline audit either validates or challenges each component. When SAP quotes 5,000 named users and your audit identifies 3,200 active users (with another 1,800 stale accounts that can be deactivated during migration), you have concrete leverage to reduce the user count assumption and therefore the monthly subscription fee.

Cost: €30K–€50K for independent baseline audit. Saves multiples of that across the contract term. SAP licence optimisation advisory routinely includes this baseline work.

Challenge the BTP Credit Allocation

RISE bundles include BTP credits — compute, storage, analytics infrastructure. SAP allocates these based on historical consumption patterns. In practice, most enterprises consume 40–60% of the allocated credits. The unused credits expire at contract renewal. You're paying for capacity you don't use.

Demand that SAP model your specific use cases — the extensions you plan to build, the integrations you plan to deploy, the analytics tools you plan to run. Map your planned BTP consumption against the offered credit allocation. If SAP's standard bundle allocates 100,000 credit units and your actual need is 35,000 units, renegotiate the allocation downward. Document this in the contract as a specific commitment, not a guideline.

Secondary benefit: when you force SAP to right-size BTP to your actual consumption, you reduce architectural pressure to over-use BTP simply to consume allocated credits. Your integration and extension strategies become driven by technical merit, not budget burning.

Audit Active vs Inactive Users Aggressively

RISE contracts scale linearly with named users. SAP's baseline assumption includes all users with any SAP system access, including inactive accounts, system accounts, and legacy access from decommissioned applications. A typical large enterprise has 15–25% stale user records in its SAP user base.

During contract negotiation, demand detailed user account reconciliation: filter to actually active users (logged in within 90 days), exclude service and batch accounts, exclude integration accounts (which should be licensed separately, if at all), exclude deactivated legacy access. Map the resulting user population to RISE pricing. Most enterprises reduce their SAP user count assumption by 20–35% when stale accounts are excluded. On a 5,000-user estimate, that's 1,000–1,750 users — which translates directly to monthly subscription fee reduction.

This must be done before contract signature. Post-go-live user count verification and "true-up" mechanics almost always go against the buyer — SAP's perspective on which accounts count as active is more expansive than yours, and by year 1, migration activities, reorganisations, and system complexity have made manual verification nearly impossible.

Run an Independent Hyperscaler RFP

RISE pricing includes hyperscaler infrastructure passed through from AWS, Azure, or GCP. SAP uses commercial agreements with hyperscalers that include margin. You don't have to accept SAP's default hyperscaler pricing. Independent RFPs to AWS, Azure, and GCP for your specific workload — S/4HANA compute, database, storage, backup, disaster recovery — typically surface 15–25% cost variance between hyperscalers. SAP may try to claim lock-in to a specific hyperscaler; in practice, that lock-in is contractual, not technical. S/4HANA runs on all three major clouds with equivalent capability.

The RFP should specify: instance types and sizes (this comes from RISE discovery), storage requirements (database plus backup), network egress patterns (unknown but estimated), backup and DR requirements, and the 3-year commitment period. Map the resulting quotes. Select the lowest-cost provider. Negotiate with SAP to use that infrastructure cost baseline, with actual charges passed through without markup. If SAP resists, this is leverage — you're offering to shift your cloud spend to a different hyperscaler if pricing isn't competitive.

Negotiate Reserved Instances vs On-Demand

Hyperscaler pricing has two tiers: on-demand (pay per hour) and reserved instances (commit for 1–3 years, receive 30–50% discount). RISE infrastructure is stable, predictable, and multi-year. Reserved instances are the economically rational choice. Demand that SAP's infrastructure costs are quoted on reserved instance pricing, not on-demand. This requires coordination with your hyperscaler selection (Tactic 4) — reserved instance discounts are specific to compute type, region, and commitment period.

The savings are substantial. A typical S/4HANA deployment might consume €50K–€100K monthly in on-demand infrastructure. Reserved instances reduce this by 30–40% — roughly €15K–€40K monthly. Across a 3-year RISE contract, that's €540K–€1.4M in cumulative savings. It's a straightforward negotiating point: you're asking SAP to use the same cost optimisation discipline that any cloud-native customer would apply.

Understand and Minimise Data Egress Charges

Hyperscalers charge for data egress — moving data out of their cloud infrastructure. RISE workloads generate egress through integrations (pulling data from on-premise systems, pushing data to third-party applications), analytics (extracting data for reporting and BI), and backup (replicating to secondary regions). SAP's RISE pricing assumes baseline egress; complex, integration-heavy environments exceed that baseline significantly.

Egress costs compound quickly: €0.12 per GB egress on AWS, similar rates on Azure and GCP. A typical enterprise with 50+ integrations and daily data synchronisation can generate 10–50 TB of monthly egress, which translates to €1,200–€6,000 monthly in egress charges alone. Over a 3-year contract, that's €43K–€216K in unplanned costs.

Demand that SAP model your specific integration architecture and quantify egress requirements before contract signature. Negotiate an egress cost cap or inclusion threshold in the RISE contract. If SAP won't cap egress, design your integration layer to minimise it — prefer bulk exports over transactional sync, compress data in transit, and evaluate whether all integrations are genuinely necessary. This architectural discipline should be driven by economics (egress costs), not forced retrospectively.

Use SAP's Migration Tooling (Identify What's Included)

RISE contracts include migration services and tooling — data migration frameworks, landscape tools, testing frameworks, accelerators. SAP doesn't always volunteer what's included. Migration services are sometimes quoted as separate consulting projects. Demand a detailed list of what RISE includes: accelerators, reusable code libraries, data migration tools, testing tools, landscape automation, and support hours for each. For each tool, quantify internal effort that would otherwise be required or third-party consulting that can be displaced.

Most RISE migrations involve 500K–2M lines of custom code review, 10–50 TB data migration, 20–40 go-live waves. SAP's included tooling can offset significant consulting cost. A €2M custom code analysis and remediation effort might be 40% displaced by SAP's migration accelerators. That's €800K in internal effort saved. This value should reduce your RISE base price negotiation — SAP is providing embedded consulting value that would otherwise be external cost.

Deploy Selective Brownfield vs Greenfield Approach

RISE migration can be structured as complete brownfield (migrate 100% of legacy data, code, and configuration to S/4HANA) or selective brownfield (migrate critical processes to S/4HANA, retire non-core legacy functionality, consolidate redundant systems). The selective approach is cheaper but requires strategic discipline.

Complete brownfield migrations carry high cost because you're moving everything, including legacy technical debt, obsolete data, and code that should have been retired. Selective migrations require upfront analysis: which legacy systems genuinely need to move to S/4HANA? Which can be retired? Which can run parallel for a transition period? This analysis increases discovery cost but often reduces total migration cost by 25–40%. A legacy accounts payable system running on an aging platform might be consolidated into S/4HANA Finance. A niche sales forecasting system that runs quarterly might be retired (its data is in S/4HANA anyway). An old CRM system might run parallel for 18 months while sales processes transition.

Negotiate RISE pricing on the basis of the selective migration scope, not a complete legacy-to-cloud conversion. Document which legacy systems are in-scope, which are out-of-scope, and which have defined end-of-life dates. This reduces user counts, integration complexity, and data volume — which ripples through the entire RISE cost structure.

Demand Phased Go-Live With Cost Gates

RISE contracts typically cover migration and go-live support through a fixed date (often 12–24 months). The risk structure is binary: go-live on schedule, or costs explode. This creates pressure to cut corners, compress timelines, and avoid scope management discipline.

Demand a phased go-live structure with defined cost gates: Phase 1 (Finance & Accounting, 4 months), Phase 2 (Operations & Logistics, 4 months), Phase 3 (Sales & Distribution, 4 months). Each phase has a defined scope, go-live date, and SAP support allocation. Between phases, review actual costs against budget. If Phase 1 runs 10% over, adjust Phase 2 scope or timeline accordingly. This requires SAP to commit to fixed Phase costs and limits their ability to bill for scope creep after the fact.

Secondary benefit: phased go-live reduces execution risk. You learn from Phase 1 and apply those lessons to Phase 2. You also have data migration and user adoption success in a smaller domain before scaling to the whole enterprise. This typically results in better quality outcomes and fewer production support issues post-go-live — which reduces post-go-live cost inflation.

Lock Price Escalation Caps in the Order Form

RISE list prices can increase annually. SAP's standard language permits "market-aligned" increases with SAP as the arbiter. In practice, SAP has increased RISE list prices by 4–8% annually. On a €3M annual RISE cost, an annual 6% increase compounds to 38% over a 5-year contract — an additional €1.14M in cost.

Demand an explicit price cap in the Order Form (not buried in terms & conditions): maximum annual increase of 3% or tied to CPI (Consumer Price Index) + 1%, whichever is lower. Make this a hard contractual ceiling, not a guideline. Pair it with specific language about what does and doesn't trigger price increases: additional users and new modules trigger increases; optimisation and efficiency don't. This forces SAP to absorb the cost of its own efficiency gains and prevents surprise escalations.

Get User True-Down Rights in Writing

RISE contracts include user count assumptions. During year 1, actual user populations often differ from assumptions: reorganisations, automation, attrition. SAP typically resists true-down provisions (rights to reduce user counts and receive credit for the reduction). Without explicit true-down language, you're locked into the original user count assumption for the full contract term, even if 20% of those users no longer exist.

Demand true-down rights: the right to reduce your committed user population by up to 15% annually, with credit applied to the following month's invoice. Pair this with annual usage reconciliation (SAP measures, you validate). This gives you flexibility if your environment evolves and eliminates the risk of over-paying for unused users.

SAP will argue this creates "revenue uncertainty." That's exactly the point — it shifts risk from you (locked in) to SAP (incentivised to deliver value that justifies the user population). This is a high-leverage negotiating point because SAP genuinely dislikes it. That dislike signals its importance to you.

Include Independent Licence Review Rights Every 2 Years

RISE contracts run 3–5 years. Your environment changes. Users migrate, systems consolidate, integrations evolve. Without periodic review rights, you can't challenge whether your original assumptions — user count, BTP allocation, support scope — remain accurate. You're stuck with Year 1 assumptions through Year 5.

Demand a contractual right to independent licence audit every 24 months. This audit measures actual vs. assumed users, actual vs. allocated BTP consumption, actual vs. estimated infrastructure costs. If the audit identifies material variance (e.g., 30% fewer active users than assumed, 50% of allocated BTP unused), you have the right to renegotiate pricing for the subsequent contract year. This keeps SAP honest about baseline assumptions and gives you leverage to address over-sizing as your environment matures.

Cost: €50K–€100K per audit. Savings potential: 5–15% of RISE annual cost if audit identifies material over-sizing. On a €3M annual contract, 10% savings is €300K — easily justifying the audit cost and giving you recurring leverage throughout the contract term.