What is the SAP Transition Option and what does it cost?

The Transition Option extends on-premise operations through end of 2033. It comes with a 20 percent surcharge over the comparable cloud price and requires a Max Success Plan.

How are on-premise licenses credited against Cloud ERP?

Existing maintenance investments can be credited against the Cloud ERP ACV. Three credit types apply with negotiation-dependent amounts and defined time windows.

On-Premise Migration and SAP Transition Option: Managing the BS7 Maintenance End Strategically

Mainstream Maintenance for SAP ERP 6.0 EhP 6-8 ends on December 31, 2027. Starting January 1, 2028, Extended Maintenance begins with a surcharge of two percentage points on the Maintenance Base. Organizations that have moved to RISE (PCE) by that date do not bear this surcharge. The Transition Option extends on-premise operations through end of 2033, but at a 20 percent premium over the comparable cloud price and requires a Max Success Plan. Between these options lie significant differences in contract mechanics, license crediting, and negotiating position. Organizations that evaluate these options in a structured way now retain room to maneuver.

Maintenance Timeline: What End of 2027 Means
Three Scenarios from 2028: On-Prem, Cloud, Hybrid
Extended Maintenance: Mechanics and Costs
Transition Option: Mechanics, Deadlines, Surcharge
The Nine SAP Product Types: On-Prem vs. Cloud
License Crediting: On-Prem Credits Against RISE ACV
Dual-Use Period: Governance During Migration
Add-on Product Versions in the Transition Option
Monetizing Shelfware Instead of Letting It Lapse
Four Governance Moments in the Migration Phase
Contract Governance After Signing: What Starts Now
FAQ
Next Steps

