The Cloud: Technical Innovation, Pressure for Business Transformation, and Digital Sovereignty

At the heart of this epochal shift driven by cloud computing lies a paradigm shift from the traditional purchase of software to a subscription-based model for accessing IT functionalities via cloud infrastructures. For the global customer base of SAP, the world leader in ERP, this development, however, represents not merely a technical generational shift, but a commercial, legal, and organizational restructuring.

Driven by the expectations of international capital markets, which demand recurring and predictable subscription revenue, SAP’s executive leadership has effectively abandoned its strategy of selling software alone. By setting the end of maintenance support for the established SAP Business Suite 7 and the core SAP ERP 6.0 system for the end of 2027—accompanied by a fee-based, optional extension through the end of 2030—immense pressure to transform is being exerted on both small and medium-sized businesses and large corporations alike.

This predicament requires those in charge in IT departments, executive suites, and Customer Centers of Expertise (CCoE) to conduct a sober and critical analysis: The allure of cloud marketing rhetoric promises more agile business processes, effortless access to artificial intelligence, and drastically reduced operating costs. The operational reality in German-speaking countries and worldwide, however, reveals a high degree of skepticism and architectural disillusionment. A significant portion of SAP’s existing customers are resisting the forced, hasty shift to public cloud architectures and is seeking ways to secure its own digital sovereignty, undisturbed control over business-critical crown jewels, and the preservation of value in process logic that has evolved over time—see ABAP modifications.

Against this backdrop, the topic of cloud computing is evolving from a purely technical infrastructure decision into a matter of vital importance concerning strategic freedom of action. The theoretical classification of cloud computing is traditionally divided into the three well-known service models: Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and Software as a Service (SaaS).

IaaS, PaaS and SaaS

While IaaS provides only purely virtual computing power, storage media, and network capacity, PaaS offers existing SAP customers structured runtime environments, databases, and application services. The SaaS model, on the other hand, represents a complete shift away from in-house IT infrastructure management by providing ERP users with a ready-to-use software application—including all maintenance and operational tasks—on a turnkey basis via the Internet.

However, in the practical reality of complex industrial enterprises, it has become clear that rigid, monolithic SaaS approaches rarely meet the highly differentiated requirements of modern value chains. Rather, flexible, hybrid cloud architectures are needed that seamlessly orchestrate on-premises data centers, dedicated private cloud instances, and scalable hyperscaler capacities.

Within this framework, the open-source specialist Red Hat plays a key role for the entire SAP ecosystem. While Linux has been the undisputed standard operating system for the SAP HANA in-memory database platform for many years, the Red Hat Enterprise Linux (RHEL) has evolved into the preferred backbone and standard foundation for SAP’s internal IT landscapes as well as for the entire customer portfolio of SAP Enterprise Cloud Services. The partnership between SAP and Red Hat ensures that demanding SAP workloads can run on a hardened, certified, and fail-safe infrastructure, whether in a company’s own on-premises data center or on the infrastructures of global hyperscalers.

Enterprise Kubernetes

However, the SAP customer’s true architectural IT liberation from proprietary lock-in is only achieved through the use of the Red Hat OpenShift enterprise Kubernetes platform. OpenShift acts as a universal abstraction and integration layer that serves as a vendor-neutral framework spanning traditional on-premises infrastructures, private hosting environments, and the public platforms of Microsoft Azure, Amazon Web Services, and Google Cloud. Through this cloud-agnostic abstraction, OpenShift protects users from creeping vendor lock-in with regard to any given cloud provider. ERP developers and IT architects gain the strategic freedom to design applications once and run them flexibly anywhere: Develop once, deploy anywhere!

Combining OpenShift with the Red Hat Ansible Automation Platform also enables full end-to-end automation of complex system landscapes, rollout processes, security policies, and daily IT operations tasks. An outstanding example of the IT convergence of open source and SAP architecture is the SAP Edge Integration Cell (EIC), which serves as a modern, containerized successor to traditional process orchestration systems.

„We ensure security in the cloud with AI agents by
”the development of a runtime environment with our technology partner, Nvidia."

Thomas Pfiester,
Head of Global Customer Engagement and Adoption,
SAP, (Keynote speaker at the DSAG Annual Convention)

The Edge Integration Cell requires a fault-tolerant Kubernetes runtime environment and has been officially released for Red Hat OpenShift, enabling companies to run business-critical API endpoints and data integrations on-premises at their own facility or in a private cloud, while ensuring connectivity to the Business Technology Platform (SAP BTP). Even within Microsoft infrastructures, the Azure Center for SAP Solutions builds on the jointly developed SAP Deployment Automation Framework (SDAF) and uses Red Hat components for automated infrastructure deployment. Open source and hybrid container platforms are thus proving to be an indispensable shield for safeguarding the digital sovereignty of the European industrial sector in the cloud.

