Moving Oracle Databases Between Clouds: Licensing, Egress, and Portability in 2026

This is the definitive buyer-side guide to what happens to your Oracle Database licenses when workloads move between AWS, Azure, Google Cloud, OCI, and on-premises. It shows where the money leaks during the transition itself, where Oracle holds leverage, and the moves that stop you double-paying across a multi-month cutover.

Most Oracle cloud licensing content treats a single destination as a static end state: BYOL on AWS, BYOL on Azure, or License Included on OCI. Migrations do not work that way. A real move runs for months, keeps the source system alive while the target proves out, crosses at least two counting regimes, and generates a data-transfer bill that nobody modeled. The licensing risk lives in the transition, not the endpoint, and Oracle knows it. In 25 years negotiating with this vendor, the pattern is consistent: the audit letter arrives during or just after a migration, not before it.

This guide centers the transition. It covers how cores are counted the instant you leave on-premises, how many licenses port across each platform, why the same 16 licenses cover twice the compute on OCI as on AWS, how the 100-day dual-running window actually works, where egress charges ambush you (the 2026 rates and the surcharges that stack on top), and how a migration reliably triggers an Oracle audit. Every figure below is grounded in the research provided or flagged as market experience. Read it before you sign the migration statement of work, not after the invoice.

The core rule: the moment you leave on-premises, the discount evaporates

Start with the single fact that changes the economics of every Oracle cloud migration. In on-premises environments, Oracle's Processor Core Factor Table applies. On common Intel and AMD x86 processors the factor is 0.5, which means two physical cores count as one Processor license. In Authorized Cloud Environments (Oracle's defined term for AWS, Azure, and Google Cloud), the Core Factor Table is explicitly not applicable. Oracle's own policy document, "Licensing Oracle Software in the Cloud Computing Environment," states this directly.

The practical effect: on the three big hyperscalers, every two hyper-threaded vCPUs count as one full Processor license. As Cintra put it in March 2025, this exclusion effectively doubles the licensing cost compared to many on-prem environments. A workload that consumed 8 Processor licenses on a 32-core on-prem box (32 cores multiplied by 0.5, halved again because you sized conservatively) does not stay at 8 when you lift it to AWS EC2. If it lands on 16 vCPUs, it needs 8 licenses; if you provision generously to 32 vCPUs, it needs 16. The math on our Oracle BYOL on AWS reference walks the two-vCPU-per-license rule in detail.

The core factor discount is a property of on-premises tin. It does not travel. Model your target on vCPU counting or you will under-buy by roughly half.

There is one narrow relief valve inside the policy. Authorized Cloud Environment instances with four or fewer vCPUs on AWS or Azure are counted as one socket, which Oracle treats as equivalent to one Processor license. That helps small, fixed workloads and nothing else. It does not scale to production databases, and it does not restore the core factor. Google Cloud is now named in the same policy alongside Amazon EC2, Amazon RDS, and Microsoft Azure; older guidance that excluded GCP is out of date, and buyers who follow it price Google workloads under the on-prem core factor rule when the vCPU rule actually applies. Our deep dive on Authorized Cloud Environment core counting covers each platform's arithmetic.

The policy is unilateral. Your contract is not.

This is the leverage point most buyers miss. The "Licensing Oracle Software in the Cloud Computing Environment" document is a non-contractual, unilateral policy. Oracle can revise it at any time, and it has. The operative version for 2026 is the June 12, 2024 update, which introduced only minimal changes from its predecessor. Oracle references this document constantly in audits and compliance discussions, and buyers routinely treat it as binding law. It is not.

Your Oracle Master Agreement (OMA) and your ordering documents take precedence over the policy. If your contract grants specific mobility rights, specific metrics, or specific definitions of a processor, those govern, not the PDF. This matters enormously for a migration, because Oracle's policy could change mid-project and reprice your target environment. The buyer-side move, drawn from repeated negotiations, is to build cloud migration terms into the contract itself: pin the counting method, pin the conversion ratios, and pin the mobility rights in a signed ordering document or amendment before you migrate. Do not let a document Oracle can rewrite dictate a position you will hold for five years.

