Why Cloud and Hybrid SAP Landscapes Create Unique Compliance Risk

The traditional on-premise SAP compliance model was relatively contained. Your SAP landscape sat in your data centre, your users accessed it via your network, and compliance was measured annually through USMM and LAW. The introduction of cloud-hosted SAP, RISE with SAP, SuccessFactors, Ariba, and SAP Business Technology Platform has shattered this contained model.

In a hybrid landscape, the same employee may access an on-premise SAP ECC system for core ERP transactions and also use SuccessFactors for HR processes, Ariba for procurement, and a BTP-hosted extension for custom workflows. Each of these environments has its own licensing model, its own measurement methodology, and its own compliance obligations — and SAP does not offer a unified licence that spans all of them.

This structural fragmentation is the root cause of most cloud and hybrid compliance failures. Organisations that manage their SAP licence position as if it were still a single on-premise deployment will accumulate compliance gaps across cloud modules, BTP credits, and digital access document volumes that only become visible during an audit.

The Three Principal Cloud Deployment Models and Their Licence Implications

Model 1: RISE with SAP (SAP-Managed Private Cloud)

RISE with SAP is SAP's flagship cloud migration offering. It bundles SAP S/4HANA Cloud Private Edition, infrastructure managed by SAP on a hyperscaler of the customer's choice, SAP Business Technology Platform starter credits, and access to certain SAP services including the Business Process Intelligence tool. The single subscription model simplifies the commercial relationship but introduces its own compliance complexity.

What is critical to understand about RISE with SAP is the gap between what is marketed as included and what the contract actually delivers. RISE includes the core S/4HANA Cloud Private Edition licence and managed infrastructure. It does not automatically include all SAP modules that a customer was using in their on-premise ECC environment. Industry solutions, analytics licences, integration platform licences, and certain add-on modules must be separately licensed and separately priced within the RISE contract. Customers who sign RISE contracts without independently validating the module scope frequently discover compliance gaps during implementation, when it is contractually too late to adjust the terms without cost.

The SAP annual support obligation within RISE is embedded in the subscription pricing, but the effective support cost remains calibrated to approximately 22% of the net equivalent licence value. This means that the support cost component of a RISE subscription is a meaningful factor in the 5-year total cost of ownership calculation, and it increases in line with subscription price escalation clauses.

Model 2: BYOL (Bring Your Own Licence) on Hyperscaler Infrastructure

BYOL allows organisations to run SAP software on their own cloud infrastructure — typically AWS, Microsoft Azure, or Google Cloud — using their existing SAP licences. SAP certifies specific hyperscaler configurations for SAP workloads, and running SAP on non-certified infrastructure is a licence compliance violation regardless of the technical functionality.

BYOL compliance requires maintaining an up-to-date certified infrastructure profile, ensuring that SAP system landscape descriptions are kept current in the Customer Interaction Centre, and notifying SAP of material changes to the hosting environment. Organisations that migrate SAP workloads to hyperscaler infrastructure without notifying SAP of the change in hosting model risk invalidating their support entitlements, which SAP can treat as a licence compliance violation.

The commercial advantage of BYOL over RISE is that well-optimised BYOL deployments with negotiated hyperscaler agreements and existing perpetual SAP licences can deliver significantly lower 5-year total cost of ownership than RISE subscriptions. However, this advantage requires active licence management, certified infrastructure governance, and contractual protection against SAP's periodic attempts to reclassify BYOL customers as RISE customers at renewal.

Model 3: Hybrid On-Premise and Cloud (The Most Common Reality)

The majority of large enterprises operate in a hybrid model: core ERP workloads remain on-premise or in a self-managed cloud while cloud-native SAP modules such as SuccessFactors (HR), Ariba (procurement), Concur (expense management), and SAP Analytics Cloud handle specific business functions. This is the most complex compliance scenario because each environment is governed by different contractual terms, measured using different tools, and invoiced through different commercial channels.

