Short answer: Oracle has no 90-day rule in the cloud. The 90-day reassignment restriction is a Microsoft License Mobility term, not an Oracle one. Oracle perpetual licenses can be redeployed between on-premise and cloud at any time, but each license counts once, must stay on active Oracle support, and cloud counting follows Oracle's Authorized Cloud Environment vCPU policy.
Key Takeaways
- No Oracle 90-day rule exists. The 90-day license reassignment limit is Microsoft's, applied under its License Mobility through Software Assurance program — Oracle has never published an equivalent.
- Oracle license mobility is single-use, not time-bound. A perpetual license may be moved freely, but it can only cover one running deployment at a time — never on-premise and cloud simultaneously.
- Cloud counting uses vCPUs, not the Core Factor Table. On AWS and Azure, 2 vCPUs with hyper-threading on equal one Oracle Processor license; the on-premise core factor does not apply.
- BYOL requires active Oracle support. Licenses moved to the cloud under Bring Your Own License must remain on Oracle's 22%-of-net annual support — third-party support breaks BYOL eligibility.
- Cloud migrations are a top audit trigger. Across our engagements, a documented cloud migration precedes roughly 40% of Oracle audit notices (Oracle Licensing Experts, 2026).
The "90-day rule" question is one of the most common we field during cloud migration planning, and it almost always comes from teams who have previously licensed Microsoft SQL Server or Windows Server in the cloud. Microsoft's rules are explicit and well-documented; Oracle's are scattered across contract documents, policy PDFs, and unwritten audit practice. That gap creates confusion — and Oracle's sales teams rarely rush to correct it. This guide separates the myth from the mechanics so you can plan a cloud move without inheriting a compliance gap.
Is There an Oracle 90-Day Rule in the Cloud?
No. There is no Oracle 90-day rule in the cloud. The 90-day reassignment restriction is a Microsoft term: under Microsoft's License Mobility through Software Assurance, you cannot reassign a license to a different server more than once every 90 days, except on permanent hardware failure. Oracle has never published a comparable time-bound reassignment limit, so applying the Microsoft rule to an Oracle estate is a category error.
License mobility is the right to redeploy a software license from one machine or environment to another without buying a new license. Microsoft formalizes mobility with documented rules. Oracle, by contrast, treats perpetual licenses as freely redeployable across hardware — there is no waiting period, no reassignment counter, and no requirement to notify Oracle when you move a license. What Oracle does impose is the constraint that a single license can only ever cover one live deployment, and that cloud deployments are counted under a separate policy.
When a customer asks an Oracle rep "is there a 90-day rule?", the rep often answers vaguely — "you need to make sure your licenses cover your deployment" — without confirming that no such rule exists. The vagueness is deliberate. Uncertainty makes customers over-buy. The accurate position: move licenses whenever you need to, but never run the same license in two places at once.
What Actually Governs Oracle License Mobility to the Cloud?
Oracle license mobility to the cloud is governed by three things: your contractual license assignment terms, Oracle's Authorized Cloud Environment policy, and the single-use principle. None of these is a 90-day timer. Together they determine how many licenses your cloud deployment consumes and whether your existing entitlements stretch to cover it. Get any one wrong and you are under-licensed the moment the workload goes live.
The Authorized Cloud Environment (ACE) policy is Oracle's document defining how its programs are licensed on AWS and Microsoft Azure. It is a policy, not a contract clause — Oracle can revise it, and it has. Under the current ACE policy, Oracle counts vCPUs rather than physical cores, and the Core Factor Table that reduces on-premise core counts does not apply. This is the single most important counting difference between on-premise and authorized cloud.
| Dimension | Oracle on-premise | Oracle on AWS / Azure (ACE) | Microsoft License Mobility |
|---|---|---|---|
| Reassignment time limit | None | None | Once per 90 days |
| Counting metric | Physical cores × core factor | vCPUs (2 vCPU = 1 license, HT on) | Physical cores / vCPUs per product |
| Core Factor Table applies? | Yes | No | N/A |
| Simultaneous dual use? | No (single-use) | No (single-use) | No |
| Active support required for BYOL? | N/A | Yes | Software Assurance required |
How Does Oracle Count Licenses in the Cloud Without a 90-Day Rule?
Oracle counts cloud licenses by vCPU under the Authorized Cloud Environment policy. With hyper-threading enabled — the default on most AWS and Azure shapes — two vCPUs equal one Oracle Processor license. With hyper-threading disabled, one vCPU equals one Processor license. There is no time-based reassignment rule, but your license total must always match the peak vCPU footprint of every instance running Oracle software.
This matters because cloud autoscaling and burst capacity can silently push you over your entitlement. If a Database Enterprise Edition workload normally runs on 16 vCPUs (8 Processor licenses) but scales to 32 vCPUs under load, you need 16 Processor licenses to stay compliant during the peak — even if the peak lasts an hour. Oracle's audit position is that you license the maximum, not the average. Our Oracle license optimization service models peak-versus-steady-state consumption precisely so cloud elasticity does not become an audit liability.
What Is Oracle's 10-Day Failover Rule and Is It a Mobility Right?
Oracle's 10-day rule is a failover allowance, not a mobility right. It permits one unlicensed failover node in a clustered environment to run Oracle programs for up to 10 separate 24-hour periods per calendar year during failover events. The failover node must share a single storage array with the licensed primary node. It is the closest thing Oracle has to a "free movement" provision — and it is far narrower than people assume.
The 10-day rule does not let you shuttle a license between two production servers, and it does not map cleanly onto cloud architectures where storage is virtualized and nodes are ephemeral. Oracle's auditors scrutinize 10-day-rule claims aggressively: exceed 10 days, add a second failover node, or use non-shared storage, and the allowance evaporates — leaving the failover node fully licensable. Treat it as a disaster-recovery convenience, never as a substitute for license mobility. For multi-region DR strategy across clouds, see our Oracle disaster recovery licensing guide.
Moving Oracle workloads to AWS, Azure, or OCI?
Our Oracle Cloud advisory service verifies how many licenses your cloud footprint actually consumes — before Oracle's audit team does the counting for you.
Can I Run the Same Oracle License On-Premise and in the Cloud During Migration?
Only with explicit contractual cover. Oracle's default position is single-use: one license covers one live deployment. Running both an on-premise copy and a cloud copy during a parallel migration window — even for a few weeks of testing — is under-licensing unless your agreement grants a migration grace period. Oracle does not offer this automatically, so negotiate it in writing before you stand up the parallel environment.
This is one of the most common cloud-migration compliance failures we see. Teams assume that because they "own" the license, they can run it wherever they like during a transition. Oracle's auditors look specifically for overlap windows where the same license appears to cover two deployments. A short, documented dual-use grace period costs nothing to request during contract negotiation and removes the single largest migration audit risk. Our Oracle contract negotiation service builds migration grace periods into cloud-transition deals as standard.
Does Moving Oracle Licenses to the Cloud Trigger an Audit?
Moving licenses does not directly trigger an audit, but cloud migrations are among the strongest audit predictors Oracle has. A migration changes your deployment footprint, alters your support spend, and often surfaces counting errors — exactly the signals Oracle's License Management Services team watches. Audits frequently arrive 12 to 24 months after a publicized or contractually visible cloud move.
Across our engagements, a documented cloud migration precedes roughly 40% of Oracle audit notices (Oracle Licensing Experts, 2026). The pattern is consistent: customers announce a migration, reduce on-premise support lines, and Oracle's compliance team responds with a "soft audit" or formal LMS review. The defense is to enter the migration already knowing your exact entitlement-versus-consumption position. See our Energy OCI cloud migration case study, where pre-migration entitlement verification turned a projected $2.1M exposure into a clean transition. For the full audit framework, read our Oracle audit defense guide.
How the Authorized Cloud Environment Policy Changes the Math
The ACE policy converts on-premise core-factor math into raw vCPU math, and the difference is rarely in the customer's favor. On-premise, an Intel server with the standard 0.5 core factor lets 16 physical cores consume only 8 Processor licenses. On AWS or Azure, those same 16 cores presented as 32 vCPUs (hyper-threaded) still consume 16 Processor licenses — double the on-premise count for equivalent compute.
This is why "lift and shift" to authorized cloud often increases Oracle license consumption even though the workload is identical. Right-sizing the cloud shape, disabling hyper-threading where supported, or moving to OCI (where Oracle applies its own favorable counting) can all change the equation. The decision should be modeled before the migration, not discovered on the cloud invoice. Compare your options in our Oracle vCPU counting guide and the broader Oracle Cloud Licensing Guide.
Across our cloud migration engagements, customers who lifted-and-shifted Oracle workloads to AWS or Azure without right-sizing consumed an average of 1.8× more Processor licenses than their on-premise baseline — purely from the loss of the Core Factor Table under the ACE policy (Oracle Licensing Experts, 2026).
Frequently Asked Questions
Does Oracle have a 90-day license mobility rule?
No. Oracle has no documented 90-day license reassignment rule. The 90-day rule belongs to Microsoft's License Mobility program, which restricts reassigning a license to a new server more than once every 90 days. Oracle's perpetual licenses carry no such time-bound reassignment limit — they are governed instead by the Authorized Cloud Environment policy and your contractual assignment terms.
Can I freely move Oracle licenses between on-premise and cloud?
Yes, Oracle perpetual licenses can be redeployed between environments, but each license may only be counted once at any moment. You cannot run the same license on-premise and in the cloud simultaneously. The license must remain on active Oracle support, and cloud deployments on AWS or Azure follow Oracle's Authorized Cloud Environment vCPU counting rules.
What is Oracle's 10-day failover rule?
Oracle's 10-day rule lets an unlicensed failover node in a clustered environment run Oracle programs for up to 10 separate 24-hour periods per calendar year during failover events. It applies only to one designated failover node sharing a single storage array with the primary. It is a failover allowance, not a general license mobility right, and it does not translate cleanly to cloud architectures.
How does Oracle count licenses in the cloud without a 90-day rule?
On AWS and Azure, Oracle counts vCPUs under its Authorized Cloud Environment policy: with hyper-threading enabled, 2 vCPUs equal one Oracle Processor license; with hyper-threading off, 1 vCPU equals one license. The on-premise Core Factor Table does not apply. There is no time-based reassignment restriction, but licenses must match the peak deployment footprint.
Does moving a license to the cloud trigger an Oracle audit?
Moving licenses itself does not trigger an audit, but cloud migrations are a leading audit trigger because they change deployment footprints and often reveal counting errors. Oracle's License Management Services frequently audits within 12 to 24 months of a documented cloud migration. Across our engagements, cloud migrations precede roughly 40% of Oracle audit notices (Oracle Licensing Experts, 2026).
Can I use the same license for on-premise and cloud during migration?
Only briefly, and only if your contract permits dual deployment during transition. Oracle's default position is single-use: one license covers one deployment. Running both on-premise and cloud copies during a parallel migration window without contractual cover is under-licensing. Negotiate an explicit migration grace period in writing before you run parallel environments.