Practically, that means running the review described in our guide on the Oracle license review to run before you sign a migration SOW. If your OMA is silent on cloud, you are exposed to whatever the policy says on the day of the audit, and that is the position you want to fix in writing while you still have something Oracle wants (a migration commitment, a renewal, a new purchase).

BYOL portability: the same licenses, different mileage on each platform

Bring Your Own License (BYOL) is not a new grant. It is the reallocation of licenses you already own to a cloud deployment. That single sentence, from Oracle Licensing Experts (June 2026), explains most compliance failures on this topic. BYOL does not create capacity; it moves existing capacity, and the source has to give it up. More on that in the dual-running section.

What varies across platforms is how much compute one license buys. On OCI, one Oracle Database Processor license covers 2 OCPUs, and one OCPU equals one physical core, which is four vCPUs with hyper-threading. On AWS, Azure, and GCP, one license typically covers one physical core, meaning two vCPUs. In effect, OCI delivers roughly twice the compute per license as the hyperscalers. A customer with 16 Oracle Database Enterprise Edition Processor licenses can deploy on an OCI VM with up to 32 OCPUs under BYOL; the same 16 licenses on AWS cover far less usable compute.

Two edge cases change the arithmetic. First, Embedded Software Licenses (ESL) are not eligible for BYOL at all; they are tied to a specific application and cannot be moved to the cloud. If part of your estate is ESL, that portion cannot follow the workload, and you must license it fresh or leave it behind. Second, Standard Edition and Enterprise Edition count differently. Enterprise Edition is core-based; Standard Edition is per-socket. Under the OCI conversion ratios, one Standard Edition license maps to a different OCPU allocation than Enterprise Edition, so do not apply the EE ratio to an SE estate.

On Azure specifically, Oracle and Microsoft maintain a strategic partnership, and Oracle explicitly provides license mobility for customers running Oracle software on Azure. That mobility is real, but it does not restore the core factor and it does not exempt you from the double-use rule. If you are weighing BYOL against License Included on Azure, the steady-state math favors BYOL once the workload runs continuously, as we set out in our Azure BYOL versus License Included analysis.

OCI gives you twice the compute per license as AWS, Azure, or Google. That single ratio can flip which platform is cheapest to run the identical workload on.

Which platform is actually cheapest to license the same workload?

Because OCI doubles your effective license capacity, the platform that is cheapest to license is frequently not the platform that is cheapest to run compute on. Buyers make the mistake of comparing raw VM prices and ignoring that they need twice as many hyperscaler cores under license to match OCI's per-license yield. When you own a fixed pool of Oracle licenses and are deciding where to redeploy them, OCI's 2-OCPU-per-license ratio often wins on the license line even when its infrastructure list price is competitive rather than lowest.

The honest answer is that the cheapest platform depends on three variables: how many licenses you already own, how much compute the workload needs, and whether you will buy new licenses or reallocate existing ones. If you are license-rich and compute-modest, OCI stretches your existing entitlement furthest. If you are license-poor and must buy, the hyperscaler License Included models can be cheaper to start, but they lock you into a per-hour meter that punishes steady-state workloads. We model the full decision, including the OCI Support Rewards offset, in our comparison of which cloud makes the same Oracle workload cheapest to license, and the OCI-specific mechanics in our OCI licensing cost guide.

The dual-running trap: where migrations quietly double the bill

This is the single most expensive mistake in an Oracle cloud migration, and it is almost always accidental. During cutover you keep the source database running while the target proves out. That is normal engineering practice. The problem is that BYOL reallocated your licenses to the target, and if the source is still using those same licenses, you are in double-use, which is a compliance violation. You have not bought new licenses; you have double-counted the ones you own.

Oracle's policy provides a defined transition window: a 100-day overlap during which both the on-premises (or source) and the cloud (target) deployment may run on the same licenses. Inside that window you are compliant. Outside it, every day the source stays live on reallocated licenses is a day of unlicensed use that Oracle can and will back-date in an audit. The 100 days is generous for a clean cutover and dangerously tight for a phased, multi-application migration where cutover slips.

