Buyers search MOSA and MCA; Oracle’s paper says OMA and CSA. A reference to what each master governs, the ordering mechanics beneath them, and where the negotiable clauses live.
Oracle does not sell under a MOSA or an MCA: those acronyms belong to Microsoft’s stack. Oracle’s masters are the Oracle Master Agreement for licenses, hardware, support, and services, and the Cloud Services Agreement for cloud. This reference maps what each governs, how orders attach, and where every clause lives.
This reference is for legal, procurement, and SAM leaders untangling Oracle paper in 2026. Read it alongside the cloud licensing policy guide and the Oracle Practice page so the contract stack and the licensing rules line up.
The two standing vehicles are the Oracle Master Agreement and the Cloud Services Agreement, both published in Oracle’s contracts library. MOSA and MCA are Microsoft’s names: the Microsoft Online Subscription Agreement and the Microsoft Customer Agreement.
The confusion is understandable and common. Procurement teams that renegotiated Microsoft paper recently carry the vocabulary into Oracle files, and the two stacks rhyme: one vehicle skews license, one skews cloud, and orders attach beneath each.
Both masters exist in a published transactional form, accepted online for a single purchase, and a negotiated enterprise form signed for a term of years. The published versions are the floor Oracle starts from; the negotiated versions are where enterprise terms actually move.
Almost always the OMA: the master that governs on premises program licenses, hardware, technical support, and professional services. Every traditional license purchase becomes an ordering document under it, and Oracle offers it in a transactional form and a five year form covering multiple purchases.
The cloud master: the CSA, or on newer accounts the cloud schedule of an OMA. It governs OCI consumption, Fusion SaaS subscriptions, Universal Credits, and the service level, data handling, and suspension terms that on premises paper never mentions, published under Oracle’s cloud services contracts.
The stakes are asymmetric. Getting the vocabulary wrong costs nothing; getting the governing paper wrong prices audits, mergers, and renewals for years, which is why this page spends its time on the second problem.
Nowhere, and that is the point. Oracle retired the Oracle License and Services Agreement for new business around 2013, but every order placed under an OLSA remains governed by it, so mature estates run OLSA, OMA, and cloud paper simultaneously.
Oracle’s contract vehicles, by generation
| Vehicle | Era | Status | Governs |
|---|---|---|---|
| OLSA | Before roughly 2013 | Closed to new orders, still governing old ones | Legacy license and support estates |
| OMA | 2013 onward | Current master for most enterprise buying | Programs, hardware, support, services, optionally cloud |
| CSA | Cloud era | Current cloud master, transactional or term | OCI, SaaS, Universal Credits, cloud policies |
| Microsoft MOSA and MCA | Different vendor entirely | Not Oracle paper | Microsoft subscriptions; the source of the shorthand |
The split runs by estate: what you are buying decides which master applies, and a single transaction can generate lines under both. The mechanics are identical in shape: a standing master, an ordering document per purchase, and policy documents incorporated by reference.
The license master and the cloud master, compared
| Dimension | License master (OMA) | Cloud master (CSA) |
|---|---|---|
| Scope | Programs, hardware, support, services | OCI, SaaS, cloud support |
| Cost model | License fee plus annual support | Subscription or consumption commitment |
| Compliance mechanism | Audit clause, deployment review | Metering, commitment shortfall, credit expiry |
| Incorporated policies | Technical support policies, license rules | Hosting, delivery, and service level policies |
| Typical order form | License ordering document | Cloud order with credits or subscriptions |
| What expires | Support lapses; perpetual licenses survive | The service itself, and unused credits |
Treat the split as a checklist trigger: any proposal touching both estates gets two reads, one against each master, before anyone discusses price. The double read takes an hour and has paid for itself in every file where it happened.
Each purchase produces an ordering document that names the programs or services, the license metric, quantities, fees, and term, and states which master governs it. The order inherits everything it does not say; silence on any topic means the master’s default applies.
Amendments and negotiated concessions ride on the order, which makes the order the natural home for deal specific protections. It also means a protection won once must be rewon or referenced on every subsequent order.
Risk lives high and money lives low. The location table below is where to look first when a question surfaces mid dispute.
Read the precedence clause, because the stacks answer differently by design. Modern Oracle masters generally let a signed ordering document prevail over the master for that transaction, which is why negotiated amendments ride on orders.
Incorporated policies sit below both, but move on Oracle’s schedule. A term you did not freeze is a term you agreed to re read annually.
Because estates straddle the line: database and middleware on premises under the OMA, OCI and Fusion under cloud paper, often with OLSA legacies underneath. Nothing consolidates automatically, and each stack keeps its own defaults until renegotiated.
Take a composite June renewal: database processor licenses with support, plus an OCI Universal Credits commitment added as an incentive. One commercial conversation, one signature meeting, three rulebooks in play.
In the reviews where this split was mapped before signature, the buyer caught terms drifting onto the wrong paper in time to fix them. In the reviews done afterward, the mapping became a dispute exhibit.
Master terms are negotiable before signature for enterprise buyers, and materially harder to reopen once orders accumulate beneath them. The negotiability profile differs by stack, and knowing the difference saves rounds.
The license master carries the classic audit clause, typically exercisable on 45 days written notice, reviewing deployment against entitlements. The cloud master needs no audit in that sense: Oracle meters consumption itself, so cloud exposure concentrates in commitment sizing, overage rates, and expiry forfeiture rather than in seat counting.
The incorporated documents. Support fee behavior follows the technical support policies as they stand from time to time, and cloud operations follow the hosting and delivery policies on the same basis, so Oracle can revise the rulebook mid term.
The buyer response is surgical: cap support uplift in the order, freeze the definitions that price you, and reference policy versions by date where it matters. Clause by clause language for the support side lives in the support renewal contract checklist.
Order by order, never wholesale. Signing an OMA does not migrate OLSA orders onto it, and buying cloud does not move license entitlements anywhere; each order keeps the master it was born under until the parties actively novate it.
It keeps governing its orders, sometimes advantageously. OLSA era terms occasionally read better for the buyer than their modern equivalents, which is why wholesale consolidation onto new paper should be evaluated, not welcomed by default.
Before agreeing to any tidy up that renews old orders under a new master, compare the audit, assignment, and definition language line by line. Consolidation offers are rarely neutral for the side proposing them.
Consolidation is right when the legacy terms are worse than the new ones and the estate is simple enough to compare line by line. It is wrong whenever it is accepted unread, because the party drafting the consolidation chose what to carry forward.
Whatever the assignment clause says, which is why it deserves reading before the deal team needs it. License masters typically restrict assignment without consent; divested entities can find themselves unlicensed on day one, and acquirers can find the target’s paper does not transfer to the group.
A ULA is an amendment layer riding on the license master and its orders: unlimited deployment rights for named programs, for a term, ending in certification. Its mechanics and exit economics are a discipline of their own, mapped in the Oracle ULA guide.
A note on scope: this is a reference page about the paper itself. The negotiation craft that moves these terms, plays, sequence, and timing, lives in the buyer strategies playbook, and this page stays out of its way deliberately.
The recurring errors are structural rather than technical, and they surface at renewal, at audit, and in due diligence, long after the signature that caused them.
Six columns, kept current: the order, its date, the governing master, the products and metrics, the special terms it carries, and the renewal date. One owner maintains it, and every renewal starts by reading it.
The register is the artifact that makes this page unnecessary in a crisis. Estates that held one answered audit and divestiture questions in hours; estates without one commissioned archaeology under deadline.
The account team line, repeated in most first drafts we see, is that the master is standard boilerplate and the order is where the deal lives. We disagree. In roughly two thirds of the 40 to 50 Oracle contract structures Fredrik Filipsson reviewed between 2023 and 2025, the costly exposure traced back to unread master terms, not to order pricing: audit scope that widened a review, assignment language that complicated a divestiture, incorporated policies that moved support fees after signature. The master governs every order beneath it for years, which makes it the negotiation; the order is the receipt. Settle audit, assignment, and freeze language before the first order exists, when the leverage to move them is at its peak.
Source: Redress Compliance advisory engagement file, 2024 to 2025.
Buyers negotiate the receipt and skip the rulebook. The master sets audit, assignment, and termination defaults for a decade of orders placed beneath it.
Bring the contract stack under management inside a quarter with these moves.
No. MOSA is the Microsoft Online Subscription Agreement. Buyers searching for an Oracle MOSA almost always mean the Oracle Master Agreement, the OMA, which governs on premises licenses, hardware, support, and services.
The Cloud Services Agreement, the CSA, or the cloud schedule of a modern OMA. The MCA itself is the Microsoft Customer Agreement; Oracle’s cloud paper covers OCI, Fusion SaaS, Universal Credits, and the incorporated cloud policies.
Program licenses, hardware, technical support, and professional services, with cloud optionally included on newer versions. It exists in a transactional form for a single purchase and a five year form under which multiple ordering documents accumulate.
Oracle cloud services: OCI consumption, SaaS subscriptions, and the service level, data handling, suspension, and renewal terms that govern them. Universal Credits commitments and pay as you go orders both attach beneath it.
No. Every order remains governed by the master it was placed under, so OLSA orders keep OLSA terms indefinitely. Migration happens order by order, and only when paper is actively renewed or novated onto the new master.
Both, split by line. License and support lines fall under the license master while cloud lines fall under the cloud master, so a combined renewal must be read against two rulebooks before signature.
Yes, before the first order. Audit notice and scope, assignment, liability, and policy freeze language all move for enterprise buyers at signature, and become far harder to reopen once orders and spend accumulate beneath the master.
Generation and structure. The OLSA was Oracle’s standard master before roughly 2013; the OMA replaced it with a modular master covering programs, hardware, support, services, and optionally cloud. Orders placed under the OLSA remain governed by it, so both often live in one estate.
The governance, renewal and negotiation moves that hold Oracle cost across a five year horizon.
Used across more than five hundred enterprise engagements. Independent. Buyer side. Built for procurement leaders running the next renewal cycle.
500+ enterprise clients. 11 vendor practices. Industry recognized. One conversation can change what you pay for the next three years.
One short note on Oracle contracts and licensing, master agreements, audit terms, and the buyer side moves we are running in client engagements.
