They Count What Is Possible

License management for SAP and Oracle: why both vendors count potential rather than use, where the rules that matter actually live, and what you need to settle before a cloud migration

Executive Summary

Strategic Context

Situation. SAP and Oracle customers are running into several deadlines at once. SAP ends mainstream maintenance for Business Suite 7 at the end of 2027 and offers extended maintenance until the end of 2030 at a premium. Oracle’s rules for licensing in the public cloud carry a date of 4 September 2026. Both vendors are pushing their installed base toward subscriptions.

Complication. Whoever migrates takes their license estate along, and most organizations do not know it. Licensing expert Richard Spithoven of SoftwareOne put it in one sentence in an interview with Techzine: “People don’t know what they don’t know.” There is a second finding that rarely gets said out loud: in many places, the metrics of both vendors do not count what you use, but what you could use. And the rules that govern the count often are not in the contract.

Question. Where does license exposure with SAP and Oracle actually arise, and what does an organization need to know before it renews, migrates or enters an audit?

Key Findings

1. At decisive points, both vendors count potential, not use. Oracle licenses Java SE by employee count, explicitly “not just the actual number of employees that use the Programs”. A Fusion user counts “regardless of whether the individual is actively accessing the hosted service”. An Oracle database on VMware is sized by physical capacity, because Oracle classifies VMware as soft partitioning. SAP measures every system and classifies every user created on it. So what? A usage report alone does not answer the licensing question. You also need a picture of where the software is installed, who could theoretically access it and on which hardware it could run.

2. The rule that governs the count often sits next to the contract. Oracle’s Partitioning Policy, its Database Licensing document and its cloud licensing rules all carry the same language: “for educational purposes only”, “may not be incorporated into any contract”, “subject to change without notice”. Yet in practice these are the documents that determine how many licenses Oracle asks for. So what? Archive the versions in force when you sign, and negotiate the points that matter for your architecture (virtualization, cloud, containers) into the contract. A policy the vendor can change at any time is not a planning basis.

3. Support is a bigger lever than the license purchase. In Oracle’s current Technology price list, annual database support is 22 percent of the license price, and the renewal rises every year by an inflationary adjustment whose rate Oracle does not publish. Dropping individual licenses from a license set is not permitted, and a partial termination triggers repricing of the rest. At SAP, extended maintenance until 2030 costs an additional two percentage points on the maintenance basis. So what? Shelfware mainly costs you support, every year. Getting rid of it means knowing the license sets and orders it sits in and modeling the termination rules first.

4. The cloud changes the counting method, not the exposure. In AWS, Azure and Google Cloud, Oracle’s core factor table does not apply. Two vCPUs with multithreading equal one Processor license. By our own calculation from both Oracle documents, that doubles the license requirement compared with the same x86 core count on premises. At SAP, converting on-premise licenses to cloud subscriptions requires, according to SAP material, a license audit no more than six months old. So what? Migration is not an escape from measurement. It is the occasion for it. Calculate the license requirement of the target architecture before you fix instance sizes.

5. Interfaces are license objects. In SAP v Diageo, SAP claimed around 54.5 million pounds in license and maintenance fees because Diageo’s customers, through an ordering portal, and Diageo’s field sales, through a separate sales application, accessed SAP ERP indirectly via SAP PI. The court sided with SAP on liability. SAP’s response in 2018 was the Digital Access model, which counts nine types of created documents. So what? Every integration that creates documents in SAP belongs in the license inventory. If you do not know your interfaces, you can neither assess Digital Access nor judge an audit.

Critical Recommendations

Conclusion

License management for SAP and Oracle is not a counting exercise but a translation job: you translate your architecture into the vendor’s metrics before the vendor does. Measuring only what is used misses the metrics. Not freezing the rules means negotiating against a moving target. And migrating without knowing your estate carries the uncertainty into a contract under which the vendor sees usage continuously.

Where the Debate Stands

