The Double-Payment Problem Defined
When an organisation transitions from on-premise SAP ECC to RISE with SAP or S/4HANA Cloud, there is an unavoidable period during which both systems must operate simultaneously. Data migration, user acceptance testing, cutover planning, and operational contingency all require the old system to remain live while the new one is being stood up and validated. The question is not whether you will run both systems — you will — but whether you will pay twice for that privilege.
Double payment in SAP transitions takes five distinct forms, each with a different root cause and a different contractual remedy. The organisations that avoid paying twice are those that identify all five forms before negotiation begins and negotiate explicit contractual protections for each. The organisations that pay twice are those that focus only on the headline subscription price and assume everything else will be sorted out operationally.
The fact SAP would prefer buyers to overlook: SAP's standard contract templates do not include dual-use rights, maintenance credit offsets, or BTP overlap protections as default provisions. These must be explicitly requested and negotiated. Every clause that prevents double payment must be added by the buyer — SAP will not volunteer it.
Double-Payment Trap 1: Maintenance Fees During the Cloud Transition
If you have paid annual maintenance fees for your on-premise SAP environment and you begin a RISE with SAP transition mid-maintenance cycle, you are paying for on-premise support you will not fully consume while simultaneously starting cloud subscription fees. For a large ECC environment with €2 million in annual maintenance, a migration that begins six months into the maintenance year means €1 million in prepaid maintenance fees that are — absent a specific contractual remedy — simply lost.
The negotiation: require SAP to apply the remaining value of prepaid on-premise maintenance fees against your RISE subscription fee as a credit. SAP can accommodate this by reducing the first-year cloud invoice by the proportional remaining maintenance value, or by extending your RISE subscription term by the equivalent period. This is a commercially reasonable request — you are not asking SAP to waive fees, you are asking SAP not to charge you twice for the same service period. SAP typically accommodates this when the request is made explicitly during contract negotiation; buyers who raise it post-signature receive significantly less favourable treatment.
Double-Payment Trap 2: Parallel Run Licence Costs (Dual-Use)
Running your existing ECC environment in parallel with S/4HANA — for data migration, user training, and contingency — creates a period where both systems are active and technically licensable. Without dual-use rights explicitly negotiated into your contract, SAP's position is that you require separate licence entitlements for both environments. For a large ECC deployment, this can represent an additional €1 to €3 million in avoidable costs over an 18-month parallel run period.
Dual-use rights contractually permit you to run both the legacy on-premise environment and the new cloud environment simultaneously without incurring double licence fees. SAP typically grants dual-use rights for 12 to 18 months when explicitly requested during the initial RISE negotiation. The window is usually sufficient for a well-planned migration — but must match your actual cutover plan, not SAP's optimistic go-live timeline.
The key contractual requirement: the dual-use provision must specify which specific SAP systems are covered (the named ECC system IDs), the duration of the dual-use period, and what happens if migration delays require an extension. An open-ended dual-use provision is better than a fixed-term one if your migration timeline carries execution risk.
A Client Pattern: The Dual-Use Oversight
A European retail group with 2,800 SAP users signed a RISE agreement in 2023. The deal was negotiated quickly, with strong focus on the per-user subscription rate and migration credits. Dual-use rights were not discussed — the assumption was that SAP would not charge separately for the ECC environment during the transition. SAP's position, raised six months after signature when the parallel run was well underway, was that the legacy system required a separate "Customer-Specific Maintenance" arrangement at €450,000 per year.
A 14-month parallel run — driven by the complexity of the retail merchandise management integration — cost the company €525,000 in maintenance fees that should have been zero under a properly negotiated dual-use provision. The lesson is not that SAP is unreasonable — this is standard contract behaviour. The lesson is that what is not explicitly negotiated into an SAP contract does not exist.
Need help structuring your SAP cloud transition to avoid double payment?
Our SAP commercial advisory specialists have managed hundreds of cloud transition negotiations.Double-Payment Trap 3: BTP Overlap with On-Premise Licences
SAP's Clean Core strategy — the architectural mandate that customisations and extensions move from the S/4HANA core to SAP BTP — creates a specific double-payment risk for organisations with existing on-premise SAP engines. If you have licensed SAP Process Integration (PI/PO), SAP NetWeaver BPM, or other middleware and integration platforms as part of your on-premise SAP environment, and you begin running equivalent BTP services during the cloud transition, you may be paying for the same functional capability twice: once through your on-premise licence and once through BTP credit consumption.
The resolution requires an architecture review before go-live that maps every on-premise capability against its BTP equivalent and identifies which on-premise entitlements can be retired (and when) as BTP services take over. For each overlap period, the contract should specify that BTP consumption covering capabilities already licensed on-premise is either included in the subscription fee or offset against the on-premise maintenance cost being retired.
This is the double-payment trap that is hardest to identify without technical expertise, because it requires understanding both the licensing implications of on-premise SAP middleware products and the consumption model of BTP services. Buyers who engage systems integrators without independent commercial advisory support frequently miss this overlap entirely.
Double-Payment Trap 4: Extended Maintenance Alongside Cloud Subscription
For EHP 6–8 customers who will not complete migration before December 31, 2027, SAP's extended maintenance option (available through December 31, 2030) costs approximately 24% of licence value annually — versus the standard 22% for mainstream maintenance. The 2-percentage-point uplift represents a meaningful additional cost for a large ECC estate.
The double-payment risk arises when organisations pay extended maintenance on the full on-premise estate while also paying RISE subscription fees for a partial cloud deployment. If the migration is phased — with some business units on RISE and others still on ECC — there is a period where full on-premise maintenance plus full RISE subscription are running simultaneously for overlapping functional scope.
The contract negotiation should address phased migration explicitly: maintenance costs for the on-premise estate should be reduced proportionally as user volumes migrate to RISE, rather than remaining static at the original maintenance base. SAP typically resists this unless pushed — the default position is that maintenance fees apply to the full on-premise estate regardless of how many users have migrated to cloud.
Double-Payment Trap 5: DDLC Charges on Integrations Already Covered On-Premise
The most technically complex double-payment trap involves Digital Access. Some on-premise SAP licence agreements include provisions — compatibility rights, specific indirect access terms, or explicit DDLC entitlements — that cover certain external system integrations. When an organisation migrates to RISE, these on-premise provisions do not automatically carry forward. SAP's RISE contract template starts fresh on digital access, meaning integrations that were covered under on-premise terms now require new DDLC entitlements under the cloud contract.
The result is that organisations can end up paying twice for the same integration — once through the historical on-premise terms (via maintenance fees that include any embedded indirect access rights) and again through new DDLC charges in the RISE contract. Avoiding this trap requires reviewing your existing on-premise agreement's indirect access provisions before negotiating the RISE contract, and explicitly requesting that covered integration scenarios be grandfathered into the RISE DDLC terms without additional charge.
Six Protective Provisions to Negotiate
1. Maintenance Credit Offset Clause. Insert a provision requiring SAP to apply the pro-rated value of any prepaid on-premise maintenance fees against the first-year RISE subscription fee, or equivalently extend the RISE subscription term, when the RISE start date falls within a paid maintenance period. Specify the calculation methodology and the payment mechanics clearly.
2. Dual-Use Rights for 18 Months. Include explicit dual-use rights covering the named ECC systems, the duration (minimum 18 months, with an extension mechanism if migration is delayed), and a clear statement that running both environments during the dual-use period does not constitute additional licence exposure or require additional maintenance fees.
3. BTP Overlap Assessment and Credit. Require SAP to document which BTP services replace which on-premise licensed capabilities, and negotiate a credit or fee offset for any period where equivalent functionality is being paid for twice — once on-premise and once via BTP consumption.
4. Phased Migration Maintenance Reduction. For phased migrations, negotiate a provision that reduces on-premise maintenance fees proportionally as user volumes migrate to RISE, rather than maintaining the full on-premise maintenance base throughout the transition period.
5. DDLC Grandfathering for Existing Integrations. Require SAP to confirm in writing which indirect access or digital access provisions from the existing on-premise agreement carry forward into the RISE contract, and for any that do not, negotiate DDLC coverage as part of the RISE deal rather than leaving them as future exposure.
6. Migration Credit Maximum Extraction. Migration credits decrease approximately 10% per year approaching the 2027 EHP 6–8 deadline. Negotiate the maximum credit entitlement for your migration timeline — credits applied against subscription fees, BTP allocations, or implementation services all reduce the effective double-payment burden of the transition period.
SAP Commercial Advisory Intelligence
Quarterly updates on SAP cloud transition economics, credit structures, and contract protections from our SAP commercial advisory specialists.