Moving Oracle workloads into a third-party datacenter does not transfer or reduce your license obligation, and in some configurations it multiplies it. This guide names exactly who must hold the license, what the hosting exhibit permits, and where the compliance exposure sits before you sign a colocation or managed services contract.
Moving Oracle workloads into a third-party datacenter does not transfer or reduce your license obligation, and in some configurations it multiplies it. This guide names exactly who must hold the license, what the hosting exhibit permits, and where the compliance exposure sits before you sign a colocation or managed services contract.
When a customer moves Oracle Database, WebLogic, or an options-heavy estate out of its own datacenter and into a hosting provider, a colocation facility, or a managed services arrangement, the first assumption is usually wrong. Buyers treat the move as a hardware relocation and expect the license count to travel unchanged. In practice, the outcome depends entirely on who runs the workload, for whose benefit, and on what partitioning technology. Get those three answers right and the move is clean. Get them wrong and you inherit a compliance gap that can run into seven figures at list price.
The controlling concept is that Oracle licenses are granted for your internal business operations only. Under a standard license agreement you cannot use Oracle software to run services for third parties, and you cannot use the programs for the internal business operations of any other entity. When programs are used for the benefit of a third party, Oracle classifies that activity as hosting, and hosting has its own rules and its own contract exhibits. This is the pivot point that decides everything else in a hosting or managed datacenter deal. For the broader movement rules see our pillar on Oracle license transfer and assignment.
Moving Oracle into someone else's datacenter is not a transfer. In most models you keep the license and every obligation attached to it.
Start with the good news, because it is stronger than most vendors admit. Standard Oracle license agreements typically permit deployment on a third party's servers. The relevant language in Schedule P reads to the effect that you may allow your agents and contractors (including, without limitation, outsourcers) to use the programs and deliverables for your internal business operations, and that you remain responsible for their compliance with the General Terms and Schedule P. That single clause is what makes colocation and most managed hosting legal without any new agreement.
The practical rule from 25 years of negotiations: you can run Oracle in a third-party environment unless a specific contractual provision bars it, and such provisions are rare. If you are simply lifting your own workloads into a rented cage or a managed provider's tin, and the workloads still serve your business, you do not need a new hosting exhibit. You keep your existing licenses, you keep your existing support stream, and the provider acts as your agent. Do not let a hosting sales team or an Oracle rep tell you a colocation move requires fresh licenses. It does not, as long as the beneficiary is still you.
The trap sits in the word 'beneficiary'. The moment the Oracle software starts serving another entity's operations, for example a managed provider standing up a shared Oracle instance for multiple client tenants, you have crossed from internal use into hosting, and different licensing applies. That is where the model you sit under stops being an implementation detail and becomes the entire commercial question.
If Oracle is being delivered as a service to third parties, the arrangement falls into one of two program models, and they allocate the license (and the liability) in opposite directions. Getting this classification right before signing is the single most valuable thing a buyer can do.
| Dimension | ASFU (Application Specific Full Use) | PAH (Proprietary Application Hosting) |
|---|---|---|
| Who holds the Oracle license | Your customers own or control the licenses | The provider holds the Oracle license |
| Who bears audit and compliance liability | Customers bear it | Provider bears all of it |
| Typical use case | Pure hosting provider delivering Oracle as a service | ISV hosting its own proprietary application that embeds Oracle |
| Eligibility restriction | Customer wants direct Oracle ownership | Provider must own the application IP |
| Generic managed hosting of a third party's app | Requires full-use licenses | Not permitted under PAH |
Under ASFU the customer receives direct Oracle rights, owns or controls the licenses, and the provider supplies hosting and operational management on top. This is the correct structure for a pure hosting provider. Under PAH the customer does not receive Oracle licenses at all; the provider holds them, and the customer consumes Oracle only through the value-added features of the provider's application. The liability split follows the license: under PAH the provider bears every compliance obligation, audit response, and true-up; under ASFU the customer carries them.
The critical qualifier that catches generic managed service providers: PAH is not a general hosting license. It is reserved for ISVs hosting their own proprietary solution, and the ISV must own the application IP. If you are hosting someone else's application, that does not fall under PAH. It would require full-use licenses with a special clause, or it is not permitted at all. Full-use licenses on their own cannot be used to host for third parties without a separate PAH agreement. If a managed provider is quoting you a bundled Oracle-inclusive price and cannot tell you which model backs it, treat that as unpriced audit risk sitting in your contract.
If your managed provider cannot name the model, ASFU or PAH, that backs your Oracle usage, you are carrying unpriced audit risk in someone else's contract.
Here is where the money is actually lost. Colocation and managed datacenters follow on-premises partitioning rules, not cloud rules. That matters because most enterprises virtualize, and virtualization is where Oracle extracts the largest overcounts. Soft partitioning, which includes VMware and Hyper-V in any configuration, does not limit license scope. The full physical server, and in many cases the full vSphere cluster, must be licensed. Pinning a VM to specific cores does not change this.
Only the technologies named in Oracle's partitioning policy qualify as hard partitioning: Oracle Linux KVM (capped), Solaris Capped Zones, IBM LPAR, and a small set of legacy entries. VMware never qualifies, regardless of how it is configured. A single vSphere cluster spanning many hosts can pull the entire estate into license scope. When you move into a hosting provider's shared VMware platform, you must know exactly which hosts and clusters your workloads can migrate to, because Oracle will count all of them. This is closely related to the constraints we cover in reassigning Oracle licenses between servers and datacenters.
The scale of the problem is not theoretical. Across roughly 30 to 40 Oracle virtualization engagements in 2024 and 2025, our analysis found that in soft-partitioned estates the cores Oracle billed for came out at a median of 3.5 times the cores actually running a database. On the other side of the ledger, correctly capped hard-partition configurations held at audit and preserved 30 to 60 percent Enterprise Edition savings. At a $47,500 per-processor list price, with an x86 core factor of 0.5 (an 8-core server needing 4 processor licenses), the difference between soft and hard partitioning on a moderately sized estate is easily a seven-figure exposure.
When your chosen 'hosting provider' is actually a public cloud, the rules change again. Oracle's policy lists Amazon EC2, Amazon RDS, Microsoft Azure, and Google Cloud Platform as Authorized Cloud Environments. Google Cloud is on that list now, contrary to a great deal of older guidance. Inside an Authorized Cloud Environment, the counting rule is vCPU-based: with hyperthreading enabled, two vCPUs count as one Oracle processor license; with hyperthreading disabled, one vCPU counts as one. Critically, Oracle states the Processor Core Factor Table does not apply in these environments.
That dropped core factor is a doubling trap. Lifting an unchanged estate to EC2 doubles the Oracle requirement on identical hardware. A 48-core server needs 24 processor licenses on premises at the 0.5 core factor, but 48 licenses on AWS because the multiplier stops at the cloud boundary. Named User Plus minimums travel too: a 32 vCPU instance is 16 Oracle processors, and the 25 NUP-per-processor minimum is counted on that cloud number. See the full mechanics in our guide to Oracle licensing on AWS and the retention rules in Oracle BYOL cloud transfer and license retention.
Two further points buyers underestimate. First, Authorized Cloud Environment status does not eliminate BYOL requirements. You must still hold perpetual Oracle licenses with active Software Update License and Support; the framework changes how you count, not whether you must license. Second, the cloud policy is non-contractual and Oracle can change it. Oracle has previously attempted to double the license requirement on AWS and Azure, and it can revise the document again. If your architecture depends on the current counting rule for its economics, you are exposed to a policy change you did not agree to. Where SE2 fits, note the caps differ by provider: 8 vCPUs on AWS, 4 vCPUs on Azure and GCP per database, as covered in our Oracle SE2 licensing analysis.
The financial stakes vary by how the move is structured, but the pattern is consistent. A same-hardware move into a soft-partitioned hosting platform, or into a public cloud with the core factor stripped out, can double or triple the license requirement without adding a single new user. That is not value Oracle created; it is a counting artifact you can negotiate against or engineer around.
| Scenario | License impact vs on-prem baseline | Where the risk lives |
|---|---|---|
| Colocation, dedicated hosts, hard partition | Neutral | Proving isolation at audit |
| Managed provider, shared VMware cluster | Up to 3.5x (median overcount) | Cluster reachability and vMotion scope |
| Pure hosting, ASFU model | Customer holds and counts licenses | Customer bears audit liability |
| ISV proprietary app, PAH model | Provider holds and counts licenses | Provider bears all compliance |
| Lift-and-shift to AWS/Azure EC2 | 2x on identical cores | Non-contractual policy can change |
Your leverage is highest before you sign the hosting or managed services contract, and it collapses once workloads are live and Oracle can observe the deployment. Push the compliance obligation onto the provider where the model allows it. In PAH and ASFU arrangements the allocation of audit liability is contractual, so negotiate an explicit indemnity: if the provider's platform architecture (shared clusters, uncapped soft partitioning) creates an overcount, the provider carries the true-up cost, not you. Providers that host Oracle at scale will resist this, which tells you exactly where they know the risk sits.
Keep transfer evidence from day one. Any move between your datacenter and a provider is a candidate for audit scrutiny, and you will need to prove the beneficiary was always your business and the partitioning was compliant. Our guide on proving a legitimate Oracle license transfer at audit covers the documentation set. If the move is part of a corporate change, review the Oracle secondary-market and resale reality before assuming licenses can follow a sold or carved-out unit.
The one-line summary from the buyer side: moving Oracle into a hosting provider or managed datacenter is a change of location, not a change of ownership. You almost always keep the license and every obligation attached to it. The money is won or lost in the partitioning architecture and the contractual allocation of audit liability, both of which you control only before the ink is dry.
Generally no. Standard Oracle license agreements permit deployment on a third party's servers through the Schedule P outsourcer and agent clause, provided the workloads still serve your internal business operations. You keep your existing licenses and support. You would only need new licensing if the Oracle software starts serving another entity's operations, which Oracle classifies as hosting.
It depends on the model. Under ASFU (Application Specific Full Use) the customer owns or controls the licenses and bears the audit liability, while the provider supplies hosting. Under PAH (Proprietary Application Hosting) the provider holds the licenses and bears all compliance obligations, but PAH is only available to ISVs hosting their own proprietary application. Generic managed hosting of a third party's app does not qualify for PAH and requires full-use licenses.
It can dramatically. Colocation and managed datacenters follow on-premises partitioning rules. VMware is soft partitioning and never limits scope, so the full server or cluster must be licensed. Across recent engagements the median overcount in soft-partitioned estates was 3.5 times the cores actually running a database. Demand dedicated, isolated hardware or price the full reachable cluster before signing.
Oracle uses hosting agreements (ASFU and PAH) when Oracle software is used for the benefit of a third party rather than solely for your internal business operations. You do not need one for straightforward colocation or outsourcing of your own workloads, which are covered by the Schedule P agent clause. You do need one when you are delivering Oracle as a service to your own customers.
Public clouds are Authorized Cloud Environments with a different counting rule. The core factor does not apply, so two vCPUs (hyperthreading on) equal one processor license, and lifting an unchanged estate to EC2 doubles the requirement on identical cores. You still need perpetual licenses with active support to use BYOL, and Oracle can change the cloud policy because it is non-contractual.
Only if you negotiate it into the contract. Under PAH the provider bears compliance by default; under ASFU the customer does. For colocation and outsourcing under Schedule P, you remain responsible for your agents' compliance. Where the provider controls the architecture that drives the count, negotiate an explicit indemnity so overcounts caused by their platform are their cost, not yours.
Oracle Cloud at Customer enterprise licensing framework. Buyer side framework across OCI Dedicated Region, Exadata Cloud at Customer, autonomous database.
Gated with a work email on the download page. No sales follow up you did not ask for.
Get the White Paper →
500+ enterprise clients. 11 vendor practices. Industry recognized. One conversation can change what you pay for the next three years.
One buyer side briefing a week. Renewal signals, audit moves, and the levers that work. No vendor spin.