In February 2026, Techzine spoke with Richard Spithoven of SoftwareOne, and the interview sums up the situation well. His example of shelfware: “A company that purchased 100 ERP software modules 10 years ago may now only use 40 of them.” Support is still paid on all hundred. On the consequences, he says claims sometimes run into the hundreds of millions, and the largest he has seen amounted to 1.2 billion euros. The article leaves open what exactly that figure refers to. Such cases rarely become public because companies see them as an “admission of failure”.

The article also describes what changes with the cloud. With Oracle Fusion, the customer receives annual reports from a Customer Success Manager on module access, and an expected renewal of 2.3 million euros becomes 4.2 million. For RISE with SAP: “There, too, a CSM regularly generates reports to see who has access to which functionality.” And for migration projects in general: “In almost all projects where customers move away from on-premise ERP, I see that the costs ultimately go through the roof.”

This piece does not adopt two statements from the article as fact. The first is that Oracle increased support costs “from 4 to 8 percent”, with a rise to 10 percent expected in June 2026. Techzine gives no source, and Oracle’s own documents describe the mechanism of the annual adjustment but no rate (see Finding 3). The second is that SAP audits every year. SAP itself speaks of a contractual right to verify usage “at regular intervals”. Both may hold in practice. Neither is supported by the documents read for this piece.

One observation about the sources belongs here. The problem is old. As early as 2014, a Flexera manager called indirect access “the elephant in the room” of SAP licensing in a conversation with itassetmanagement.net, and the same source already described Oracle treating VMware as soft partitioning. Twelve years later, neither issue has gone away. Both have been translated into new models.

Finding 1: They Count Potential, Not Use

The intuitive question in license management is: how much do we use? At many points, the metrics of both vendors ask a different question: how much could you use? The overview below collects the places where the vendors say so in their own words.

Java is the clearest case. Oracle replaced the legacy Java SE subscriptions with the Universal Subscription on 23 January 2023. Since then, the price has been tied not to installations or users but to the workforce. The definition covers “all of Your full-time, part-time, temporary employees” plus the corresponding staff of “agents, contractors, outsourcers, and consultants that support Your internal business operations”. Oracle’s own example in the price list: 28,000 employees, 5,000 of them at service providers, come to 2,268,000 US dollars a year. Pricing starts at 15 US dollars per employee per month. A company running Java on twenty servers no longer counts servers, it counts heads.

The Kubernetes case follows the same logic, only more technical. What counts is not the running container but the node the image was pulled to. An autoscaling cluster can thus create license requirements on nodes where the database never ran in production.

SAP is not fundamentally different here. Measurement is per system, and classifying users is the customer’s job before every measurement. The License Administration Workbench then consolidates a person’s users across systems and assigns “one contractual user type”. If users are not classified properly, the measurement result effectively decides the assignment.

There is an important exception, and it shows that it can be done differently. SAP’s Digital Access counts only documents that were actually created. Read, update and delete are explicitly not counted. And under RISE with SAP, Full Usage Equivalents can be reallocated between use types, according to SAP material explicitly “to avoid shelf-ware during their life-cycle”. These are models closer to actual use. They apply only where your contract has them. With Joule Agents, SAP is taking this path further and charging per action, with its own pitfalls for the business case (see SAP Now Prices the Action, Not the User).

The decision that follows. Build your license inventory in three layers: installed (where the software sits), entitled (who could access it) and used (who does access it). Only with all three can you say which metric actually hits you.

Finding 2: The Rule Sits Next to the Contract

Oracle’s license agreement defines the Processor. How that definition applies to virtualization, cloud and containers is governed by three documents Oracle publishes on its website. All three contain essentially the same caveat. The Partitioning Policy puts it this way:

“This document is for educational purposes only and provides guidelines regarding Oracle’s policies in effect as of February 14, 2022. It may not be incorporated into any contract and does not constitute a contract or a commitment to any specific terms. Policies and this document are subject to change without notice.”

