What Licensing Modifications Mean (and Why They Matter)
A SAP licensing modification is a formal change to an existing SAP licence agreement. This differs from a renewal negotiation or a new purchase. In a modification, you keep your current contract's framework but adjust specific terms: the number of named users, the modules you're licensed for, the deployment model (on-premise, cloud, hybrid), or the licence metric (e.g., converting from named users to consumption-based pricing).
Modifications matter because they allow you to reshape your licence position mid-contract without penalty, assuming you have contractual flexibility. A properly drafted modification prevents a full rebase of your discount structure. If you negotiate a 45% discount on your initial order, a well-structured modification preserves that discount even if you add 50 new users. Conversely, a poorly structured modification can trigger a rebase—SAP can argue that a significant change to your licence scope justifies renegotiating the entire contract at current list prices.
Free SAP Licensing Guide
Download our comprehensive guide covering named user types, audit risk, and optimisation strategies.
Download the SAP Licensing Guide →What You CAN Modify
User Count Changes
You can increase or decrease named user counts. If you're licensed for 500 named users and you've grown to 600, you can add 100 users via modification. The modification process typically involves:
- Entitlement validation: SAP (or your account team) reviews your actual user count, often via SAP's user management console or a self-certification questionnaire.
- True-up fee: You pay for the delta (100 additional users) at your blended rate (i.e., list price minus your discount). For example, if the list price is $200/user and your discount is 45%, you pay $110 per additional user, totaling $11,000.
- Discount preservation: Your existing discount applies to the true-up, preventing a full rebase. This is critical and should be contractually explicit.
Decreasing users is rarer but possible. If you reduce from 500 to 400 named users, you typically cannot reclaim the reduction retroactively. However, you can stop paying for the 100 unused users looking ahead, reducing your annual support and maintenance costs by 22% of the 100-user value (approximately $2,200 per year at $200/user list).
Adding New Modules
You can license additional modules mid-contract. SAP packages functionality into modules: Finance, Supply Chain Management (SCM), Customer Relationship Management (CRM), Human Capital Management (HCM), and many others. If you were initially licensed for Finance and SCM, you can add HCM via modification.
Module additions work similar to user count increases: SAP charges you the list price for the module, minus your existing discount. If your discount is 45%, you pay 55% of the module's list price. The module's annual support fee also applies at 22% of the net licence value. This is a clean way to expand functionality without renegotiating the entire agreement, as long as your discount structure is preserved.
Changing Deployment Model
You can shift from on-premise to cloud, or vice versa, via modification. For example, if you've run SAP on-premise for 10 years and want to move to the cloud, a modification converts your on-premise licence position to a cloud subscription.
This is more complex than adding users or modules because the business models differ. On-premise licences are perpetual (you own them forever); cloud subscriptions are annual or multi-year rentals. SAP typically offers trade-in credit for your existing on-premise perpetual licences when you convert to cloud, but the credit is rarely dollar-for-dollar. Expect to receive 60-75% credit for a perpetual licence being converted to a 3-year cloud subscription.
What You CANNOT Modify
Transferring Licenses to Another Legal Entity
You cannot modify your SAP contract to transfer licences to a subsidiary, acquired company, or partner without SAP's explicit consent. SAP licences are tied to the named licensee (the company entity in the contract). If Company A owns SAP ERP and Company B (a subsidiary or newly acquired company) wants to use it, that's not a modification—that's a change-of-control or a new licensing arrangement requiring SAP approval.
This constraint creates friction in M&A scenarios. If you acquire a company with SAP systems, you cannot simply "modify" your contract to include the acquired systems. SAP treats it as a separate licensing matter, often triggering an audit and rebase.
Sublicensing to Third Parties
You cannot modify your agreement to sublicense SAP to third parties (customers, vendors, service providers) unless explicitly permitted in your contract. Most SAP agreements prohibit sublicensing except in tightly controlled circumstances (e.g., your service providers using SAP on your behalf). A modification cannot override this core restriction.
Extending Usage Rights Beyond the Licensed Scope
You cannot modify your contract to change the stated usage rights. If your agreement specifies that you can use SAP for "internal business operations," you cannot modify it to use SAP for "external data processing for customers" or other expanded use cases. Usage rights are contractually sacred; modifying them requires a new agreement or explicit written consent from SAP.
Modifications vs. Add-Ons: A Critical Distinction
SAP distinguishes between Modifications (changes to SAP's standard source code or metadata) and Add-Ons (new independent functionality built on SAP using APIs). This distinction affects licensing, cost, and maintenance.
A Modification is a custom alteration to SAP's standard product. For example, if you customize the standard procurement workflow to add a secondary approval step, that's a Modification. Modifications must be registered with SAP, and they create ongoing maintenance exposure. When SAP releases a new version or patch, your custom Modifications must be re-certified and potentially re-coded. Modifications are licensed per system and included in your annual support cost.
An Add-On is independent functionality that calls SAP's APIs rather than modifying SAP's core code. For example, if you build a analytics dashboard that pulls data from SAP via APIs, that's an Add-On. Add-Ons have more licensing flexibility and lower maintenance overhead. They're licensed separately and not subject to the same annual support requirements.
For budget and licensing purposes, Add-Ons are preferable because they don't inflate your SAP maintenance costs. However, licensing teams often conflate the two terms, so be explicit in negotiations: clarify whether your custom work is a Modification (higher cost, more SAP dependency) or an Add-On (lower cost, more independent).
RISE with SAP Discontinuation: April 2025 Game-Changer
In April 2025, SAP discontinued the RISE with SAP offering for new customers. RISE (Realize, Implement, Succeed with SAP) was an all-in-one cloud subscription launched in 2021, bundling S/4HANA, BTP (Business Technology Platform) credits, and implementation services. It was attractive because it simplified licensing: fixed monthly costs, no perpetual licences, and bundled implementation.
SAP replaced RISE with Cloud ERP Private, a new subscription model focused on private or hybrid cloud deployments. Existing RISE customers mid-contract were allowed to continue, but SAP offered a renegotiation path. Modifications to RISE contracts post-April 2025 now typically convert RISE customers to Cloud ERP Private terms.
What does this mean for your modifications? If you're on RISE and you want to add users, add BTP capacity, or extend your contract, expect SAP to push a conversion to Cloud ERP Private. This is not a simple modification—it's a material contract change that can affect pricing, support models, and implementation responsibilities.
Navigating SAP licensing modifications?
Our team has renegotiated 500+ SAP contracts and preserved discounts through complex modifications. Let's protect your position.Cloud ERP Private and Full-Use Equivalent (FUE) Metrics
Cloud ERP Private introduces a new licence metric: Full-Use Equivalent (FUE). Instead of licensing per named user or consumption metric, Cloud ERP Private clouds charge per FUE, which represents a usage tier or user grouping. The FUE model is simpler than legacy DDLC or named-user counting but creates confusion during modifications.
When modifying from RISE (which used RISE packs based on user count and BTP consumption) to Cloud ERP Private (which uses FUE), SAP must re-baseline your licence position. A typical RISE pack covered 100 users plus 1,000 hours of BTP compute. Converting to FUE might map to "3 FUE per month" or similar, but the mapping is not linear. Modifications in this scenario often trigger a rebase of your effective cost.
Best practice: if you're modifying a RISE contract or considering Cloud ERP Private, negotiate a fixed price cap for the duration of the modification. SAP will resist, but a "not to exceed" clause prevents surprise rebases.
S/4HANA Migration Resets the Baseline (and Modifications Can't Prevent It)
Many enterprises are migrating from legacy SAP ECC to S/4HANA. Modification language cannot protect you from a rebase during S/4HANA migration. SAP treats S/4HANA migration as a new licensing event, not a modification of your existing ECC licence.
Here's why: ECC and S/4HANA use different architectural foundations. ECC uses traditional database models; S/4HANA uses SAP's HANA in-memory database. SAP argues that migrating to S/4HANA is equivalent to buying a new system, even if it's the same data and the same named users. During migration, SAP audits your actual usage, counts your real users (not theoretical counts), and rebases your licence position.
If you're on ECC with 500 licensed named users but only 350 are actively used, S/4HANA migration might increase your baseline to 400 users because SAP's S/4HANA auditing tools detect all configured users, not just active ones. Protecting yourself requires contractual language before you migrate: a "use of same systems" clause that says your S/4HANA licence baseline cannot exceed your pre-migration ECC baseline by more than 5-10%.
Three Practical Modification Scenarios and How to Negotiate Each
Scenario 1: Reducing User Counts at Renewal
You're mid-contract with 500 named users. An organizational restructuring reduces your SAP user base to 400. You want to modify your agreement to reduce your licence count and lower your support costs. This is straightforward:
- Provide SAP with a current user entitlement report showing actual usage at 400 users.
- Request a modification to reduce named users from 500 to 400.
- Calculate your annual savings: 100 users × $200 list × 22% support rate = $4,400/year.
- Negotiate a credit for the "over-licensed" period (the time you've been paying for 500 users when you only needed 400). This is often a tough negotiation, but it's reasonable if you can prove under-utilization.
SAP will resist giving credit retroactively, but will offer to reduce future costs. The modification is clean if you present clean data.
Scenario 2: Converting from Named User to Digital Access (DDLC)
You're on a named user licence model with 500 users. Your business processes have evolved: many users now access SAP indirectly (via portals, reports, third-party integrations). You're concerned about indirect access exposure and want to convert to a digital access / DDLC model to have predictability.
This modification is complex but increasingly common. DDLC measures documents processed (invoices, POs, shipments) rather than user seats. SAP will:
- Audit your historical document processing volumes for the past 12 months.
- Calculate an implied DDLC baseline (e.g., if you process 500,000 documents/month, that maps to a specific DDLC tier).
- Offer a DDLC licence tier that covers that volume, plus 10-15% buffer.
- Price it as a modification using your current discount (hopefully).
DDLC conversions often result in a small savings (5-10%) compared to named user pricing, but the real value is predictability: you know your indirect access exposure is contractually capped.
Scenario 3: Adding BTP Capacity Mid-Contract
You're on Cloud ERP Private and you need additional BTP (Business Technology Platform) capacity. You initially subscribed for 1,000 hours/month of compute credits. You now need 1,500 hours/month. This is a straightforward modification:
- Request an additional 500 hours/month of BTP compute via modification.
- SAP charges the monthly incremental cost for 500 additional hours (typically $0.05-0.10 per hour, depending on your tier).
- The modification is bundled into your next invoice, with no other changes to your licence position.
This is one of the cleanest modifications because BTP is consumption-based, making the incremental cost transparent and uncontroversial.
Get our SAP modification negotiation playbook
Framework for protecting discounts, avoiding rebases, and structuring modifications to preserve your licence economics.ECC End-of-Mainstream-Maintenance (2027): A Modification Deadline
SAP's ECC (Enterprise Core Components) reaches end-of-mainstream-maintenance in December 2027. After that date, SAP no longer provides standard bug fixes and security patches. Customers can purchase extended support (at escalating costs), but the clock is ticking for ECC investments.
If you're on ECC and you want to continue on SAP's roadmap, you need to plan an S/4HANA migration or move to Cloud ERP. Modifications to your ECC licence (adding users, modules) become strategic decisions: are you investing in ECC knowing its end-of-life is approaching, or are you buying time until S/4HANA is ready?
Best practice: use the 2027 deadline as a negotiation point. If you're adding significant ECC capacity in 2026, push for a modification clause that guarantees your S/4HANA conversion (when you're ready) will not trigger a rebase or higher pricing. This protects you from SAP's "end-of-life pressure" to migrate immediately.
Key Takeaways
Licensing modifications allow you to reshape your SAP position without renegotiating from scratch. You can add/remove users, add modules, and change deployment models. You cannot transfer licences, sublicense, or expand usage rights via modification. RISE discontinuation and Cloud ERP Private changes the modification landscape, requiring careful negotiation of FUE-based terms. S/4HANA migration resets baselines regardless of modification language, so protect yourself contractually upfront. And three common modifications—user count reductions, digital access conversions, and BTP additions—have distinct negotiation strategies that preserve your leverage.
With over 500 engagements and 20+ years of SAP licensing expertise, Redress Compliance has guided enterprises through complex modifications that preserved discounts, avoided rebases, and protected licensing economics. If you're planning a modification, our team can help you structure it to maximize your negotiating position and minimize future exposure.