Maintenance Timeline: What End of 2027 Means {#maintenance-timeline}

Three dates define the decision space for on-premise operators: end of 2027, January 1, 2028, and December 31, 2030. Organizations that know these milestones can evaluate options on the merits. Those that don't are making decisions on an incomplete information base.

The end of Mainstream Maintenance for SAP ERP 6.0 EhP 6-8 is not new news, but it enters the immediate planning horizon in 2026 and 2027. Lead times for a well-founded decision, whether cloud migration, Extended Maintenance, or Transition Option, run 12 to 24 months. That means: organizations that haven't made a decision by end of 2026 are losing room to act.

What Mainstream Maintenance Covers and What Ends

Mainstream Maintenance includes Legal Changes (statutory requirements such as tax and regulatory updates), Support Packages, error correction, and Problem Resolution. Through end of 2027, SAP ERP 6.0 EhP 6-8 systems receive this full scope of service without surcharge.

When Mainstream Maintenance ends, there is no immediate system shutdown. The software continues to run. What ends is active further development and regular statutory upkeep. In regulated industries this is a relevant point: tax changes, reporting obligations, and compliance requirements will no longer be applied automatically under standard maintenance after 2027.

Which EhP Versions Are Affected

Not all EhP versions run through end of 2027. EhP 0-5 reached the end of Mainstream Maintenance at end of 2025. These systems have been in Customer Specific Maintenance (CSM) mode since January 1, 2026, which requires separate arrangements.

EhP 6, 7, and 8 run under Mainstream Maintenance through December 31, 2027. This is the group for which Extended Maintenance and the Transition Option are the structured extension paths.

Solution Manager 7.2 Follows the BS7 Strategy

Solution Manager 7.2 is tightly coupled to the BS7 maintenance strategy. Mainstream Maintenance also ends at end of 2027. Extended Maintenance for SolMan 7.2 is automatically included in BS7 Extended Maintenance and runs through end of 2030. There will be no new SolMan release after 7.2. The successor for ALM requirements is SAP Cloud ALM, which is included in the RISE package.

NetWeaver BW: Embedded vs. Standalone

For NetWeaver BW, a distinction must be drawn between embedded and standalone BW. Embedded BW, operated as part of the BS7 system, follows the BS7 cycle. Standalone BW has its own maintenance cycle, documented in SAP Note 2741041, which differs from the BS7 timeline.

Compatibility Scope Use Rights: Four Constellations

Compatibility Items, meaning functional areas that are no longer part of standard S/4HANA functionality, are subject to their own deadlines. Four constellations are relevant:

Use under cloud subscription: Extended use rights through 2030
On-prem S/4HANA with cloud contract (at least 50 percent of Maintenance Base converted, or ACV at least 50 percent of Maintenance Base): Extended through 2030
On-prem S/4HANA with separately licensed cloud solution: Extended for the specific item
All other cases: End of Compatibility use rights at end of 2025

The relevant SAP Note for the Compatibility Scope Matrix is SAP Note 2269324.

Key Dates at a Glance

Date	Event
End of 2025	End of Compatibility Scope for non-qualifying on-prem S/4HANA systems
Dec 31, 2027	End of Mainstream Maintenance for SAP ERP 6.0 EhP 6-8 and SolMan 7.2
Jan 1, 2028	Start of Extended Maintenance (+2 percentage points on-prem); RISE/PCE condition
Dec 31, 2030	End of Extended Maintenance, SolMan Extended, Compatibility Scope Cloud
2031-2033	Transition Option (20 percent surcharge, Max Success Plan required)

Three Scenarios from 2028 {#three-scenarios-from-2028}

From January 1, 2028, on-premise operators have three clearly distinct paths. Each path has its own contract mechanics, its own budget profile, and its own governance moments. A decision without contract analysis is not sound in any of the three scenarios.

Scenario 1: Full Landscape on RISE (SAP ERP Private Cloud Edition)

Organizations that have moved their entire system landscape to SAP ERP Private Cloud Edition (PCE) by January 1, 2028, bear no Extended Maintenance surcharge. Extended Maintenance is included in the subscription price of the RISE contract. This is the structurally simplest solution, but it requires all systems to be running in PCE by that cutover date.

"All systems" is meant literally: leaving individual systems outside PCE and requesting Extended Maintenance for those is technically possible, but it creates a parallel structure of two different contract regimes. For governance moments around usage, authorizations, infrastructure, and costs, that means significantly higher coordination overhead.

Scenario 2: Fully On-Premise (BS7 Extended Maintenance)

Organizations that remain on-premise require an Extended Maintenance addendum to their existing maintenance contract from January 1, 2028. The basis for the surcharge is the Maintenance Base of all BS7 Core Applications, add-ons, and runtime databases. The surcharge is two percentage points on this base.

Important for planning: Extended Maintenance is not selective. When you apply for Extended Maintenance, you apply for it across the entire landscape. Excluding individual systems is not possible. This all-or-nothing rule is one of the most common misconceptions in planning.

Scenarios 3 and 4: S/4HANA Contract Conversion and Product Conversion

Two further paths allow optimization of the Maintenance Base by deliberately surrendering no-longer-needed use rights:

In S/4HANA Contract Conversion, classic ERP term licenses that are still productive are converted. Use rights that are no longer needed can be surrendered, which reduces the Maintenance Base. The Extended Maintenance surcharge of two percent is then calculated on the reduced base.

In S/4HANA Product Conversion, cumulative licenses minus already-converted SKUs form the calculation base. The remaining lowest discounted SKUs form the basis. Here too: two percent on the reduced base.

What All-or-Nothing Means for Extended Maintenance

The all-or-nothing rule is a structurally relevant governance point. It means: any organization that has even one on-premise system running BS7 and wants to apply for Extended Maintenance must do so for the entire BS7 landscape. Cherry-picking by system is not possible.

The practical consequence: organizations with a phased cloud migration plan, first one plant, then the next, bear the full Extended Maintenance surcharge on the entire base for the systems remaining on-prem, not only on the systems not yet migrated.

The governance moment in the cost dimension here lies in knowing the precise composition of the Maintenance Base before the cutover date. Organizations that don't know what line items make up their Maintenance Base can neither reliably calculate the cost of Extended Maintenance nor systematically exploit optimization potential through license surrender.

Extended Maintenance: Mechanics and Costs {#extended-maintenance-mechanics-and-costs}

Extended Maintenance is not an automatic next step after end of 2027. It is a paid addendum with clear conditions, a defined scope, and a fixed end date.

Period and Termination Notice

Extended Maintenance runs from January 1, 2028, to December 31, 2030. The addendum can be terminated with 90 days' notice to year-end. On December 31, 2030, Extended Maintenance ends automatically, regardless of whether an organization has migrated by that point.

After 2030, there is no structured SAP maintenance for on-premise BS7 systems. The exception is the Transition Option, but that represents its own contract regime and is not designed as an extension of Extended Maintenance.

Pricing Structure: What Belongs to the Maintenance Base

The Extended Maintenance surcharge is two percentage points on the Maintenance Base. The Maintenance Base covers all BS7 Core Applications, all add-ons, and the runtime database.

A concrete example: an organization with 22 percent Enterprise Support and a Maintenance Base of EUR 1,000,000 pays 24 percent on that base from 2028, meaning EUR 240,000 per year instead of EUR 220,000 previously. That is an additional EUR 20,000 per year, or EUR 60,000 over the three years of Extended Maintenance.

Scope: What Extended Maintenance Delivers and What It Doesn't

The scope of Extended Maintenance matches that of Mainstream Maintenance: Legal Changes, Support Packages, and Problem Resolution. What Extended Maintenance does not deliver: no new features, no innovation access, no access to AI capabilities, no path toward cloud. It is a continuation of the status quo without further development.

This is not a criticism of Extended Maintenance as an option, but a description of the service scope that is relevant for evaluation. Organizations that face innovation pressure or regulatory obligations requiring new functionality need a different path.

Optimization Potential: Reducing the Maintenance Base Through License Surrender

One of the most significant governance moments in the cost dimension before Extended Maintenance begins lies in reducing the Maintenance Base. By deliberately surrendering no-longer-needed use rights, the base can be substantially reduced.

An abstract example shows the optimization potential:

Maintenance Base before optimization:         EUR 1,000,000
- Unneeded products (e.g., BO):              -EUR   200,000
- ECC Engines (covered in S/4HANA):          -EUR   500,000
- User reduction (3,000 to 300 BW users):    -EUR   270,000
Remaining Maintenance Base:                   EUR    30,000
Extended Maintenance (2%):                    EUR       600/year

This calculation shows: the difference between an unoptimized and an optimized Maintenance Base can reduce the Extended Maintenance surcharge from a substantial amount to a marginal one. The prerequisite is a careful inventory of use rights that are actually in use.

What Extended Maintenance Does Not Deliver

For completeness: Extended Maintenance provides no access path to SAP Business AI, no Joule access, no new BTP entitlements, and no preparation for S/4HANA migration beyond standard support. Organizations that choose Extended Maintenance are running a platform that has not developed substantially since 2016. This assessment is relevant for strategic positioning and for the CFO conversation.

Transition Option: Mechanics, Deadlines, Surcharge {#transition-option-mechanics-deadlines-surcharge}

The Transition Option is the last structured extension path for organizations whose IT landscape needs more time for a complete cloud migration. It extends on-premise operations beyond the end of Extended Maintenance through end of 2033, but on different terms.

What the Transition Option Is

Formally, the Transition Option is SAP ERP Private Edition operated in the cloud, designed for customers on EhP 7 or EhP 8. Systems are hosted in a SAP-managed cloud environment (Private Cloud Edition) but retain the ECC 6.0 architecture at their core. The Transition Option is not a permanent operating state and is not a substitute for S/4HANA migration.

Subscription Window and Service Start

The subscription window for the Transition Option is 2028 to 2030. This means: organizations that want to use the Transition Option must sign the contract between early 2028 and end of 2030. Service start is no earlier than January 1, 2031; maximum duration runs to December 31, 2033.

This deadline chain is relevant for decision-makers because it defines a clear decision calendar. Organizations that have not signed a Transition Option contract by end of 2030 no longer have this path available.

Price Surcharge: 20 Percent Over the Comparable Cloud Price

The price surcharge for the Transition Option is 20 percent above the comparable price of a regular SAP ERP Private Edition. Exception: organizations that subscribed to the Transition Option before end of 2025 do not bear this surcharge.

The 20 percent surcharge is calculated on the cloud price of the comparable Private Edition, not on the previous on-premise Maintenance Base. This is an important distinction for budget planning.

Minimum Requirements: 2 TB and Max Success Plan

Two minimum requirements apply to the Transition Option:

First, the 2 TB minimum size. Systems below this size are generally not eligible for the Transition Option.

Second, the Max Success Plan Transition Services. This plan is mandatory with the Transition Option and generates additional costs on top of the base price. The Max Success Plan includes extended support and advisory services from SAP, specifically oriented toward migration and transformation scenarios.

EhP Prerequisite: Only EhP 7 and EhP 8

The Transition Option supports only EhP 7 and EhP 8 for SAP ERP 6.0. Organizations on older EhP versions, meaning EhP 0 through 6, must first upgrade to at least EhP 7 before moving to the Transition Option. That is a separate project that must be factored into overall planning.

What the Transition Option Is Not

The Transition Option is not a permanent state. It is a time-limited bridge whose end on December 31, 2033, is fixed. Organizations using the Transition Option face the same migration decision by end of 2033 at the latest, only with less lead time. The Transition Option buys time; it does not resolve the strategic challenge.

Decision Timeline for Decision-Makers

A structured backward-planning view shows which decisions must be made when:

By end of 2026: Decision on the base scenario (cloud vs. on-prem) based on a current Maintenance Base analysis
By mid-2027: Conclude contract negotiations for Extended Maintenance or RISE migration
By end of 2027: Systems in PCE or Extended Maintenance addendum signed
2028-2030: Subscription window for the Transition Option open, if needed
Jan 1, 2031: Transition Option service start
Dec 31, 2033: End of Transition Option, no further structured SAP extension

The Nine SAP Product Types: On-Prem vs. Cloud {#the-nine-sap-product-types}

Discussion of the maintenance end and migration frequently focuses on SAP ERP. The governance moment in the infrastructure dimension shows, however, that on-premise is not just ERP. When you migrate, you migrate a portfolio of multiple product types with different maintenance cycles, different cloud counterparts, and different contract regimes.

On-Premise Core Products and Their Specific Maintenance Cycles

The core products in the on-prem portfolio directly affected by the BS7 maintenance timeline include SAP ERP (EhP 6-8, Mainstream through end of 2027), NetWeaver BW as an embedded system (follows BS7 cycle), and Solution Manager 7.2 (Mainstream through end of 2027, Extended through end of 2030).

Each of these products has its own maintenance mechanics and must be included separately in the migration strategy.

RISE as Migration Target: What's Included and What Stays Separate

RISE with SAP (SAP Cloud ERP Private Edition) bundles S/4HANA Cloud Private Edition, BTP base entitlements, and technical operations in a single contract. What is included in the RISE package depends on the tier selected.

Important for governance moments in the cost dimension: BTP entitlements are present in the RISE package at a base level. Whether this base level is sufficient for actual usage depends on planned extensions and use cases. Additional BTP capacity is procured separately.

Product Types with Their Own Contract Cycles

Not all SAP product types follow the RISE contract automatically. SuccessFactors, Ariba, and Concur have their own cloud subscriptions and are not automatically included in a RISE migration. When you migrate, you migrate the ERP core system, not your entire SAP software landscape in a single step.

This matters for the governance moment in the cost dimension: after a RISE migration, multiple separate contract regimes can coexist, with different renewal dates, different ACV profiles, and different governance requirements. Consolidated governance across all SAP contracts becomes more important after migration, not less.

BTP Entitlements in the RISE Package

BTP entitlements are included in the RISE package, but their actual value depends on the edition and usage intensity. Organizations that want to use BTP for integrations, extensions, or AI workloads should verify before signing whether the included entitlements cover planned requirements. Missing entitlements must be renegotiated or procured separately.

The governance moment in the infrastructure dimension with respect to the BTP portfolio lies in knowing the actual utilization of included entitlements. RISE contracts frequently include BTP services that are licensed but not activated or used. These unused entitlements represent lost value that can be identified in regular reviews and either activated or used as a lever in contract negotiations.

At the same time: BTP capacity beyond the included base level generates additional cost. Organizations that only concretize planned BTP use cases after contract signing frequently discover that the base level is insufficient. An early BTP requirements analysis is therefore part of proper RISE contract preparation.

License Crediting: On-Prem Credits Against RISE ACV {#license-crediting}

Existing SAP ERP and on-prem S/4HANA customers can apply credits toward a RISE contract through the Cloud Extension Program. This is one of the most significant governance moments in the cost dimension during a migration: the level of applicable credits depends on negotiation and is time-sensitive.

Three Credit Types

SAP makes three types of credits available:

Maintenance Credits are offset against future on-prem maintenance invoices. They are relevant for organizations that plan to move to RISE but still have ongoing maintenance payments.

Service Credits are offset against services SKUs, for example, against implementation or consulting services from SAP.

Cloud Credits are applied directly against cloud contract invoices, that is, against the ACV of a RISE contract.

Eligibility: Who Can Apply Credits

Eligibility for credit application belongs to SAP ERP and on-prem S/4HANA customers moving to RISE or GROW through the Cloud Extension Program. Eligibility is tied to the program and is not automatic.

In practice, this means: organizations that want to use credits must actively bring the Cloud Extension Program into the contract negotiation. Credits do not arise automatically and are not communicated automatically. This is a concrete governance moment in the cost dimension that structured negotiation preparation addresses.

How Credits Are Applied Against ACV

The offset is executed through the Order Form of the RISE contract. Maintenance Credits can be applied as a lump sum against the ACV of the first contract year or spread over multiple years, depending on the negotiation outcome.

Important: the amount of applicable credits is not publicly tabulated. It depends on negotiation and is influenced by the Maintenance Base level, the RISE ACV volume, and the timing of the negotiation.

Why Early Engagement Strengthens Your Negotiating Position

The earlier an organization enters negotiations, the more room exists on both sides. SAP has an interest in moving customers to the cloud early. That interest is strongest when the maintenance end is still 18 to 24 months away. Organizations that negotiate 6 months before end of 2027 are negotiating with significantly fewer options and significantly more time pressure.

What Is Not Automatically Credited

Add-ons, Application Management Services (AMS) contracts, and third-party maintenance contracts are not automatically included in the credit calculation. Organizations that want to apply add-on credits must negotiate this explicitly and provide documentation.

Shelfware, meaning paid but unused licenses, is also not automatically considered as a credit. Shelfware is a separate negotiating argument, covered in section 9.

Governance Moment: Anchoring Credits in the Contract

The governance moment in the cost dimension here lies in anchoring the credit offset in the contract. Verbal commitments are not part of the contract. What is in the Order Form applies. What is not in the Order Form does not exist contractually.

For the four roles involved in this decision, this means concretely:

The Contract Manager is responsible for verifying that agreed credits are correctly reflected in the Order Form and for the timing of the offset.

Procurement is responsible for negotiating the credit terms and documenting the negotiation basis, which can be referenced in later renewal negotiations.

Controlling is responsible for budget planning that accounts for the credit offset, so that no double burden arises from ongoing maintenance and full ACV.

Executive carries the decision of whether the timing of migration aligns with the available credit volume and the strategic budget situation, or whether a delay would improve the negotiating position.

These role perspectives show: the credit negotiation is not a technical detail but a central governance moment that requires coordination between contract management, procurement, controlling, and executive leadership.

Dual-Use Period: Governance During Migration {#dual-use-period-governance-during-migration}

During the migration phase, the on-premise system and the cloud system run in parallel. This period, typically six to 18 months, has its own contract mechanics and generates governance requirements that neither the on-prem contract nor the RISE contract alone automatically covers.

What the Dual-Use Period Means

Dual-Use describes the contractually governed period in which on-prem and cloud systems are operated productively at the same time. SAP allows this parallel operation for a defined transition period because data migration, user training, and cutover typically cannot be completed on a single date.

The length of the dual-use period must be established contractually. In practice, six to 18 months is the typical range, depending on migration scope, system complexity, and organizational structure.

What SAP Permits Contractually and What It Does Not

The use rights during the dual-use period must be governed in the RISE contract. SAP permits parallel operation on the condition that users do not work productively in both systems simultaneously, but rather that one of the systems serves as the migration environment.

What SAP does not permit: double productive use of the same user in both systems without corresponding licensing. Organizations that don't draw this boundary cleanly in the contract risk a back-billing demand in the next measurement.

How FUE Licensing Works During the Dual-Use Period

FUE licensing (Full Use Equivalent) is the central governance moment in the usage dimension during the dual-use phase. FUEs normalize different user types to a unified comparison unit:

Developer Access: 1 user equals 2 FUE
Advanced User: 1 user equals 1 FUE
Core User: 5 users equal 1 FUE
Self-Service User: 30 users equal 1 FUE

When users are provisioned in both systems during the dual-use phase but are only active in one, the contractual definition of "active user" determines the license obligation. This definition should be agreed in writing before the dual-use phase begins.

Billing and Maintenance Demarcation

When does the on-prem maintenance obligation end, and when does the full RISE ACV obligation begin? This demarcation is frequently not clearly governed during the dual-use phase. In practice, organizations often pay both maintenance and ACV for part of the dual-use phase because the contractual demarcation points are not precisely defined.

The governance moment in the cost dimension lies in the precise definition of the cutover date in the Order Form: from which date does the on-prem maintenance obligation cease, and from which date does the full ACV begin?

Typical Governance Gaps in Parallel Operations

During the dual-use phase, governance gaps arise from the distribution of users across two systems:

In the usage dimension: which users are active on which system, and how are FUE assignments handled between on-prem and cloud?

In the authorizations dimension: which roles are set up from scratch in the new system, and which are migrated? Role design directly affects FUE costs in the cloud system.

In the infrastructure dimension: which SLA applies during the dual-use phase, and who is responsible for incidents on which system?

In the cost dimension: which billing demarcations apply, and who monitors compliance with those demarcations?

These four governance moments in the dual-use phase are the central governance objects of a structured migration accompaniment program.

Add-on Product Versions in the Transition Option {#add-on-product-versions}

Not all add-ons are available in the Transition Option. Organizations that operate add-ons in their current ECC system must verify, before the Transition Option decision, which add-ons can be carried over and which require an S/4HANA equivalent or a separate replacement.

Which Add-on Categories Are Supported

The Transition Option supports only EhP 7 and EhP 8 for SAP ERP 6.0. Older EhPs must be upgraded to at least EhP 7 before migration. The following add-on categories are available in the Transition Option:

Supply Chain and Logistics: APO 7.0 EhP4 on ERP 6.0 EhP8 (as connector only, not standalone), EWM 9.5, DMC 6.0.

Finance and Treasury: SAP Revenue Accounting 1.3 (IFRS 15), SAP Treasury and Risk Management (US version), SAP CPM 2.0, Financial Task List Management Integration.

HCM and HR: HR Renewal 2.0, SAP Fiori for HCM 2.0, SuccessFactors Employee Central Integration (SFSF EC Integration), Manager Self-Service Add-on, Mobile Add-on for ERP.

Compliance and Invoicing: GINVOICING 2.0 for global electronic invoicing, SAP Document Builder Management.

Integration and Platform: SAP Cloud for Customer Integration, SAP CPQ ERP Integration, PLM System Integration, and payment connector add-ons.

Industry-Specific and Localization: Utilities-specific add-ons for the CEE region and additional localizations.

What Is Not Included in the Transition Option

Not all add-ons appear on the Transition Option list. Older EhP versions are categorically excluded. Add-ons without an S/4HANA equivalent that are not listed in the Transition Option catalog cannot be carried over and must be replaced separately.

The S/4HANA Compatibility Pack for add-ons applies at most through December 31, 2030, for cloud subscriptions. Organizations running add-ons on the basis of the Compatibility Pack must migrate them to S/4HANA-native solutions by end of 2030.

Sizing Implications: Add-ons and ACV

Every activated add-on affects infrastructure sizing and therefore the ACV of the RISE contract. Add-ons such as APO, EWM, or CRM integrations increase system complexity and therefore sizing requirements.

The governance moment in the infrastructure dimension here: sizing must be precisely aligned with the actual add-on inventory before contract signing. Sizing that is too conservative leads to capacity bottlenecks; sizing that is too generous creates overcapacity that unnecessarily increases the ACV.

Add-ons Without S/4HANA Equivalent: Early Identification

One of the most important governance tasks before the Transition Option decision is identifying all add-ons without a direct S/4HANA equivalent. These add-ons can still be operated in the Transition Option if they appear on the available list, but they must be migrated to alternative solutions by end of 2033 at the latest. Organizations that only carry out this identification during the Transition Option lose valuable planning time.

Monetizing Shelfware Instead of Letting It Lapse {#monetizing-shelfware}

In on-premise environments, licenses accumulate over the years that are paid for but not, or no longer fully, used. This shelfware is a strategic asset in a cloud migration, with a time window for realization.

What Shelfware Is and How It Arises

Shelfware consists of licenses for which maintenance is paid even though the use rights are not exercised. It arises through several typical mechanisms: corporate consolidations where licenses from acquisitions enter the portfolio but are never put into productive use. Functional reorganizations where modules are replaced but the license continues. User reductions where headcount falls but licensed capacity is not adjusted.

In mature SAP landscapes built up over ten or more years, shelfware is not an exceptional case. It is a structural result of the complexity of ERP contract portfolios.

Shelfware as a Negotiating Argument

Shelfware can be used as a negotiating argument when moving to RISE. The mechanism: unused licenses for which maintenance is being paid can be brought forward as an additional argument in the credit negotiation. SAP has an interest in customers moving to the cloud. Organizations that can document shelfware simultaneously demonstrate that part of their previous maintenance payments had no operational counterpart.

The prerequisite for this argument is a complete inventory: which licenses are in the portfolio, which are actually being used, and which are merely being maintained?

Reducing the Maintenance Base Through License Surrender

Shelfware can be used not only as a negotiating argument but also directly to reduce the Maintenance Base. Use rights that are no longer needed can be surrendered before Extended Maintenance begins. This reduces the base on which the Extended Maintenance surcharge is calculated.

The abstract calculation from section 3 (reduction from EUR 1,000,000 to EUR 30,000 Maintenance Base) illustrates this: the governance moment in the cost dimension before January 1, 2028, lies not only in choosing the scenario but also in cleaning up the base to which the scenario is applied.

Time Window: When Shelfware Realization Is Still Possible

The window for shelfware realization closes with the start of Extended Maintenance or the signing of a RISE contract. Organizations that identify shelfware only after contract signing can generally no longer bring it retroactively as a negotiating argument.

This means concretely: the inventory and shelfware analysis should fall within the preparation phase of the contract negotiation, not the phase after signing.

What Systematic Inventory Requires

A reliable shelfware analysis requires two data sources: the SAP Readiness Check, which provides technical usage data from the productive system, and your own license register, which documents the contractually licensed rights.

Organizations that combine both data sources can systematically identify which use rights are licensed but not used. This gap is the actionable finding.

Four Governance Moments in the Migration Phase {#four-governance-moments}

Migration does not change the fundamental structure of contract governance. It shifts the weights among the four dimensions in which governance moments arise: usage, authorizations, infrastructure, and cost. In the migration phase, all four dimensions are active simultaneously, because both the existing system and the new system generate governance requirements.

Usage: Tracking the FUE Shift

The governance moment in the usage dimension lies in the continuous monitoring of the FUE shift between on-prem users and cloud users. During migration, users gradually move from the on-prem system to the cloud system. Each shift changes the FUE distribution and therefore the licensing basis.

In practice, FUE assignments are not automatically adjusted during migration. Organizations that don't actively monitor the FUE distribution notice discrepancies only at the next measurement. This can lead to back-billing demands or to unused FUE quotas in the on-prem contract that continue to generate cost.

Authorizations: Role Design as a License Cost Factor

The governance moment in the authorizations dimension lies in role design during the transition from ECC to S/4HANA. Roles that were broadly defined in ECC can lead to a higher FUE type in S/4HANA if the breadth of the role requires an Advanced User license instead of a Core User license.

Concrete example: a user who had a reporting role with read access across multiple modules in ECC can be classified as an Advanced User in S/4HANA if the role design exceeds the threshold for Core User. Role design is therefore not just an IT architecture question but a cost factor.

The governance moment lies in reviewing role design before go-live: which license class results for each user type, and does this match the sizing assumptions in the RISE contract?

Infrastructure: SLA Alignment and Hyperscaler Choice

The governance moment in the infrastructure dimension has two aspects: first, the SLA alignment between the previous on-prem SLA and the RISE SLA; second, anchoring the hyperscaler choice in the contract.

On-prem systems typically have individually negotiated SLAs with the internal IT operations team. RISE SLAs are standardized but differ by hyperscaler and tier. A review of whether RISE SLA parameters cover previous operational requirements should be conducted before contract signing.

The hyperscaler choice, whether Azure, AWS, or Google Cloud, affects not only technical operations but also available complementary services and costs. Azure is the largest RISE partner, Google Cloud offers the strongest data and AI integration, AWS has the most mature SAP workload experience. This choice should be anchored in the contract to avoid later changes without a contract amendment.

Cost: ACV Tracking and Credit Application

The governance moment in the cost dimension during the migration phase covers three aspects:

First, ACV tracking during the ramp-up phase. RISE contracts frequently include a graduated ramp-up profile where the ACV is lower in the early years and then grows to the full level. Organizations that don't actively monitor the ramp-up profile notice deviations from the planned migration path only when the profile no longer fits.

Second, the application of Maintenance Credits against ACV. Credits agreed during negotiation must be actively tracked until they are correctly recorded in the Order Form.

Third, the Extended Maintenance position: organizations that pay Extended Maintenance for a transition period because migration is not yet complete must carry this position as a known budget item, not as a surprise on the next invoice.

Contract Governance After Signing: What Starts Now {#contract-governance-after-signing}

Migration is a project with a beginning and an end. Contract governance is an ongoing discipline that does not begin and end with the migration project, but starts with the RISE contract signing and runs across the entire contract term.

What Becomes an Ongoing Governance Task After Migration

After go-live on RISE, new ongoing governance tasks arise that are frequently not yet in focus during the migration project:

In the usage dimension: BTP credit consumption, FUE development with growing user populations, overage monitoring for AI unit quotas.

In the authorizations dimension: role maintenance under the FUE model, license class review during role changes, PCE metering evaluation.

In the infrastructure dimension: SLA monitoring to RISE standard, system sizing review with growing workloads, hyperscaler operational data.

In the cost dimension: ACV tracking, derived charges reconciliation, renewal preparation.

How FinOptory Structures the Post-Migration Phase

FinOptory structures ongoing governance along three dimensions:

Assets describes what is in the contract: entitlements, ACV, clauses, deadlines, renewal dates.

Change describes what is shifting: usage changes, SAP updates, role adjustments, new add-ons, new modules.

Control describes ongoing governance: 14-day reviews, reconciliation of actual vs. contractual, proactive communication ahead of governance moments.

Who Governs SAP Contracts After Signing

The challenge lies in the system, not the organization. Governing SAP contracts after signing requires a systematic approach that neither the migration project team nor ongoing IT operations builds alone. Migration projects end with go-live. IT operations focuses on system availability. Contract governance is its own discipline, combining specialized knowledge of contract mechanics, SAP product types, and negotiation logic.

Why Migration and Ongoing Governance Need the Same Data Foundation

A point that frequently becomes visible too late in practice: migration projects build valuable knowledge about the existing contract structure. Sizing assumptions, add-on analyses, credit negotiations, SLA comparisons. This knowledge should not disappear into documents with project close-out but should be transferred into an ongoing governance structure. Organizations that use the data foundation from the migration project for ongoing contract governance have a structural advantage over those that start from scratch after go-live.

What the Renewal Governance Moment Has to Do With Migration

The first renewal negotiation after RISE go-live typically takes place three to five years after contract signing. Organizations that at that point have no reliable usage data, no documented contract deviations, and no structured negotiation preparation are negotiating without a foundation.

The governance moment before renewal does not begin shortly before the renewal date, but on the day of go-live. Every 14-day review, every documented deviation between contractually agreed and actual service scope, every usage change is material for the later negotiation.

This is the structural reason why signing the RISE contract is not the end of the governance task, but the beginning. Governing SAP contracts after signing is not an effort that ends after go-live. It is an ongoing discipline that runs across the entire contract term.

Four Roles, One Governance Model

Ongoing contract governance after migration touches four roles, each with different perspectives on governance moments:

The Contract Manager is responsible for ongoing compliance, the contract structure, and verifying that scope and billing align. In the post-migration phase, the primary task is integrating the new RISE contract into the regular review cycle.

Procurement is responsible for purchasing decisions, terms, and the preparation of renewal options. The relevant governance moments in the cost dimension lie in ACV development and in the early identification of expansion needs that feed into the next negotiation.

Controlling carries cost allocation, invoice review, and budget clarity. In the post-migration phase, new challenges arise in the internal allocation of RISE costs because the subscription model requires a different allocation logic than the previous license model.

Executive carries prioritization decisions, approvals, and the strategic renewal decision. Governance moments at this level are infrequent but significant: organizations that only review the renewal timing when the deadline is near have already largely forfeited their strategic negotiating position.

FAQ {#faq}

1. What happens to my SAP ERP system on December 31, 2027?

The system continues to run. What ends is Mainstream Maintenance: Legal Changes, Support Packages, and error correction in the standard are no longer provided automatically. From January 1, 2028, continued operation requires either an Extended Maintenance addendum or operation under PCE/RISE, which includes Extended Maintenance in the subscription price.

2. What does Extended Maintenance cost and how is the base calculated?

Extended Maintenance costs two additional percentage points on the Maintenance Base. The Maintenance Base covers all BS7 Core Applications, add-ons, and runtime databases. By deliberately surrendering no-longer-needed use rights, the base can be reduced before Extended Maintenance begins, which substantially reduces the surcharge in absolute terms.

3. Does Extended Maintenance apply to all systems, or can I exclude individual ones?

Extended Maintenance applies to the entire on-premise BS7 landscape. Cherry-picking by system is not possible. When you apply for Extended Maintenance, you apply for it across all BS7 systems.

4. What is the Transition Option and when does it expire?

The Transition Option is a time-limited cloud operating model for SAP ERP EhP 7 and EhP 8 in SAP ERP Private Edition. Service start is January 1, 2031; the end date is December 31, 2033. The subscription window runs from 2028 to 2030.

5. What does the Transition Option cost compared to a regular RISE contract?

The Transition Option carries a 20 percent surcharge over the comparable price of a regular SAP ERP Private Edition. In addition, the Max Success Plan Transition Services is mandatory. Customers who subscribed before end of 2025 do not pay the surcharge.

6. Can I apply on-premise licenses as a credit toward a RISE contract?

Yes, through the Cloud Extension Program. Three credit types are available: Maintenance Credits, Service Credits, and Cloud Credits. The amount depends on negotiation and is not publicly tabulated. Early negotiations typically strengthen the negotiating position.

7. How long is dual-use operation contractually permitted?

SAP permits dual-use operation for a contractually defined transition period. The typical range in practice is six to 18 months. The exact duration and the usage rules during parallel operation must be established in the RISE contract.

8. What happens to add-ons that have no S/4HANA equivalent?

Add-ons without an S/4HANA equivalent can still be operated in the Transition Option if they appear on the available add-on list. They must, however, be migrated to alternative solutions by end of 2033 at the latest. The S/4HANA Compatibility Pack applies only through end of 2030 for cloud subscriptions.

9. What is shelfware and how do I use it as a negotiating argument?

Shelfware consists of licenses for which maintenance is paid without the use rights being exercised. When moving to RISE, shelfware can be used as an additional argument in the credit negotiation. The prerequisite is a complete inventory via the SAP Readiness Check and license register.

10. Which add-ons are available in the Transition Option and which are not?

Available add-ons span categories including Supply Chain (APO as connector, EWM), Finance (Revenue Accounting, Treasury), HCM (HR Renewal, SuccessFactors EC Integration), Compliance (GINVOICING), and Integration. The complete list is accessible in the SAP Help Portal and in SAP Customer Evolution documentation. Only EhP 7 and EhP 8 are supported.

11. What does January 1, 2028, mean as a cutover date for RISE customers?

For customers whose entire system landscape is operated in SAP ERP Private Cloud Edition by January 1, 2028, Extended Maintenance is included in the subscription price without additional surcharge. That is the structural simplification RISE offers compared to on-prem Extended Maintenance.

12. How do I govern SAP contracts after go-live on RISE?

Ongoing contract governance after go-live covers the four governance dimensions: usage (FUE development, BTP credits), authorizations (role design, license classes), infrastructure (SLA monitoring, sizing), and cost (ACV tracking, derived charges, renewal preparation). A structured 14-day review process ensures governance moments are identified before they become budget deviations.

13. How does Extended Maintenance relate to the on-prem hyperscaler choice?

Extended Maintenance is relevant exclusively for on-premise operation. Organizations that remain on-prem with Extended Maintenance make no hyperscaler decision. The choice between Azure, AWS, and Google Cloud only becomes relevant when moving to RISE or the Transition Option. This decision should be anchored in the contract and affects both complementary services and the long-term cost structure.

14. What happens if I haven't fully migrated to S/4HANA by end of 2030?

After end of 2030, there is no structured SAP maintenance for on-premise BS7 systems without the Transition Option. Organizations that by that point have neither completed Extended Maintenance nor subscribed to the Transition Option and have not yet migrated to S/4HANA are in an operating state without a contractual basis for regular SAP support. Third-party maintenance is a possible option but requires its own contract structures and typically does not cover the full scope of SAP support.

15. Which SAP tools support preparation of the migration decision?

SAP provides several tools that are relevant in the decision preparation phase: the SAP Readiness Check delivers technical system data for sizing and custom code analysis. SAP Signavio Process Navigator supports fit-to-standard alignment. SAP Cloud ALM is the ALM tool for RISE operations after go-live. These tools are included in the RISE contract but in practice are frequently activated only after go-live rather than during the preparation phase.

Next Steps {#next-steps}

The 2027 maintenance end is a concrete governance moment with a fixed decision calendar. Organizations that evaluate their options now retain room to maneuver for negotiation, planning, and decision-making.

Book a Contract Check: A structured analysis of the Maintenance Base, credit potential, and Transition Option eligibility in four weeks. Fixed price EUR 7,900. Schedule an initial conversation

Use FinOptory AI: For an initial assessment of your own maintenance timeline and options, FinOptory AI is available on the website. To FinOptory AI

Further Resources: For a complete overview of all nine SAP product types and their governance requirements, we recommend the pillar on SAP Contract Governance. For questions about renewal preparation, we refer you to the pillar on renewal governance.

Bernhard Mändle, Managing Consulting, FinOptory Sources: SAP Customer Evolution, DSAG AK Lizenzen, SAP Help Portal (help.sap.com), SAP Note 2269324 (Compatibility Scope Matrix), SAP Note 2741041 (NetWeaver BW Maintenance), Redress Compliance, SAP Licensing Experts

Table of Contents