The cloud licensing document carries the same caveat, with “policies in effect as of September 4, 2026”. The core factor table is marked “Updated: Jan 28, 2026”. The Partitioning Policy describes itself as a way “to license a sub-capacity of total physical cores as an exception from the contractual Oracle Processor definition”. The policy is an exception Oracle grants, not a commitment you can rely on.

That creates an asymmetry. The documents Oracle calculates by in an audit are not enforceable by the customer, and they change. The cloud rules carry a date from September this year. The document does not show what changed from the previous version.

At SAP, the equivalent sits in the price and conditions list that measurement explicitly refers to: users are to be classified “in accordance with the current use and the underlying price list”. Here too, a document outside the license agreement itself decides which user type covers which activity.

The decision that follows. With every contract, file the versions of these documents in force at the time, with their dates. And negotiate the points that affect your architecture into the order: which virtualization is accepted as hard partitioning, which cloud conversion applies, how containers are counted. What is in the order applies. What is in the policy applies until Oracle changes it.

Finding 3: Support Is the Bigger Lever

Oracle’s Technology Global Price List dated 15 September 2026 lists Database Enterprise Edition at 47,500 US dollars per Processor license and 10,450 US dollars for “Software Update License & Support”. For Standard Edition 2 it is 17,500 and 3,850 US dollars. In all four columns, support equals exactly 22 percent of the license price. The price list does not state that percentage in words. It follows from the figures.

More important than the starting point is how it rolls forward. The price list says: “The price of a technical support renewal for Software Update License & Support is the technical support fees paid for the same licenses in the prior year, increased by the Inflationary Adjustment Rate (IAR).” Where a contractual cap exists, the lower value applies. Oracle publishes the rate neither in the price list nor in the support policies. The figures circulating in the market come from consultants. In 2022, The Register reported 8 percent in the US, citing two licensing advisory firms. Oracle declined to comment. Techzine’s “10 percent from June 2026” has no source.

The real trap sits in Oracle’s Software Technical Support Policies (effective 17 August 2026). Two rules stop you from simply taking shelfware off support:

• Matching service levels. “You may not support a subset of licenses within a license set; the license set must be reduced by terminating any unsupported licenses.” If you no longer want support for part of a set, you must terminate the licenses.
• Repricing. If part of the licenses on an order are terminated, support for the rest is recalculated at the current list price minus the standard discount. It will not exceed the previous fee for both parts combined, but it also cannot fall below what was previously paid for the remaining licenses. If you got a steep discount at purchase, termination often saves far less than expected.

If you let support lapse and want to return later, the same policies set a reinstatement fee of 150 percent of the last annual fee paid.

At SAP, the lever is the calendar. SAP states: “SAP will provide mainstream maintenance until end of 2027 for SAP Business Suite 7 core applications.” Extended maintenance follows: “This comes with a premium of two percent points on the maintenance basis for all support offerings for the scope of SAP Business Suite 7. It will be available for three years from beginning of 2028 until end of 2030.” Customers who do not take it fall into customer-specific maintenance, whose scope SAP does not describe further on that page.

For 2031 to 2033, SAP announced the “SAP ERP, private edition, transition option” in August 2025, described as “a time-bound subscription offering designed to provide business continuity from 2031 to 2033”. This is not an extension of maintenance under the existing contract. Prerequisites according to SAP: systems must be migrated to SAP ERP, private edition on SAP HANA “before December 31, 2030”, the option is “only available in combination with the max success plan”, a 2 TB minimum applies, and the price is “at an uplift compared to the SAP ERP, private edition pricing valid end of 2030”. Final pricing is to be communicated only in 2028.

The decision that follows. Assess shelfware not by license value but by support stream, and break it down by order and license set. Run every partial termination through Oracle’s repricing rule before you announce it. And treat 2030 as a hard line at SAP: if you want to run ECC beyond it, you need a HANA-based private edition environment by then, at a price SAP will only name in 2028.

Finding 4: The Cloud Changes the Counting, Not the Exposure

Oracle permits its software in three “Authorized Cloud Environments”: AWS (EC2 and RDS), Microsoft Azure and Google Cloud Platform. Separate rules apply there:

• “count two vCPUs as equivalent to one Oracle Processor license if multi-threading of processor cores is enabled, and one vCPU as equivalent to one Oracle Processor license if multi-threading of processor cores is not enabled.”
• “When counting Oracle Processor license requirements in Authorized Cloud Environments, the Oracle Processor Core Factor Table is not applicable.”

On premises, current Intel Xeon and AMD EPYC processors carry a core factor of 0.5. A server with four physical cores therefore needs two Processor licenses. With multithreading enabled, the same four cores correspond to eight vCPUs in the cloud, and under the cloud rule that is four licenses. This calculation is our own derivation from the two Oracle documents, not an Oracle statement, and it assumes each vCPU is one hardware thread, as the multithreading rule implies. It does show the order of magnitude: for the same compute, the license requirement can double. Oracle’s own cloud converts more favorably. According to the core factor table, one Processor license covers two OCPUs on x86.

Standard Edition 2 also has its own cloud limits: only on instances of up to eight vCPUs, with every four vCPUs counting as one socket. And licenses from an Unlimited License Agreement may be used in these clouds, but “customers may not include those licenses in the certification at the end of the ULA term”. If you are maximizing your ULA to certify as many licenses as possible at the end while migrating to the public cloud in parallel, you are working against yourself.

SAP’s cloud side is friendlier by design, but not without conditions. SAP’s RISE material (March 2021) describes the Full Usage Equivalents metric with weightings: an advanced use user counts one FUE, core use one fifth, self-service use one thirtieth. SAP’s example: 40 advanced, 75 core and 270 self-service users make 64 FUE. The minimum for RISE with SAP S/4HANA Cloud, private edition was 40 FUE. Whether these factors still apply unchanged in today’s contracts has not been verified.

For converting existing licenses, the same SAP material lists four conditions under the Cloud Extension Policy that you should know before migrating: new cloud subscriptions must be signed, the term is three or five years, on-premise use rights and maintenance end on the termination date (“please make sure that you allow for enough time for the transition”), and: “License audit current (6 months old at the most)”. Conversion requires a current measurement.

The decision that follows. Calculate the license requirement of the target architecture before fixing instance sizes, using the vendor’s cloud rules, not the on-premise rules. At SAP, plan the measurement as part of the migration plan, not as a risk alongside it. Its result is the basis of your conversion negotiation.

Finding 5: Interfaces Are License Objects

SAP UK v Diageo ([2017] EWHC 189 (TCC)) concerned two applications: the Connect portal, through which Diageo’s customers and distributors placed orders themselves, and the Gen2 field application used by Diageo’s sales representatives. Both accessed SAP ERP via SAP PI. SAP claimed 54,503,578 pounds in additional license and maintenance fees. The court found that users were “accessing or using mySAP ERP indirectly through SAP PI” and left the amount to a separate quantum phase, to be assessed “by reference to the nature and extent of the usage and SAP’s price list”. The 54.5 million is the claim, not the award. No source on the final amount was read for this piece.

How unclear the situation was at the time is shown by a statement from the German-speaking SAP user group DSAG in May 2017. Board member Andreas Oczko told Computerwoche that SAP had no clear definition or rule on indirect use.

In April 2018, SAP introduced the Digital Access model. It counts nine types of system-generated documents: sales, invoice, purchase, service and maintenance, manufacturing, quality management, time management, financial and material documents. Sales, invoice, purchase, financial and material documents are counted at line item level, financial and material documents with a factor of 0.2. What counts is the initially created document. “read, update, or delete documents are not counted”.

For the transition, SAP offered the Digital Access Adoption Program. In the April 2020 version, customers had two options: license at least 115 percent of estimated document volume and pay only for the growth, or license at least 100 percent and receive a 90 percent discount on Digital Access. The program then ran until the end of 2021, and SAP wrote: “Program is unlikely to be extended again”. A licensing advisor later reported an indefinite extension. No current SAP source on its 2026 status was available for this piece. If you want to use it, get the status confirmed by SAP in writing.