A look at SAP’s product portfolio reveals a diverse range of operating and licensing options that differ drastically from one another in terms of their scope of functionality, configuration flexibility, and commercial obligations. At the traditional end of this spectrum is the classic on-premises model. In this model, the customer purchases or leases the software licenses and operates the S/4 system in its own data center or through a dedicated hosting arrangement with a service provider. The invaluable advantage of this option lies in unrestricted system control, full freedom of configuration in the backend, and release and patch management without time constraints. The company retains absolute data sovereignty and is not forced to follow rigid vendor-imposed upgrade cycles.

The major drawback, however, lies in the fact that the company bears full operational responsibility for hardware, database backups, system reliability, and maintaining a staff of highly specialized IT personnel. In addition, SAP is increasingly excluding existing customers with purely on-premises installations from innovative enhancements such as native AI scenarios or specific BTP functions in order to artificially increase the pressure to migrate.

Rise and Grow with SAP

SAP is promoting the comprehensive "Rise with SAP" package as the primary transformation path for its existing customer base. At the heart of this program is S/4 HANA Cloud Private Edition. Technically speaking, the Private Cloud is a dedicated single-tenant system that runs on SAP’s infrastructure or that of selected hyperscalers and is provided as a managed service.

In direct contrast to the Public Cloud, the Private Edition offers virtually the same range of business functions and the same broad industry coverage as the on-premises version. With the Private Edition, existing customers can continue to use the familiar SAP GUI, perform in-depth customizing, and maintain existing Z-developments, while the basic infrastructure operations, the application of security patches, and defined technical services are handed over to SAP. However, even within the Private Edition, SAP is continuously increasing pressure on customers to adhere to the Clean Core principle and to gradually migrate customer-specific extensions to the Business Technology Platform or into decoupled structures.

At the opposite end of the spectrum is the commercial package “Grow with SAP,” which is specifically designed for new customers, midsize companies with highly standardized processes, or separate subsidiaries. Grow is built on S/4 Hana Cloud Public Edition, a true multi-tenant SaaS product.

In the public cloud, multiple customers share the physical infrastructure and basic software functions, while the data remains strictly logically separated. This model promises short implementation times, continuous functional innovations, and the fully automated deployment of system updates directly by SAP. However, this apparent convenience comes at the cost of significant limitations: Direct access to the ABAP backend code or the classic database layer is categorically prohibited. Customizations are possible exclusively through predefined in-app extensions or through external side-by-side extensions on the BTP. SAP Cloud customers must be prepared to radically subordinate their operational workflows to SAP’s predefined best-practice processes.

Migrating from a traditional on-premises environment to the cloud-based Rise or Grow platforms requires a necessary restructuring of the contractual and accounting frameworks. In the legacy R/3 or ECC environment, companies purchased perpetual licenses, which were capitalized as capital expenditures (CapEx) on the balance sheet. In addition, there was an annual maintenance fee—typically 22 percent—for technical support and the right to software updates.

Upon entering into a cloud subscription agreement, this structure is completely converted into ongoing operating expenses (OpEx). Ownership of the software remains with the manufacturer; the customer merely acquires a time-limited right of use in the form of a lease. If the company stops paying the monthly or annual installments, access to the ERP cloud system is completely revoked.

Cloud Licensing Metrics

The key management tool for this licensing transformation is the Full Use Equivalent (FUE) metric. Instead of purchasing a specific number of user license types (such as Professional, Functional, or Productivity User) as in the past, the company subscribes to a variable allocation of FUE points. The various S/4 Cloud usage types are converted using fixed equivalence factors: One FUE corresponds exactly to one S/4 for Advanced Use (comparable to the former Professional User), five S/4 for Core Use (comparable to the Functional User), or thirty S/4 for Self-Service Use.

For Developer Access, SAP requires a ratio of two FUEs per developer in the FUE key. While SAP touts the FUE model as a flexible solution that allows for demand-driven shifts in capacity within the booked user tiers without lengthy contract renegotiations, independent licensing experts warn of drastic hidden price increases.

The primary cost trap of the FUE model lies in the business transition from usage-based (Did-Do) to authorization-based (Could-Do) system measurement. While in the old ECC environment, the system tracked which transactions an employee actually performed, SAP in the S/4 Cloud editions strictly licenses based on the authorizations and roles assigned in the system.

If, due to unresolved, historically accumulated „monster roles“ or blanket system profile assignments, an employee theoretically has the authorization to access advanced logistics or financial functions, they are automatically classified by the vendor’s verification tool (the STAR Service or S/4 Trusted Authorization Review) into the most expensive license category (Advanced Use), even if they never use these functions in their day-to-day work. Without a thorough cleanup of authorization structures prior to a cloud contract transition, existing customers face cost increases of 20 to 50 percent compared to their previous on-premises maintenance fees.