Two operational facts make this worse. First, OCI does not enforce license compliance; it will let you over-deploy without warning, so the guardrail is your own tracking, not the platform's. The same is true across the hyperscalers. Second, the counter starts the day you deploy on the target, not the day you plan to cut over, so a project that budgets 100 days from cutover has already burned weeks it did not count.

The buyer-side discipline is straightforward and non-negotiable: track the deployment date on the target, set a hard decommission deadline for the source inside the 100-day window, and decommission on schedule even if it costs you a rollback safety net. If your project genuinely needs longer, negotiate the extended overlap in writing before you start, because Oracle will not grant it retroactively during an audit. We lay out the full playbook in our guide on dual-running Oracle during a cloud cutover and the source-side timing in when to decommission source licenses after a migration.

Migrations trigger audits. Plan for the letter.

Oracle's License Management Services (now GLAS, formerly LMS) watches for major estate changes, and cloud migration is at the top of the list. Oracle often initiates audits following data center refreshes and migrations to cloud or virtualized environments. Moving Oracle workloads to AWS or Azure under BYOL, or running Oracle on VMware, is a documented audit trigger. If you are migrating, assume the letter is coming and prepare as though it is.

The reason migrations attract audits is that they create exactly the compliance gaps described above: core factor confusion, over-deployment on unenforced platforms, and dual-running past the overlap window. Oracle also knows that a mid-migration customer is at maximum disruption and minimum appetite for a fight, which is precisely when a settlement gets signed. If your estate touches VMware during the transition, the cluster-counting exposure compounds the risk; our Oracle on VMware guide covers how Oracle counts every core the database can reach.

An Oracle audit finding is an opening position, not a settled bill. Independent measurement and scope control routinely cut the first number by a third or more.

Here is what every buyer must internalize about audit findings. First, they are retroactive: Oracle counts the duration of unlicensed use and calculates back-dated fees, so turning off a non-compliant instance later does not erase the past exposure. Second, the finding is an opening position, not a bill. Independent measurement and scope control typically cut the first number by a third or more, and using timing (quarter-end), alternatives (continued cloud migration, third-party support), and the strength of your counter-arguments can negotiate a settlement down by 40 to 70 percent or more. The audit is a negotiation, and it starts with Oracle's most aggressive number, not its fairest one.

The defensive posture during a migration: keep your own contemporaneous records of deployment dates, vCPU counts, and decommission dates. If Oracle's measurement disagrees with yours, your dated evidence is what pulls the number down. Do not accept Oracle's scripts as the sole source of truth, and do not let the audit expand beyond the products and environments named in the notice.

The egress cost trap: the migration bill nobody modeled

Licensing is only half the transition cost. The other half is data egress, the per-gigabyte charge you pay to move data out of a cloud, and for a large database migration it can dwarf what anyone budgeted. These are the verified 2026 headline rates: entry egress runs $0.09/GB on AWS, $0.087/GB on Azure, and $0.12/GB on Google Cloud Premium Tier. Cloudflare R2 charges $0.00, and OCI is dramatically cheaper than the hyperscalers at 10TB free then $0.0085/GB after that.

Volume tiering matters for database-scale moves. Below 50TB per month, Azure is cheapest among the hyperscalers at $0.087/GB versus AWS at $0.09/GB and Google at $0.12/GB. From 50TB up, Azure and AWS converge at identical rates ($0.07/GB, then $0.05/GB above 150TB). The direction of the migration therefore matters as much as the volume: moving a large database off AWS or Azure at $0.05 to $0.09 per gigabyte is a real five- or six-figure line item, while moving into OCI (or out of OCI after the free 10TB) is comparatively trivial.

The hidden surcharges are where budgets actually break. Egress rates are the headline, but NAT Gateway processing at $0.045/GB and cross-availability-zone transfer at $0.01/GB each way stack on top of the base rate. A migration that routes data through a NAT gateway can more than double the effective per-gigabyte cost. Model the full path, not just the advertised egress number, and route around the gateway where architecture allows.

