Most enterprises hold both: legacy orders signed under an Oracle OLSA and newer orders signed under an Oracle Master Agreement. The two master agreements govern audit rights, support, virtualization, and entity scope differently — and Oracle quietly benefits when customers let a favorable OLSA collapse into a current OMA at renewal. Former Oracle insiders explain exactly what changed.
Short answer: The Oracle OLSA (Oracle License and Services Agreement) was Oracle's master contract until roughly 2014, when the Oracle Master Agreement (OMA) replaced it. The OMA added explicit cloud terms and broader policy-incorporation language. Crucially, signing an OMA does not retroactively replace an existing OLSA — each Oracle order is governed by whichever master agreement it was placed under.
An OLSA (Oracle License and Services Agreement) is the master contract Oracle used through roughly 2014 to set the general terms governing every license and service a customer bought. Like the agreement that succeeded it, the OLSA itself did not specify products or prices — those lived in separate Ordering Documents that incorporated the OLSA by reference.
The OLSA established the legal architecture Oracle still uses today: a master layer of general terms (license grant, restrictions, audit rights, support, warranty, liability) sitting above transaction-level Ordering Documents. When you bought Oracle Database Enterprise Edition in 2011, the perpetual license grant and the rules around it came from your OLSA; the Ordering Document only recorded the quantity, metric, and price.
Because the OLSA predates Oracle's most aggressive policy-incorporation language, many OLSA-era estates have stronger footing in disputes over soft partitioning, VMware, and BYOL — areas where Oracle later leaned heavily on non-contractual policy documents. That is precisely why Oracle prefers to migrate OLSA customers onto a current agreement. Our Oracle compliance review service starts by locating which master agreement actually governs each order.
The Oracle Master Agreement (OMA) is Oracle's current master contract, introduced around 2014 to replace the OLSA for new customers. It performs the same structural job — setting general terms above Ordering Documents — but modernizes the language around cloud services, subscription products, and incorporated licensing policies.
The OMA also restructured how support and services attach to license orders, and tightened the definitions section that drives audit exposure. As covered in our Oracle Master Agreement guide, the standard OMA is drafted to maximize Oracle's position in every foreseeable dispute: broad audit rights, auto-renewing support, and open-ended scope for license metrics.
The single most consequential change is the OMA's explicit incorporation of Oracle's licensing policies by reference. These policy documents — the Partitioning Policy, the Oracle PaaS/IaaS Cloud Licensing Policy, the Processor Core Factor Table — are not negotiated contract text, yet the OMA treats them as governing. That gives Oracle a mechanism to change the effective rules of your deployment without ever amending the signed agreement.
Oracle transitioned from the OLSA to the OMA around 2013–2014, with an intermediate agreement — the OSSA (Oracle Software and Services Agreement) — used during the handover. An OSSA (Oracle Software and Services Agreement) is the transitional master contract that sits functionally between the OLSA and the OMA, governing the orders placed under it.
The practical consequence is that a large, long-tenured Oracle customer frequently holds three generations of master agreement at once. Orders from 2008 may run under an OLSA, orders from 2013 under an OSSA, and orders from 2018 onward under an OMA — each with subtly different audit, support, and policy terms.
Across our engagements, roughly 30% of enterprises with 15+ years of Oracle history hold at least two different master-agreement generations and cannot produce a complete copy of all of them (Oracle Licensing Experts benchmark, 2026). That documentation gap is the first thing Oracle's LMS team exploits in an audit.
If you do not know which agreement governs which order, you are negotiating and defending audits blind. The starting point of any serious Oracle position is a complete inventory of your master agreements and the Ordering Documents that reference them.
The two master agreements share the same skeleton but differ in the clauses that determine your real-world risk. The table below summarizes where they diverge most. Treat it as a starting map — the exact wording in your specific OLSA or OMA always controls.
| Clause area | OLSA (legacy, pre-2014) | OMA (current) |
|---|---|---|
| Era in use | Through ~2013–2014 | ~2014 to present |
| Structure | Master terms + Ordering Documents | Master terms + Ordering Documents (same model) |
| Policy incorporation | Fewer / earlier policy references; weaker hooks for partitioning & cloud | Explicitly incorporates current Oracle licensing policies by reference |
| Cloud / BYOL terms | Largely silent (predates OCI & authorized-cloud rules) | Modernized cloud, subscription, and BYOL language |
| Support schedule | 22% maintenance, auto-renewal | 22% maintenance, auto-renewal, restructured services terms |
| Audit rights | Broad, but often narrower policy backing | Broad, reinforced by incorporated policy documents |
| Retroactive effect | Governs the orders signed under it | Does NOT retroactively replace an existing OLSA |
The decisive row is the last one. Because the OMA does not reach back to govern OLSA-era orders, a customer who negotiated favorable virtualization or assignment terms in a 2010 OLSA keeps those terms — unless they sign a new agreement that expressly supersedes the OLSA for those orders. Oracle's account teams know this, which is why "agreement consolidation" is a recurring renewal theme.
Our Oracle license optimization service inventories every master agreement and Ordering Document in your estate, so you know exactly which terms apply before Oracle does.
No. Signing an Oracle Master Agreement does not automatically replace an OLSA you already hold. Each Oracle order remains governed by the master agreement that was in force when that order was signed. The OMA applies to new orders placed under it — not to historical orders bought under an OLSA or OSSA.
This is the single most misunderstood point in Oracle contracting, and it costs customers real money. When Oracle proposes a new OMA at a renewal or a cloud deal, the document frequently contains an "entire agreement" or "supersession" clause. If that clause is broad enough — and if you sign it without scoping — it can expressly replace your legacy OLSA terms for products you bought years ago, handing Oracle the modern policy-incorporation language it lacked before.
The protection is narrow drafting. Where consolidation is genuinely necessary, the new OMA should carve out and preserve the specific favorable OLSA terms — virtualization treatment, assignment rights, support caps — rather than blanket-superseding everything. Our Oracle contract negotiation team treats supersession language as a red-line item in every consolidation deal.
Neither agreement is uniformly better — it depends entirely on the negotiated terms in your specific copy. A legacy OLSA can be more favorable because it predates Oracle's partitioning and cloud policy hooks, leaving more room to dispute VMware and BYOL positions. But some OLSAs also lack protections that later customers negotiated into their OMAs.
The honest answer is that "better" is a clause-by-clause question, not a generational one. What matters is which agreement gives you the stronger position on the issues that actually affect your estate: audit frequency, look-back caps, support escalation, entity scope, and virtualization treatment. A customer running heavily virtualized Oracle Database workloads usually benefits from a pre-policy OLSA; a customer pushing aggressively into OCI usually wants the OMA's explicit BYOL language.
This is also why the "should I consolidate?" decision can never be made on Oracle's recommendation alone. Oracle proposes consolidation when it improves Oracle's position. For a worked example of how preserved legacy terms changed an outcome, see our Oracle licensing case studies, where retaining OLSA virtualization terms removed millions from a compliance claim.
The consolidation trap is Oracle's practice of bundling an agreement migration into a renewal or cloud transaction so that signing the commercial deal also quietly replaces your favorable legacy terms. The new paper looks like a routine renewal; embedded in it is a master agreement that supersedes your OLSA and pulls every historical order under current policy.
Oracle frames consolidation as administrative tidiness — "let's get everything onto one current agreement." In reality it is one of the highest-leverage moves Oracle makes, because it can convert a defensible virtualization position into an indefensible one without a single new license being discussed. Enterprises rarely notice, because the change is in the master terms, not the price.
Handled deliberately, consolidation can even be turned to the customer's advantage. The point is never to let it happen by default. For the broader framework, our Oracle Database licensing guide covers how master-agreement terms flow down into database deployment risk.
Before you sign, have an independent team compare your legacy OLSA against Oracle's proposed OMA — clause by clause. We identify exactly what you would lose and negotiate to keep it.
The OLSA (Oracle License and Services Agreement) was Oracle's master contract until around 2014, when the Oracle Master Agreement (OMA) replaced it. Both set general terms for all Oracle orders, but the OMA introduced clearer cloud and policy-incorporation language and a restructured support schedule. Critically, if you signed under an OLSA, the OLSA still governs every order placed under it — the OMA does not retroactively replace it.
No. The OMA does not automatically replace an OLSA you already signed. Each Oracle order is governed by whichever master agreement it was placed under. Many enterprises hold a mix: legacy orders under an OLSA and newer orders under an OMA. Oracle often tries to migrate customers onto a single current OMA during a renewal — which can quietly change audit, support, and policy terms in Oracle's favor.
Yes. An OLSA remains fully valid and enforceable for the orders signed under it, even though Oracle no longer issues new OLSAs. Perpetual licenses bought under an OLSA continue under that agreement's terms indefinitely. The OLSA only stops applying if you sign a new master agreement that expressly supersedes it for those specific orders.
The OSSA (Oracle Software and Services Agreement) was a transitional master agreement Oracle used between the OLSA era and the OMA. Functionally it sits between the two. Like the OLSA, it governs the orders placed under it and is not retroactively replaced by the OMA. If your estate spans 15+ years of Oracle purchases, you may hold OLSA, OSSA, and OMA orders simultaneously.
The OMA more explicitly incorporates Oracle's non-contractual licensing policies — such as the Partitioning Policy and Cloud Licensing Policy — by reference, giving Oracle a mechanism to change effective rules without amending the signed contract. Many older OLSAs reference fewer or earlier policy documents, which can leave more room to dispute Oracle's virtualization and soft-partitioning positions.
Only after a clause-by-clause comparison. Consolidation benefits Oracle by default because it pulls historical orders under current policy language. It can benefit the customer too, but only when favorable legacy terms are carved out and preserved and Oracle pays for the consolidation in concessions. Never accept blanket supersession language without independent review.
Master-agreement analysis, support pricing benchmarks, and negotiation tactics — for Oracle stakeholders at 2,000+ enterprises globally.
Written by the Oracle Licensing Experts Team — former Oracle executives, LMS auditors, and contract managers with 25+ years of combined Oracle licensing experience. Not affiliated with Oracle Corporation. All advisory is independent and 100% buyer-side.