In addition to FUE subscriptions, consumption-based billing models on the Business Technology Platform and within the Business Data Cloud (SAP BDC) increase commercial risk. Through BTP Capacity Units, Cloud Credits, or consumption-based AI Units, customers pay for their actual usage of computing power, data volumes, or AI tokens.

Cloud Bill Shocks

The contractual challenge here lies in a forfeiture mechanism: Credit quotas paid in advance (such as under a CPEA or BTPEA contract) are forfeited without replacement at the end of the respective contract year if they have not been used due to a lack of productive use cases. If, on the other hand, unforeseen load spikes or uncontrolled data queries occur during ongoing operations, SAP immediately charges for the excess usage at significantly higher list prices, which regularly leads to the dreaded “cloud bill shocks.”.

This strict monetization is complemented by the usage-based Digital Access licensing model and Version 4 of the SAP API Policy, which was issued in April 2026. With the API Policy, Walldorf has erected a digital customs barrier that regulates the direct, unlicensed mass extraction of data and access by third-party AI agents to the ERP system.

Anyone who exports business-critical data to third-party systems without paying expensive BTP fees will be charged for indirect use or subject to usage-based licensing fees. European user associations such as DSAG and the cloud association CISPE strongly condemn this practice as an attempt—which raises antitrust concerns—to force a closed market and relentlessly chain users to the proprietary BTP ecosystem.

A direct comparison of the three primary operating models reveals profound structural differences that go far beyond mere hosting issues. In terms of system governance and operational flexibility, the traditional on-premises model continues to serve as the benchmark for highly complex industrial companies: The user retains unrestricted control over the timing of system upgrades, feature packs, and database patches. There are no predefined mandatory maintenance windows, and customer-specific developments in the ABAP namespace can be operated without restrictions. However, the company must organize all efforts related to hardware sizing, operating system support, database administration, and adherence to complex compliance and IT security standards either in-house or through separate service provider contracts.

The S/4 Cloud Private Edition (as part of Rise with SAP) aims to combine the full functionality of the on-premises system with the convenience of a managed cloud environment. From a technical perspective, it is an isolated single-tenant instance in which hosting is transferred to SAP, but the existing customer retains extensive rights to influence the choice of the specific hyperscaler (Azure, AWS, Google Cloud, or European providers) and the specific geographic location of the data center.

Private Cloud vs. On-Prem

The feature set of the Cloud Private Edition includes all 31 industry solutions and 39 language versions available in the on-premises environment. Although existing SAP customers enjoy a significantly more flexible upgrade strategy than in the public cloud and can defer system updates within the mainstream maintenance window, they are still bound by SAP’s infrastructure requirements. The sizing of HANA database storage and application servers is directly linked to the amount of FUE purchased. If a system requires additional memory due to complex in-memory analyses without an increase in the number of users, expensive infrastructure add-ons must be licensed separately.

In contrast, the S/4 Cloud Public Edition (as part of Grow with SAP) represents the most radical cloud concept. As a true multi-tenant SaaS model, it offers the lowest specific operating costs for the IT infrastructure, since software updates, security patches, and infrastructure scaling are handled fully automatically by SAP in the background. The core functionality automatically expands with the semi-annual SAP releases.

Abap modifications

However, the Public Cloud requires absolute adherence to the Clean Core principle. Traditional Z-programming, modifications to standard SAP objects, or direct write access to database tables are technically impossible. Companies with specialized manufacturing processes, established custom workflows, or complex third-party system integrations quickly run into insurmountable barriers in the Public Edition. This explains why, according to DSAG’s investment reports, an overwhelming majority of established existing customers in the DACH region continue to reject the public cloud for their central ERP core and instead opt for on-premises or controlled private cloud scenarios.

A remarkable shift has taken place in the strategic communication of SAP’s executive leadership: At the international customer conference Sapphire 2026 in Orlando, the North Star architecture of the classic SAP Business Suite 7—which had been touted for years—was quietly phased out. It was replaced by the spectacular vision of the SAP Autonomous Enterprise. From this new, AI-centered perspective, S/4HANA is by no means the final destination of ERP evolution, but merely the necessary transactional data foundation and an indispensable stepping stone. The classic ERP core is relegated to a mere „system of record“ that operates in the background as a reliable posting server, while actual process execution and user interaction are shifted to higher-level intelligence layers.

The Joule Work user interface, combined with the SAP Autonomous Suite, serves as the operational face of this new era. Instead of employees opening hundreds of Fiori tiles or entering complex transaction codes, they describe their business intentions in natural language. Behind the scenes, over 50 domain-specific Joule assistants and more than 200 specialized AI agents orchestrate autonomous end-to-end processes in finance, procurement, supply chain, and human resources. An autonomous assistant such as the „Autonomous Close Assistant“ independently analyzes variances, reconciles accounts, and prepares the monthly close, while humans, acting as „humans in the loop,“ intervene only in unsolvable exceptional situations.