Two 2026 developments cut both ways. Under the EU Data Act, AWS, Azure, and Google now offer free egress when customers leave the platform under specific conditions. Read the fine print: the conditions are narrower than the headlines suggest, and most migrations will not qualify without deliberate structuring. Separately, on 1 May 2026 Google raised its first major hyperscaler egress rate in years, doubling North America CDN Interconnect, Direct Peering, and Carrier Peering from $0.04 to $0.08 per GiB; standard internet egress did not change, so most workloads pay exactly what they paid in April. Our full breakdown of these traps sits in the egress cost trap when migrating Oracle databases off a cloud.

Rehost, replatform, or refactor: each path reprices your license bill

How you migrate changes what you owe. A lift-and-shift rehost carries the same database engine and the same license metric to the target, so your exposure is dominated by the vCPU counting rules above: size the target on cores, apply the two-vCPU-per-license rule, and you have your number. A replatform (for example, moving to a managed service or a different edition) can change the metric entirely, and a refactor away from Oracle Database (to PostgreSQL or another engine) eventually removes the license altogether but generates a long dual-running period where you pay for both.

The trap in replatforming is assuming a managed service inherits your BYOL rights unchanged. It sometimes does and sometimes does not, depending on the service and the platform. The trap in refactoring is that the Oracle license bill does not stop until the last Oracle instance is decommissioned, so a slow refactor can cost more in overlap support than the migration saves in year one. We map each path to its license consequence in our guide on how rehost, replatform, and refactor each change your Oracle license bill.

Oracle Database@ multicloud: the in-cloud alternative to raw BYOL

There is now a third option beyond BYOL and License Included: the Oracle Database@ services. Oracle and AWS announced general availability of Oracle Database@AWS, letting customers run Oracle Exadata Database Service and Oracle Autonomous Database on dedicated OCI infrastructure sitting inside AWS. Equivalent offerings exist for Azure and Google Cloud. These services put Oracle-managed database infrastructure next to your hyperscaler workloads while keeping the data plane on OCI hardware.

For a buyer, the appeal is that the counting and mobility complexity shifts toward the OCI-favorable model, and egress between the co-located OCI infrastructure and the hyperscaler is designed to be low. The catch, from market experience, is commitment: these are contracted commitments to Oracle, not pay-as-you-go conveniences, and they can re-lock you into Oracle at the infrastructure layer just as you were trying to gain platform freedom. Evaluate Database@ as a licensing and commitment decision, not merely a technical convenience, and price it against straight BYOL on the hyperscaler before you commit.

OCI Support Rewards and the renewal lever

One structural incentive changes the multicloud math in Oracle's favor, and it is worth understanding even if you resist it. OCI Support Rewards let you offset a portion of your on-premises technical support renewal against OCI consumption. For a buyer carrying a large support base, this can materially reduce the effective cost of running on OCI versus a hyperscaler, because the OCI spend partly pays down a bill you owe anyway.

This is genuine value, but it is also a retention mechanism. It rewards concentration on OCI and, over time, makes leaving OCI more expensive because you lose the offset. Model the reward as a real number when comparing platforms, but treat it as a lock-in cost in your exit planning, not a permanent discount. The 2026 Oracle licensing cost overview puts the support line in the context of your total Oracle bill across database, Java, applications, and cloud.

The buyer-side migration checklist

Pull the guidance together into an ordered set of moves. Run these in sequence, and start them before the SOW is signed, not after the first invoice lands.

