Dual-Use Period: Governance During Parallel ECC and Cloud ERP Operations
During a migration to RISE, two systems run simultaneously: the existing on-premise environment and the new cloud landscape. This parallel operation, known in the industry as the dual-use period, typically lasts six to eighteen months. Organizations that do not actively govern it lose track of which users are licensed on which system, when maintenance costs expire, and where the RISE ACV begins. The governance requirements of this phase often surface late in the migration project, even though the contract can reflect them from the start.
What the Dual-Use Period Is and What It Is Not
The dual-use period describes the timeframe in which a company operates both its on-premise landscape and the newly provisioned RISE environment in production. This is not an edge case: almost every migration proceeds in waves. Not all business units, company codes, or system classes go live at the same time. Individual systems keep running until the last process has been migrated and cutover is fully complete.
What sets this phase apart from a simple test environment: both systems are live. Users actively work in both environments. Transactions are posted on both sides. That has direct consequences for licensing, maintenance billing, and the contractual boundary between the old and new system.
What the dual-use period is not: a cost-free transition window. SAP grants dual-use rights under the Cloud Extension Program, but only under conditions that must be explicitly defined in the contract. Organizations that assume these rights without anchoring them contractually are operating in a gray area.
What SAP Permits Contractually and What It Does Not
The Cloud Extension Program allows existing customers to use both on-premise and cloud licenses temporarily during migration, without paying twice for the same user. This dual-use entitlement is subject to conditions.
First, the RISE contract must already be signed before dual-use rights take effect. A running on-premise system without an active RISE contract is not dual-use. It is standard on-premise operation with full maintenance charges.
Second, the dual-use period is time-limited. The permitted duration is defined in the contract and varies. It is not a permanent hybrid model. Organizations that want to run both environments indefinitely need a different contractual basis.
Third, the dual-use entitlement applies to user licenses, not automatically to all components of the on-premise landscape. Add-ons, third-party maintenance contracts, and AMS services for the legacy system continue until they are explicitly terminated.
A common governance moment arises here: maintenance contracts for on-premise systems keep running even after usage has shifted to RISE. Organizations without systematic tracking end up paying for maintenance that no longer delivers value.
FUE Licensing in Parallel Operations: Who Gets Counted Where?
The FUE model (Full Use Equivalent) normalizes different user types into a single comparable metric. In the RISE contract, the FUE count is the central licensing measure. In the on-premise system, named users and their access profiles form the billing basis.
During the dual-use period, this creates a practical challenge: the same person can be active on both systems. In the on-premise system, they carry a role set from the ECC landscape. In the RISE system, they gradually receive their new access in S/4HANA Cloud Private Edition. Without active governance, they remain fully licensed in both systems.
This is precisely the first governance moment in the usage dimension: who migrates completely, and when? From what date is a user exclusively active in RISE? When can the on-premise access be deactivated? Without this data, neither FUE optimization nor a targeted reduction of the on-premise license structure is possible.
The FUE model offers structural room to maneuver: organizations that reduce role breadth and correctly classify user types can cover more users with fewer FUEs. In the dual-use phase, however, this room is limited, because role definitions still originate from the ECC system and are often only cleaned up as part of the migration to S/4HANA. That is one more reason not to leave governance of this phase to the migration project, which is primarily focused on the technical go-live.
Billing Demarcation: When Does On-Premise Maintenance End, When Does RISE ACV Begin?
The billing boundary between the old and new system is one of the most common sources of budget variance in the migration phase.
The RISE ACV typically begins on contract signature or the agreed start date, regardless of when the productive go-live occurs. In practice, this means companies pay for RISE while the on-premise system is still running at full capacity. Organizations that do not actively govern the RISE contract start date and align it with the actual migration timeline accumulate unnecessary dual costs.
On the on-premise side: maintenance contracts run until terminated. There is no automatic billing based on actual system usage. An organization that shuts down its on-premise system on March 1 continues to pay maintenance until the next termination date if it has not given notice in time.
On-premise maintenance termination typically carries a notice period of ninety days to year-end. This means: an organization going live on RISE in October must submit the termination notice no later than September to stop paying from January 1. Missing this governance moment in the cost dimension means paying for another year.
The same applies to third-party maintenance contracts, AMS agreements for the legacy system, and any infrastructure contracts for on-premise hardware or co-location. All of these have their own terms and notice periods that have nothing to do with the RISE start date.
Four Governance Moments in the Dual-Use Phase
The dual-use period does not change the fundamental structure of contract governance, but it shifts the weight. All four governance dimensions are active, and each generates specific tasks.
Usage: FUE distribution between on-premise users and cloud users must be monitored continuously. Who is active in which system changes week by week during a phased migration. Without active tracking, the result only becomes visible at the next measurement date, when SAP audits the ACV profile.
Entitlements: Role designs from ECC are carried over to S/4HANA. The breadth of those roles determines which FUE type a user is assigned to. An overly broad role set costs more FUEs than necessary. Migration is the governance moment where role design and license optimization converge. This governance moment can be used during the dual-use phase, or missed entirely if no systematic approach is in place.
Infrastructure: On the on-premise side, SLAs continue that no longer reflect the actual protection requirements. On the RISE side, the agreed SLAs apply within the hyperscaler model. Reconciling these two SLA environments is part of infrastructure governance during the migration phase. Organizations that have not contractually anchored hyperscaler selection and SLA parameters only notice discrepancies once they are in production.
Costs: Tracking ACV during the ramp-up phase, offsetting maintenance credits against ACV, terminating on-premise maintenance in a targeted way, carrying extended maintenance surcharges as a separate budget line item. These four tasks occur simultaneously and are interdependent. A systematic view of what is running on which system and what costs it is generating is a prerequisite for ensuring no line item is missed.
Governance Gaps in Parallel Operations: What Systematic Monitoring Must Deliver
The central challenge of the dual-use phase is not technical complexity. It is the data situation. The question "who is currently using what on which system?" cannot be answered from the RISE contract. It cannot be answered from the on-premise license inventory. It requires a dedicated monitoring layer that brings both worlds together.
Three governance gaps are common in practice.
First, the usage gap: both systems are measured, but not synchronized. Organizations that count active users on both systems without knowing the overlap cannot perform FUE optimization.
Second, the cost gap: maintenance costs for the legacy system, ACV costs for the new system, and ongoing migration project costs are tracked in separate budget lines. A consolidated view of total transition-phase costs is missing until the controller reconciles the numbers after year-end.
Third, the deadline gap: notice periods for maintenance contracts, terms of AMS agreements, shutdown dates for on-premise systems, and ramp-up milestones in the RISE contract all live in different documents. Organizations that only learn about the next relevant deadline when it becomes urgent lose room to act.
Systematic monitoring in the dual-use phase therefore means: a shared data foundation that brings together contract deadlines, usage data, and cost positions from both systems, and that surfaces governance moments before they arrive.
What Becomes the Governance Task After the Dual-Use Period
The dual-use period ends when the on-premise system is fully decommissioned. From that point, RISE is the only productive environment. The ongoing governance task changes: dual-system oversight gives way to governing a single, complex contract structure.
What remains is the data foundation built during the migration. Organizations that documented clearly during the dual-use phase, which users migrated when, which role changes were made, and which contracts were terminated at what point, enter the post-go-live phase with a solid baseline for ongoing FUE governance, SLA reconciliation, and ACV tracking.
Organizations that did not build this documentation start post-go-live governance without a reference point. Budget variances can no longer be traced back to specific migration decisions.
The question of who governs SAP contracts after signature therefore does not begin at the final go-live. It begins the moment two systems run in parallel and decisions about usage, entitlements, infrastructure, and costs arise every day.
Related articles:
- Pillar 7: SAP On-Premise Migration, Maintenance End 2027, and Contract Governance: Hub page with full overview
- On-Premise License Credits Against RISE: Mechanics and Negotiation Position: Cluster 4: How maintenance credits are offset against RISE ACV
- SAP Product Types and Their Contract Structure: Pillar 1: Which product types require dedicated governance during migration
Managing a migration or planning your move to RISE? A contract check delivers clarity on your deadlines, credits, and governance gaps in four weeks. Fixed price EUR 7,900.
Next Steps
If you would like your current contract reviewed for risks and available commercial levers: the FinOptory Contract Check is a fixed-price engagement that delivers a structured basis within four weeks.
This article is part of our topic hub on on-premise migration and the SAP transition option. To have one specific contract assessed, the FinOptory Contract Check delivers a structured basis within four weeks.
Last updated: July 2026