The double-licensing trap is a persistent risk in hybrid environments. When a user is covered under a perpetual on-premise professional licence and also has access to a cloud module, they may require a separate cloud-specific licence even though the underlying functionality overlaps. SAP's on-premise licences and cloud module licences are not interchangeable, and the commercial terms explicitly prevent customers from claiming that an on-premise licence covers access to a cloud application.

"The hybrid model is the most expensive licensing model in the SAP ecosystem — not because the technology costs more, but because governance is harder, tools are fragmented, and compliance gaps accumulate silently across two separate licensing domains."

Running SAP in a hybrid or cloud environment?

We conduct independent cloud and hybrid SAP licence position assessments for enterprise organisations.
Request an Assessment →

Dual-Use Rights: The Migration Window Compliance Strategy

During an S/4HANA migration, organisations running both ECC (source) and S/4HANA (target) systems simultaneously create a period of parallel operation where both systems are in use concurrently. Without dual-use rights contractually established, this parallel operation period can be treated by SAP as a scope expansion requiring additional licence purchases.

Negotiating dual-use rights means securing contractual permission to run both the existing ECC system and the new S/4HANA system during a defined migration period without incurring double licence costs. SAP will typically grant time-limited dual-use rights as part of a migration agreement, but the scope, duration, and conditions of these rights must be explicitly defined in writing before the migration project begins.

The absence of contractual dual-use rights in migration agreements is one of the most common sources of unplanned SAP cost in migration projects. Migration projects that encounter delays — and most do — face the prospect of the dual-use period extending beyond the contractual window, at which point SAP may treat the continued parallel operation as a billable scope expansion.

BTP Credits in Hybrid Environments: The Hidden Consumption Risk

SAP Business Technology Platform is the integration and extension layer that connects SAP cloud applications, on-premise systems, and third-party applications. BTP is licensed on a credit consumption model where each BTP service (integration flows, API management, low-code development, data analytics) consumes credits at different rates.

In hybrid environments, BTP is frequently deployed to bridge on-premise SAP systems with cloud modules. Integration flows connecting SuccessFactors to on-premise payroll systems, Ariba-to-SAP purchase order workflows, and custom extension applications all consume BTP credits. The credit consumption rate in production environments consistently exceeds initial planning estimates because integration scenarios proliferate as business users discover BTP's capabilities and request new connections.

Organisations that received a BTP credit allocation as part of a RISE with SAP or S/4HANA bundle deal frequently exhaust their allocated credits within 12 to 18 months of go-live. SAP's response to credit depletion is to initiate a commercial conversation that typically results in a BTP subscription uplift or top-up purchase. Proactive BTP credit monitoring and governance — establishing approval workflows for new integration scenario development and tracking consumption against the credit budget — is the only effective control.

SuccessFactors PEPM Pricing and Hybrid Compliance

SAP SuccessFactors is licensed on a Per Employee Per Month (PEPM) model. The number of active employees in your system at any point determines your licence fee for the following period. In a hybrid environment where SuccessFactors manages HR data and on-premise SAP manages payroll or finance transactions, the employee count in SuccessFactors may differ from the user count in your on-premise system, creating reconciliation complexity.

The PEPM model creates compliance risk at the point of workforce expansion. When headcount grows — through organic growth, acquisition, or contractor onboarding — the SuccessFactors instance may accept the new employees without alerting the procurement team that the PEPM threshold has been exceeded. SAP's retrospective true-up mechanism for SuccessFactors means that underpayment across a measurement period accumulates and is collected at the next contract review, with potential interest-equivalent adjustments.

Eight Best Practices for Cloud and Hybrid SAP Licence Compliance

1. Maintain a Single Licence Register Across All SAP Environments

The most fundamental compliance control in a hybrid environment is a single, authoritative register that captures every SAP licence entitlement across on-premise, RISE, BYOL, and cloud module contracts. This register must map entitlements to systems, user populations, and usage metrics. Without it, the compliance position cannot be assessed, and commercial decisions are made on incomplete information.