The decision that follows. Build an interface inventory that answers three questions for every integration: does it create documents in SAP, which of the nine types, and in what volume? With that list you can assess Digital Access before SAP does in an audit. SAP itself offers a “Digital Access Evaluation Service” that helps with “estimating the number of documents relevant to the SAP Digital Access licensing model”.

What Tools Can and Cannot Do

There are specialized software asset management tools for SAP and Oracle. A current comparison site (StatWharf, September 2026) lists ten vendors for SAP, from SAP-native tools through specialists to broad SAM platforms. The site itself notes that it relies on public product documentation without hands-on testing and that “vendors may pay for inclusion or placement”. This piece therefore does not adopt the vendor savings claims quoted there.

Three categories can still be distinguished:

• Vendor tools. SAP’s License Administration Workbench consolidates measurement results across systems and serves the audit process. It reports. It does not optimize.
• Specialized optimizers. They analyze actual usage behavior and suggest cheaper user types. Their value depends on how well they model your contract and your price list.
• Broad SAM platforms. They consolidate inventory across many vendors and are strong on installation data, which is exactly the first layer from Finding 1.

No tool reads your contract. All the findings above depend on which version of a policy applies, which special terms are in the order and which license sets exist. A tool delivers the quantities. Translating them into license requirements remains contract work.

What This Means for Leadership

License exposure is architecture exposure. Whether Oracle runs on VMware, whether a Kubernetes cluster autoscales and which integration creates documents in SAP are architecture decisions. IT makes them and procurement pays for them. When the two do not talk, the exposure arises right between them.

Migration is the most expensive moment for not knowing. SAP requires a current measurement for conversion, Oracle counts differently in the cloud than in the data center, and both vendors see usage continuously in the cloud. If you do not know what you have beforehand, you negotiate afterwards on the vendor’s numbers.

Support is a budget that rolls itself forward. It rises every year without anyone deciding anything. Reducing it, on the other hand, takes decisions whose consequences sit in rules few people read.

Leadership Overview

Frequently Asked Questions

Appendix: Methodology

Type of study. Primary document analysis of SAP and Oracle license, price and support documents, supplemented by three secondary sources specified by the commissioning party.

Frameworks applied. SCQA for framing, and a comparison of both vendors’ metric definitions against the question of whether they count installation, entitlement or use. Porter, BCG matrix, PESTEL and value chain were considered and rejected because they answer industry and portfolio questions, not licensing mechanics.

Sources and quality. All statements about SAP and Oracle rules rest on vendor documents retrieved directly on 28 September 2026. oracle.com partly answers automated requests with HTTP 403, so the PDFs were downloaded directly and read in full.

Own derivations. The 22 percent support ratio is calculated from the Oracle price list figures. The doubling of license requirements in the public cloud is derived from the core factor table and the cloud licensing rules. Both are marked as own calculations in the text.

Limitations.

1. The SAP RISE material (FUE factors, Cloud Extension Policy) dates from March 2021. Current contract terms may differ.
2. The Diageo judgment was read via a third-party rendering because the original on bailii blocks automated retrieval.
3. Oracle’s audit clause comes from publicly available OLSA templates, not a current Oracle Master Agreement.
4. The 2026 status of the Digital Access Adoption Program is not confirmed by SAP sources.
5. Oracle’s Database Licensing document is dated August 2019.

Figures deliberately not used. The support increases “4 to 8 to 10 percent” (Techzine, unsourced), conversion credits for the SAP Cloud Extension Policy circulating on consultant blogs, SAM vendor savings claims from a comparison site with paid placement, and a percentage surcharge for SAP extended maintenance that does not appear on SAP’s page (which states two percentage points on the maintenance basis).

Sources

