
On 14 November, the EU Commission published a proposal to address competition concerns in maintenance services related to SAP’s Enterprise Resource Planning (“ERP”) business.
This revisits a very long-standing antitrust question. Way back in 2003-5, the prominent battle by Oracle to purchase PeopleSoft went through not only the US federal courts, but the EU Commission (as it now is) as well. That time, Oracle was allowed to consolidate the ERP market, but not before a remarkably heated battle had played out in U.S. v. Oracle.
Now it is SAP’s turn to be in the hot seat, and this time the action is in Brussels. The new case revolves around allegations that there is undue difficulty in switching between maintenance providers. Now that the Commission has published proposed Commitments – essentially a form of settlement – the main question is whether these go far enough to address those concerns.
There is a one-month period to comment on the proposed worldwide settlement.
SAP in the Cloud: How Licensing Shifts Are Reshaping Support and Competition
Over the past decade, SAP has been quietly transforming not just its technology but its entire business model. For many organisations, this change is invisible until renewal or migration time, when familiar perpetual licences and independent support options give way to tightly bundled cloud subscriptions. What was once a market rich with options – multiple deployment models, negotiable support terms, and competing maintenance providers – is becoming increasingly concentrated around SAP itself.
For lawyers advising on technology contracts, outsourcing, or competition issues, this shift raises important questions about control, flexibility, and competition law. Above all: how far should the law intervene to open up the maintenance market for SAP systems?
Modern ERP discussions focus on cloud-based systems. The upfront decision to move to the cloud often de facto loses support choice down the road. For instance, moving HR systems to the cloud-based provider Workday implies using a certified partner with support generally coming from Workday Service Partners for Application Management Services (AMS).
The biggest competition impact of all would be for third party maintenance providers such as Rimini Street and Spinnaker Support to be able to support cloud deployments hosted on the SAP first party cloud. Despite the competitive potential of such a change, the Commission’s investigation appears to have ruled this out of scope by focusing only on on-premises deployments.
It will be interesting to see how that is justified in the eventual public documents. For now, there are just a handful of public documents, and they do not yet explain why the concern is specific to on-premise systems.
The perception seems to be that on-premise consumers lack competition for service, even though no such issue arises in integrated offerings in the cloud. If that is to be the case scope, how does it compare with what is happening in cloud-based services?
From Perpetual Ownership to Subscription Access
Traditionally, SAP sold its software under perpetual licences. Customers paid once for the right to use the product indefinitely, and then paid annual maintenance for updates and support. This structure gave businesses ownership and flexibility: they could decide when to upgrade, whether to buy support from SAP or a third party, and how to host the system.
Now, SAP is steadily replacing this with subscription-based models, most visibly through its flagship “RISE with SAP” offering and S/4 HANA Cloud. Under these deployment models, the customer doesn’t buy the software; they are purchasing access to it, usually hosted in SAP’s own cloud or in a managed “private edition” on infrastructure such as AWS or Azure. The subscription typically bundles the software, infrastructure, updates, and support into a single, SAP-controlled contract.
On the surface, this simplifies things: predictable costs, regular updates, and less infrastructure to manage. But from a legal and commercial perspective, it also narrows the field. The customer no longer “owns” the software or controls the environment. That has significant implications for support, competition, and long-term negotiation leverage.
Where the Software Lives Now
At the time of writing, there are three main deployment models.
On-premise systems still exist, typically at larger or more risk-sensitive organisations. Here, the customer runs SAP on their own servers and retains control of the software. This can be performed in a traditional datacentre deployment or on public-cloud providers like AWS or Azure. In this model, the customer controls and owns the infrastructure.
Private cloud setups, often through RISE “private edition,” are hosted on public-cloud providers like AWS or Azure. In this model, SAP owns and manages the AWS account where RISE with SAP is deployed, and is responsible for the AWS services used to enable the SAP deployment. In this model, SAP controls and owns the infrastructure.
Finally, there is the SAP multi-tenant cloud, where SAP manages the entire platform as a software-as-a-service (SaaS) product.
The shift from the traditional on-premise deployment model to private cloud and SaaS is where competitive dynamics have changed substantially.
Support: Once a Market, now a Monopoly?
In the traditional, on-premise world, customers could buy maintenance directly from SAP or switch to an independent support provider. Companies such as Rimini Street and Spinnaker Support, mentioned above, built businesses offering maintenance, security updates, and compliance help at a lower cost than SAP’s own maintenance fees. They serve as an important competitive check and may well be “more efficient competitors” in competition law terms because their price point is frequently much lower (under half is not uncommon).
The EU Commission’s investigation highlighted several concerns in SAP’s practices:
- All-requirements contracts for on-premise maintenance. Requiring customers to buy all of their maintenance and support needs for SAP on-premise ERP software under similar conditions. Especially for larger systems, this might well prevent moving some of the maintenance business to other providers.
- Sleeping licences can’t get to sleep. Unused licence issues are a typical IT contracting issue, because neither party wants to take all risks to do with growth or contraction of customer needs. SAP is accused of not allowing customers to terminate maintenance and support for unused licences.
- Resetting the Initial Term clock. Adding licences resets an Initial Term which prevents termination of maintenance and support services.
- Reinstatement fees. Coming back to SAP after trying alternatives triggers a reinstatement and back-maintenance fee, perhaps as much as simply staying put in the first place.
How would the Commitments approach these issues, if accepted in their current form?
Commitment 1: Reinstatement fees
SAP would waive the current Reinstatement Fee for a returning customer, and would reduce the Back-Maintenance Payment so that it will be capped at the lower of (1) 50% of the off-support period or (2) six months’ worth of SAP maintenance fees.
Back fees are not unusual – Oracle charges them too – but it is still somewhat remarkable to charge people for a service they have not had. One view would be that the fee should be 0%, not 50%, but that may understate the costs of on-boarding and off-boarding systems.
In practice, few are likely to move back and thereby trigger the fee; that is the point of switching. This is somewhat of a tension in the case – if it is worthwhile to open up switching, that would be because the options are good, but currently blocked. Why then worry about switch-backs? There is a risk that a discount to come back might actually be a form of competition, just with the new vendor; so care is needed here.
Commitment 2: All-requirement contracts
The issue with all-requirements contracts is that they can require very large and complex systems to migrate en masse for switching to occur. The market context of lower prices from rivals would seem to imply that there are difficulties in switching, or it would already take place to harness the lower prices, thereby prompting a match (so-called Bertrand competition).
Less theoretically, there is also the issue that IT leaders live and die by the adage of finding a “single neck to hang” if things go wrong.
Seen in this way, another possibility is that customers value the integration and reliability of the established vendor. That would explain the higher price, but on a pro-consumer basis. There are no easy answers here, and customer views will be pivotal.
The current proposal here is to allow unbundling at the level of a viable system, called a Commercial Installation, and to move them one at a time.
SAP would clarify contracts to allow these so-called “landscape splits” by which requirements for maintenance of the customer’s overall SAP “landscape” of systems can be hived off to different providers.
If approved:
- Customers could split up the systems into Commercial Installations provided that they meet the defined term – that is, a defined system with its own installation number.
- For each Commercial Installation, the customer can then choose to have SAP or others serve requirements – or simply not take maintenance and support at all.
- However, if taking support from SAP, then all licences for that Commercial Installation must be obtained from SAP on an all-or-nothing basis.
It will be interesting to see whether this is seen to be enough. In essence, if approved this would allow customers to break down systems into smaller components provided that the Commercial Installation definition is still met, and then move the maintenance requirements to rivals, or to forego it, on a per-Installation basis.
Significantly, therefore, different SAP Support Models can therefore apply to different Installations so-defined, but tendering must still occur on an Installation-wide basis.
A detailed Annex 2 provides a list of integrated/non-integrated services, to support the definition of Installation. The package confirms that the Initial Term does not restrict system splits. There is a degree of licence price abuse protection for existing system splits and the reallocation of their licences. A major focus of the market testing will be whether those protections suffice.
Commitment 3: Initial term
This simpler provision would simply require that the Initial Term does not restart with each new licence term.
Suppose a business buys 1,000 licences in year 1.
In year 2, it buys 500 more.
At the moment, there is a reset of the Initial Term for maintenance. That is an indicator of weak customer bargaining power, as the marginal users do not usually incur the same risks. Treating them the same as brand new users is something of a stretch and will tend to lock-in systems.
If there are legitimate concerns such as onboarding costs to consider, they might simply feature in the contractual price and not its term.
Commitment 4: Partial termination policies
A series of already-existing SAP partial termination options relating to unused licences will have to be made “more transparent” to customers by distributing information about them via a series of communication channels, to be included in the overall suite of communications about the Commitments in Annex 5.
Commitment 5: Single metric contracts
Few can fully predict how many licences they will need. Negotiation over who is responsible for unused licences is frequent, and it arises with many vendors. Some rule limiting exposure to the customer’s business risks is normal.
There is however scope to abuse the metric if insisting on payment for predictably unusable licences. In such an instance, the predictably unused licence is effectively a price increase.
Consequently, there is a delicate balance to be had here between helpful market allocation of risk, and excessive demands.
The major change here would be a so-called Single Metric Contract, which is one that allows a single metric (e.g., number of employees) to determine the base for the maintenance contract.
The new Single Metric Contract becomes available for contract sizes >EUR 500,000.
In principle, this limits use of the new contracts by smaller customers. They may also face easier switching, because their requirements are smaller. Indeed, for a smaller customer a new SAP contract may very well not be the right answer. Much depends here on whether a customer at the >EUR 500,000 level would save money by switching.
What happens after take-off?
The above fault lines will play out in the coming weeks as the market test occurs. Much of the rest of the package sets out a typical mechanism by which a so-called monitoring trustee administers the use of the Commitments. This is not a trustee in the legal sense of holding property for another, but rather being entrusted with administration.
The term would be ten years, but paragraph 48 contains a mechanism for early release.
Currently, that would only need a “reasoned request” of “material change” before it can be released. Further, there is no need to put this to the market.
A stronger provision would specifically require proof that the issue has been addressed, and would specifically require wider market consultation before release.
Clouds on the horizon?
Cloud subscriptions are changing the picture and in somewhat similar ways, but do not seem to be under close consideration in the EU’s case.
Under SAP’s multi-tenant model for cloud-based systems, customers have no access to the underlying system code or infrastructure. Updates and patches are applied centrally by SAP, on SAP’s schedule. Third parties cannot intervene because they have no technical or contractual ability to alter the system. In effect, SAP becomes both the vendor and the sole maintainer.
If the concern about on-premise systems was a form of functional monopoly over support, then the same might yet arise for the cloud-based systems if similar terms come to be applied.
From a competition law perspective, this has echoes of familiar concerns. Bundling can be a helpful strategy where it reflects customer demand. It often lowers costs and allows efficient margin control. But bundling software, hosting, and support together without an unbundled option could well also foreclose competition in downstream maintenance services in the same way perceived in the on-premises market.
Independent support providers argue that this “vendor lock-in loop” removes the customer’s freedom to choose and inflates prices. While it is always challenging to increase case scope once Commitments are in play, those with evidence of cloud-based concerns may yet wish to make their views known.
Moreover, those who want to be offered unbundled service will be able to point to the Commitments as a proof of concept that system-wide competition restrictions carry risks.
Why This Matters
These developments are not just technical; they reshape risk and negotiating power across several dimensions.
Contractually, cloud subscriptions reduce flexibility. Terms are often standardised, renewals automatic, and exit options limited. Customers must pay close attention to data retention, transition assistance, and the right to retrieve or archive data after termination.
From a competition and regulatory standpoint, the consolidation of support within SAP’s own ecosystem has invited scrutiny under abuse-of-dominance principles. There are risks from effectively excluding competing providers from bringing benefits to end users.
Commercially, the rhythm of costs and control changes. Under perpetual licensing, customers could defer upgrades or seek cheaper support. Under subscriptions, both the pace of innovation and the cost of maintenance are set by SAP. Customers gain simplicity but lose autonomy.
Looking Ahead
SAP’s strategy mirrors a broader industry trend; major enterprise software providers are migrating to subscription-based cloud ecosystems where they control the entire lifecycle of service. The model offers efficiency and predictable revenues – but at the cost of the range of unbundled supply.
For now, third-party support exists mainly for organisations running SAP on-premise or in a self-managed private cloud. As more companies migrate to SAP’s cloud under RISE, that competitive pressure will fade; so in a sense, the Commitments risk fighting the last war. Increasingly, customers are being pushed to private cloud and SaaS options.
However, as long as perpetual licensing is sold by SAP and on-premise hosting is an option, there is an element of possible switching.
But if demand moves principally onto the cloud, then the competitive pressure from the on-premises switching diminishes. In that scenario, the Commitments would not offer customers any direct switching support: the Commitments do not directly address cloud-based deployments, and that would be so even though any competition from the on-premise market would then be less vibrant.
The shift to the cloud is not just a technical evolution but a structural one. It merges what were once separate markets (software, hosting, and support) into a single, vendor-controlled bundle. That has direct implications for contract design, procurement strategy, and potentially for regulatory oversight.
Han-Ley Tang, Managing Director, Trinity Advisors
Stephen Dnes, Founding Partner, Dnes & Felver PLLC
14 November 2025