The SAP Knowledge Graph serves as an indispensable semantic brain, enabling these AI agents to understand SAP’s complex historical data model (SQL Server-based), which consists of over seven million data fields and tens of thousands of tables. The Knowledge Graph automatically translates relational database tables into machine-readable ontologies and a network model consisting of nodes and edges. It provides the language models and AI agents with the precise business context—such as the meaning of the interrelationships between customer orders, material master data, invoices, and delivery schedules—to effectively suppress stochastic hallucinations in the business-critical general ledger.

SAP Knowledge Graph

However, the claim that AI agents and the SAP Knowledge Graph could one day render a traditional ERP system completely obsolete does not hold up to analytical scrutiny: An ERP system remains irreplaceable because core business functions such as financial accounting, tax compliance, cost accounting, and legally compliant financial reporting require absolute, deterministic precision.

Language models are based on probabilistic calculations; fundamental laws of information theory demonstrate that a stochastic AI can never guarantee 100 percent accuracy. If a probabilistic AI agent were to operate without the rule-based logic of a deterministic ERP core, even the slightest deviations would lead to legally invalid postings or erroneous production approvals. S/4 HANA and cloud ERP thus remain the indispensable mathematical foundation upon which the cognitive autonomy of AI agents, acting as a control layer, is built.

The long-term outlook for cloud computing in the SAP environment is increasingly dominated by issues of geopolitical resilience, legal certainty, and the need to avoid irreversible vendor lock-in. While SAP is exerting enormous pressure on its existing customers to migrate to proprietary cloud structures, the official contract documents still lack a technically and commercially feasible cloud exit strategy.

Cloud and AI Exit

Anyone who has converted their existing on-premises perpetual licenses into cloud subscriptions as part of a contract conversion irrevocably destroys their historical fixed assets. Exiting the SAP Cloud leaves customers with raw data that is worthless without the proprietary cloud algorithms and runtime environments.

The lack of an AI exit strategy is even more dramatic: Since SAP lacks its own core expertise in the field of foundational cognitive models and relies primarily on U.S. pioneers such as Anthropic (with its Claude model), European users are extremely vulnerable to the geopolitical decisions of foreign governments.

In this delicate situation, the European Union’s legal framework—specifically the EU Data Act, published in the Official Journal on December 22, 2023—offers an important glimmer of hope for regaining digital sovereignty. The EU Data Act is intended to facilitate switching between different cloud providers and to legally prohibit artificial barriers to switching, excessive data transfer fees, and restrictive contractual clauses.

Even though the specific EU model contracts and technical implementation regulations for complex ERP landscapes are still being drafted, European legislation is increasingly requiring providers such as SAP to offer open interfaces and standardized data portability mechanisms. This regulatory development is supported by initiatives from European infrastructure providers such as StackIT (the Schwarz Group’s European hyperscaler), which provide Rise workloads in accordance with European law and without the risk posed by the U.S. Cloud Act.

To develop a practical, future-proof cloud exit and decoupling strategy, enterprise users must rely on modern, vendor-neutral architectural standards: Instead of rigidly programming customer-specific algorithms into the proprietary BTP or tying themselves exclusively to the SAP Knowledge Graph, the establishment of a vendor-neutral „Enterprise Semantic Backbone“ is gaining traction.

Using open-source W3C standard formats such as the Resource Description Framework (RDF) and the SPARQL query language, companies can independently model their business-specific ontologies and data relationships on sovereign open-source platforms (such as SUSE Rancher, SUSE AI, or Red Hat OpenShift).

The vendor-neutral Model Context Protocol (MCP) also plays an absolutely key role in the decoupled operation of AI agents. As an open standard—comparable to a universal USB-C port for AI systems—the MCP establishes a clear separation between the language models and the transactional ERP core. Through decoupled MCP servers (such as those provided by vendors like Boomi, SUSE, or open-source communities) allow AI agents to access S/4 data securely, in a controlled manner, and with full auditability, without exposing existing SAP customers to the unpredictable licensing pitfalls of the SAP API Policy.

For the Customer Center of Expertise (CCoE) and the IT leadership of an existing SAP customer, the conclusion of this analysis is: „Take advantage of the technical benefits of the cloud and artificial intelligence where they deliver real business value. At the same time, however, maintain strict control over your system architecture. By consistently streamlining your core systems with SAP Clean Core, optimizing your licenses from an authorization perspective before signing any contract, relying on open-source hybrid cloud foundations such as Red Hat, and decoupling your data structures using open standards like MCP and RDF, you’ll secure a future-proof, agile, and digitally sovereign ERP future on equal footing with the vendor.“