1. Berry Zwets: Oracle and SAP license chaos: Understand what you have before you migrate. Techzine, 25 February 2026. https://www.techzine.eu/blogs/applications/139071/oracle-and-sap-license-chaos-understand-what-you-have-before-you-migrate/
2. David Foxen: SAP Licensing, is there an elephant in the room? itassetmanagement.net, 13 June 2014. https://itassetmanagement.net/2014/06/13/sap-licensing-elephant-room/
3. StatWharf Editorial: SAP License Management Software. September 2026. https://statwharf.com/best/sap-license-management-software/
4. SAP Support: Maintenance 2040. https://support.sap.com/en/release-upgrade-maintenance/maintenance-information/maintenance-strategy/s4hana-business-suite7.html
5. Stefan Steinle: Navigating Your RISE with SAP Journey: Updates for SAP ERP, Private Edition, Transition Option. SAP News, 4 August 2025. https://news.sap.com/2025/08/rise-with-sap-journey-sap-erp-private-edition-transition-option-updates/
6. SAP: SAP Digital Access / SAP Digital Access Adoption Program (DAAP). April 2020. https://news.sap.com/wp-content/blogs.dir/1/files/DAAP_External_FV_050520.pdf
7. SAP SE: RISE with SAP S/4HANA Cloud, Licensing Overview. March 2021. https://assets.dm.ux.sap.com/webinars/sap-user-groups-k4u/pdfs/210316_rise_with_sap_s4hana_cloud_license_overview.pdf
8. SAP Help: Process of System Measurement. https://help.sap.com/doc/saphelp_nw73ehp1/7.31.19/en-US/48/c6eb7b7a004da5e10000000a421937/content.htm
9. SAP Help: License Administration Workbench. https://help.sap.com/doc/saphelp_nw75/7.5.5/en-US/48/c6e74b7a004da5e10000000a421937/content.htm
10. SAP Support: SAP Global Adoption & Experience CoE. https://support.sap.com/en/my-support/systems-installations/glac.html
11. SAP (UK) Ltd v Diageo Great Britain Ltd [2017] EWHC 189 (TCC), rendering by getcaselaw. https://www.getcaselaw.com/case-library/f27ab4ab-6afd-496a-bb72-6fb428fc2aa7
12. Computerwoche: SAP will indirekte Nutzung klären und scheitert. 26 May 2017. https://www.computerwoche.de/article/2758821/sap-will-indirekte-nutzung-klaeren-und-scheitert.html
13. Oracle: Partitioning Policy, as of 14 February 2022. https://www.oracle.com/us/corporate/pricing/partitioning-070609.pdf
14. Oracle: Processor Core Factor Table, updated 28 January 2026. https://www.oracle.com/contracts/docs/processor-core-factor-table-070634.pdf
15. Oracle: Database Licensing, as of 6 August 2019. https://www.oracle.com/a/ocom/docs/database-licensing-070584.pdf
16. Oracle: Licensing Oracle Software in the Cloud Computing Environment, as of 4 September 2026. https://www.oracle.com/a/ocom/docs/cloud-licensing-070579.pdf
17. Oracle: Java SE Universal Subscription Global Price List, 1 March 2023. https://www.oracle.com/a/ocom/docs/corporate/pricing/java-se-subscription-pricelist-5028356.pdf
18. Oracle: Java SE Universal Subscription FAQ. https://www.oracle.com/java/technologies/java-se-subscription-faq.html
19. Oracle: Technology Global Price List, 15 September 2026. https://www.oracle.com/us/corporate/pricing/technology-price-list-070617.pdf
20. Oracle: Software Technical Support Policies, effective 17 August 2026. https://www.oracle.com/contracts/docs/057419.pdf
21. Oracle: Fusion Cloud Service Descriptions, effective 10 September 2026. https://www.oracle.com/contracts/docs/oracle-fusion-cloud-service-desc-1843611.pdf
22. Oracle: License and Services Agreement (public template, Oracle EMEA). https://www.oracle.com/us/corporate/pricing/olsa-ire-v122304-070683.pdf
23. Lindsay Clark: Oracle to hike support fees in line with inflation. The Register, 25 July 2022. https://www.theregister.com/2022/07/25/oracle_set_to_impose_inflationary

All sources retrieved on 28 September 2026.