2. Validate RISE with SAP Module Scope Before Signing

Before executing a RISE with SAP contract, produce an independent module-by-module scope validation that compares the RISE subscription scope against your current ECC module deployment. Every module used in your current landscape must be explicitly accounted for in the RISE contract. Modules that are not in scope will require separate licensing or must be decommissioned as part of the migration.

3. Negotiate Dual-Use Rights with Defined Duration and Scope

Any S/4HANA migration project, whether via RISE or BYOL, must include contractual dual-use rights with a migration duration buffer of at least 6 months beyond the planned go-live date. Projects that run on time are the exception, and contractual protection for extended parallel operation must be secured before the migration begins.

4. Establish BTP Credit Governance Before Go-Live

Implement a BTP credit governance process before deploying integration scenarios in production. Define a credit budget by business domain, establish approval workflows for new integration scenario development, and implement monitoring dashboards that track consumption against budget in real time. Assign a named owner for BTP credit oversight.

5. Conduct Annual Cloud Module Compliance Reviews

Cloud module licences (SuccessFactors, Ariba, Concur, SAP Analytics Cloud) operate on subscription terms with different measurement dates and renewal windows. An annual compliance review that reconciles actual usage against contract entitlement across all cloud modules, conducted independently of SAP's own measurement cycle, provides advance warning of gaps before SAP identifies them.

6. Maintain SAP's Certified Infrastructure Requirements for BYOL

BYOL deployments on hyperscaler infrastructure must comply with SAP's certified infrastructure requirements. Maintain documentation of the certified infrastructure profile for each SAP system, and establish a change management process that triggers a compliance review whenever infrastructure configurations are modified. Infrastructure certification gaps invalidate SAP support entitlements and create compliance exposure.

7. Perform a 5-Year TCO Analysis Before Committing to RISE

The RISE versus BYOL decision is fundamentally a 5-year total cost of ownership calculation. RISE offers simplicity and a single vendor relationship but carries a subscription escalation risk if price increase clauses are not capped at contract execution. A well-managed BYOL deployment with negotiated hyperscaler pricing and optimised perpetual licence use can deliver materially better economics over a 5-year horizon. Commission an independent TCO analysis before committing to either path.

8. Include Cloud Compliance in Contract Negotiations

Cloud module contracts contain renewal terms, automatic uplift clauses, and measurement provisions that can be negotiated. SuccessFactors PEPM caps, BTP credit top-up pricing, and RISE subscription escalation limits are all commercially negotiable at the point of contract execution or renewal. Organisations that accept SAP's standard cloud contract terms without independent negotiation support typically pay 15 to 25% more than the market rate for equivalent entitlements.

SAP Cloud Licensing Updates

RISE with SAP pricing and BTP credit models change regularly. Subscribe to our SAP knowledge hub for quarterly compliance updates.

Common Compliance Failures in Cloud and Hybrid Environments

The most common compliance failure is assuming that RISE with SAP covers all existing module usage. Organisations that have operated SAP for many years accumulate a complex module landscape, and the standard RISE scope covers only the modules explicitly documented in the migration scope. Industry solutions, analytics modules, custom development environments, and specialised integration tools are frequently omitted from the initial RISE scope and discovered during implementation.

The second most common failure is failing to track digital access document creation across hybrid integration scenarios. In a hybrid environment, the BTP integration flows connecting on-premise SAP to cloud applications generate document creation events that are counted under the DDLC metric. Organisations that have not separately licensed digital access for their hybrid integration architecture are accumulating undisclosed DDLC exposure with every transaction that crosses the on-premise to cloud boundary.

Finally, organisations frequently underestimate the cost complexity of operating SuccessFactors in parallel with on-premise HR systems during the transition period. The PEPM billing model begins from the date SuccessFactors users are onboarded, not from the date of full cutover, and the cost of running both systems during a phased transition can be material if the transition period is not tightly managed and contractually bounded.