• Confirm your OMA and ordering documents, not the cloud policy PDF, and pin the counting method and conversion ratios in writing before you migrate.
• Re-size every workload on vCPU counting for the target platform. The core factor does not travel to AWS, Azure, or Google, so your license requirement roughly doubles versus on-prem x86.
• Compare platforms on effective compute per license, not raw VM price. OCI's 2-OCPU-per-license ratio delivers about twice the compute of the hyperscalers.
• Identify any Embedded Software Licenses and any Standard Edition workloads separately. ESL cannot BYOL at all, and SE counts per socket, not per core.
• Log the target deployment date the day it happens, set a hard source decommission deadline inside the 100-day overlap, and hit it.
• Model egress on the full data path including NAT Gateway ($0.045/GB) and cross-AZ ($0.01/GB each way) surcharges, and check whether an EU Data Act exit applies to your case.
• Keep contemporaneous, dated records of vCPU counts, deployment dates, and decommission dates so you can rebut Oracle's audit measurement.
• Assume an audit letter during or just after the migration and prepare the response before it arrives.

The single sentence to carry into every migration meeting: the risk lives in the transition. Endpoints are easy to license once they are static. It is the months in between, the dual-running, the egress path, and the audit that follows, where the money is won or lost. Control those three and the migration pays for itself. Ignore them and Oracle collects the difference. When you are ready to formalize the position, run the pre-SOW review, lock your terms in writing, and treat every policy document Oracle waves at you as a starting position rather than a settled fact.

Related reading: Dual-Running Oracle During a Cloud Cutover: How to Avoid Paying Twice, The Oracle Authorized Cloud Environment Policy: How Cores Are Counted on AWS, Azure, and Google, The Egress Cost Trap When Migrating Oracle Databases Off a Cloud, Which Cloud Makes the Same Oracle Workload Cheapest to License in 2026?, and Rehost, Replatform, or Refactor: How Each Migration Path Changes Your Oracle License Bill.

Frequently asked questions

Does the Oracle core factor apply after I migrate to AWS, Azure, or Google Cloud?

No. In Authorized Cloud Environments (AWS, Azure, Google Cloud), Oracle's Processor Core Factor Table is explicitly not applicable. Every two hyper-threaded vCPUs count as one full Processor license, which roughly doubles the license requirement compared to on-premises x86 servers where the 0.5 core factor applies. Re-size every workload on vCPU counting before you migrate.

How long can I run both the source and target databases during an Oracle cloud cutover?

Oracle provides a 100-day transition overlap during which both the on-premises source and the BYOL cloud target may run on the same licenses without violating the double-use rule. The counter starts on the day you deploy the target, not the day you plan to cut over. Running the source live past day 100 on reallocated licenses creates double-use exposure that Oracle can back-date in an audit.

Why does one Oracle license cover more compute on OCI than on AWS or Azure?

On OCI, one Oracle Database Processor license covers 2 OCPUs, and each OCPU equals one physical core (four vCPUs with hyper-threading). On AWS, Azure, and Google Cloud, one license covers one physical core, or two vCPUs. In effect OCI delivers roughly twice the compute per license, which can make it the cheapest platform to license an existing entitlement even when its infrastructure price is not the lowest.

How much does data egress cost when migrating a large Oracle database off a cloud in 2026?

Verified 2026 entry rates are $0.09/GB on AWS, $0.087/GB on Azure, and $0.12/GB on Google Cloud Premium Tier, with volume tiers dropping to $0.05/GB above 150TB on AWS and Azure. OCI is far cheaper at 10TB free then $0.0085/GB. Hidden surcharges like NAT Gateway ($0.045/GB) and cross-AZ transfer ($0.01/GB each way) stack on top and can double the effective cost.

Will migrating Oracle to the cloud trigger an audit?

Frequently, yes. Oracle's GLAS (formerly LMS) treats cloud migrations, data center refreshes, and BYOL moves to AWS or Azure as documented audit triggers. Audit findings are retroactive and calculated back to the start of any unlicensed period, but the first number is an opening position. Independent measurement and scope control typically cut it by a third or more, and full negotiation can reduce settlements by 40 to 70 percent.

Is the Oracle cloud licensing policy legally binding?

No. The 'Licensing Oracle Software in the Cloud Computing Environment' document (operative version June 12, 2024) is a unilateral, non-contractual policy Oracle can change at any time. Your Oracle Master Agreement and ordering documents take precedence. Oracle references the policy in audits, so the buyer-side move is to pin the counting method and conversion ratios into your contract before you migrate rather than relying on a document Oracle controls.