Why BYOL Calculations Fail — and How to Get Them Right
Oracle's BYOL programme allows enterprises to apply on-premises perpetual Oracle Database and Middleware licences to cloud deployments, avoiding additional cloud licence fees. The commercial logic is compelling: an enterprise with 200 Oracle Database Enterprise Edition processor licences can deploy on AWS or OCI without paying Oracle's list-price cloud fees, dramatically reducing cloud database costs. The problem is that BYOL eligibility is conditional — on licence type, active support status, edition matching, and deployment topology — and Oracle's GLAS team audits cloud BYOL claims with the same rigour as on-premises deployments.
The 20 checks below validate every material BYOL eligibility condition across the four major cloud platforms. Use this checklist before committing to a cloud migration plan, before renewing Oracle support contracts, and before submitting a ULA certification that includes cloud deployments.
Work through each check in platform context. High Risk items represent conditions where non-compliance creates immediate audit exposure. Medium Risk items represent planning risks that affect cost modelling. Low Risk items are governance hygiene checks. Any High Risk non-compliance finding should be resolved before cloud migration or support renewal.
01Are all on-premises Oracle licences being ported to cloud perpetual licences — not term or cloud licences — with active Oracle Software Support and Update Service?High Risk
Expert NoteBYOL requires perpetual licences with active Oracle support. Term licences, Oracle Cloud subscriptions, and Oracle-on-cloud licences (OCC/BYOL-cloud) are not eligible for BYOL porting. Enterprises that have previously terminated Oracle support on a licence and then attempt to apply that licence to cloud BYOL deployments are non-compliant — Oracle's GLAS team has access to support termination records and matches them against BYOL claims during audit. Verify that every licence applied to BYOL has uninterrupted support history, or obtain legal advice on reinstatement cost implications.
02Does the cloud edition deployed under BYOL exactly match the edition of the on-premises licence being applied — Enterprise Edition to Enterprise Edition, Standard Edition 2 to Standard Edition 2?High Risk
Expert NoteEdition matching is a non-negotiable BYOL condition that Oracle enforces strictly. An Oracle Database Standard Edition 2 on-premises licence cannot be applied to a cloud deployment running Enterprise Edition, even if the customer owns both licence types. This is the most common BYOL calculation error Redress observes in cloud migration projects: migration architects choose a cloud instance type that runs EE (often for performance reasons) without verifying that sufficient EE licences are available for BYOL. Conduct a cloud edition requirement analysis before finalising instance type selections.
03Have Options and Packs (Diagnostics, Tuning, Partitioning, Advanced Compression, RAC) deployed in the cloud been individually validated against on-premises Option licence holdings?High Risk
Expert NoteOracle Database Options and Packs are separately licensed and each requires individual BYOL validation. An enterprise with Oracle Database EE BYOL for base database cannot automatically run Partitioning, Advanced Compression, or RAC in the cloud unless it also holds on-premises licences for each Option. Cloud database services such as AWS RDS Oracle and Azure SQL (Oracle-compatible) frequently enable options by default — including Diagnostics and Tuning Pack equivalents via automated monitoring. Run a cloud Options inventory and validate each against on-premises entitlement before migration.
04Has the Oracle licence agreement been reviewed for cloud-specific BYOL restrictions, including authorised cloud environment lists and any pre-2013 contract cloud exclusions?Medium Risk
Expert NoteOracle's cloud BYOL authorisation has evolved through several policy updates since 2013. Some legacy Oracle agreements — particularly those predating 2016 — contain explicit restrictions on cloud deployment of Oracle software, or limit BYOL to named cloud environments. OCI is universally authorised under Oracle's policy. AWS, Azure, and GCP are authorised under Oracle's Authorised Cloud Environments list, which has expanded over time but requires confirmation against the specific Oracle agreement version. Any agreement that predates Oracle's 2016 cloud BYOL policy update should be reviewed by a specialist before cloud migration.
Does your BYOL calculation hold up to Oracle audit scrutiny?
Redress Compliance validates BYOL eligibility and calculation methodology across OCI, AWS, Azure, and GCP — before Oracle engages.05For Oracle Database Enterprise Edition on OCI, is the 2:1 OCPU-to-processor-licence mapping applied — two OCPUs per on-premises processor licence — and documented in the BYOL register?High Risk
Expert NoteOCI BYOL for Oracle Database Enterprise Edition uses a 2:1 mapping: each on-premises processor licence covers two OCI OCPUs. This is more favourable than the 1:1 mapping used for most other cloud platforms. A common error is applying the AWS/Azure 2-vCPU rule (one processor licence per 2 vCPUs) to OCI OCPUs — which are physical CPU threads, not vCPUs — resulting in under-licensing. On OCI, confirm the OCPU count of the shape, divide by 2, and verify the resulting processor licence requirement against on-premises holdings. Document the calculation and the OCI shape specification in the BYOL register.
06For Oracle Database Standard Edition 2 on OCI, is the 4-OCPU-per-socket calculation applied — one SE2 socket licence per 4 OCPUs — with a maximum of two sockets per server?High Risk
Expert NoteOracle Database SE2 on OCI uses socket-based BYOL: each OCI VM shape has a defined socket count, and SE2 BYOL requires one socket licence per socket (up to the 2-socket SE2 cap). The 4-OCPU-per-socket convention applies to most OCI VM.Standard shapes. This means a VM.Standard3.Flex shape with 8 OCPUs requires 2 socket licences. SE2 BYOL is not available on Bare Metal shapes, which Oracle treats as multi-socket environments exceeding the SE2 2-socket limit. Validate OCI shape socket configuration against Oracle's OCI shape documentation before committing SE2 licences to BYOL.
07Is the Oracle Support Rewards programme applied to OCI BYOL spending, and has the 25% to 33% support invoice reduction been modelled and captured in the business case?Medium Risk
Expert NoteOracle Support Rewards is an OCI-specific benefit that reduces Oracle annual support invoices by 25% of OCI BYOL spending (33% for Oracle Database and Middleware). This makes OCI materially more attractive than AWS or Azure for enterprises with significant Oracle support costs. An enterprise spending £500,000 annually on OCI BYOL-enabled database services could reduce Oracle support by £125,000–£165,000 per year. This benefit is frequently omitted from cloud migration TCO models — a gap that leads to undervaluation of OCI versus hyperscaler alternatives. Model Support Rewards in any OCI vs. AWS/Azure comparison.
08For Oracle Autonomous Database on OCI, has the distinction between BYOL (Bring Your Own Licence) and OCPU pricing been validated — and are Autonomous Database features not requiring additional Options documented?Low Risk
Expert NoteOracle Autonomous Database on OCI is available under BYOL pricing using the 2:1 OCPU mapping, but Autonomous Database includes features that would require separate Options licences on-premises (Diagnostics Pack, Tuning Pack, Advanced Compression, Partitioning, and RAC equivalents). Under the Autonomous Database service, these features are included in the cloud service and do not require separate BYOL entitlement — Oracle considers them part of the cloud service, not separately licensed add-ons. This is a licensing simplification that reduces BYOL complexity for Autonomous Database specifically. Document this treatment in the BYOL register to avoid post-migration re-examination.
09For Oracle Database on AWS EC2 under BYOL, is the 2-vCPU-per-processor-licence mapping applied — one processor licence per 2 AWS vCPUs — with the Intel/AMD Core Factor Table adjustment for non-x86-64 instance families?High Risk
Expert NoteAWS BYOL for Oracle Database uses 2 vCPUs per processor licence for Intel x86-64 instance families (M5, R5, C5, etc.) — equivalent to Oracle's Processor Core Factor of 0.5 for Intel multi-core processors. For AMD EPYC instances (M5a, R5a, etc.), Oracle's Core Factor Table also applies a 0.5 factor, making the calculation identical. For AWS Graviton (ARM) instances, Oracle has not published a Core Factor Table entry — deploying Oracle Database on Graviton under BYOL is not explicitly authorised and should be treated as High Risk without specific Oracle confirmation. Never deploy Oracle software on Graviton or Apple M-series instances without legal and commercial sign-off.
10For Oracle Database on Azure VMs under BYOL, has the Azure instance family been validated against Oracle's Authorised Cloud Environments list, and has the vCPU-to-processor-licence mapping been confirmed for the specific VM series?High Risk
Expert NoteAzure BYOL for Oracle Database follows the same 2-vCPU-per-processor-licence rule as AWS for standard Intel VM families (D, E, F series). Azure M-series (memory-optimised, high vCPU count) instances present Core Factor Table complexity — the factor remains 0.5 for Intel processors regardless of core count, but M-series instances with Intel processors exceeding 64 vCPUs require careful counting. Azure Constrained vCPU VM sizes — where the vCPU count is artificially reduced from the physical core count — use the actual vCPU count for BYOL calculation, not the underlying physical core count. Oracle has confirmed this interpretation explicitly in partner documentation.
11For Oracle Database on GCP under BYOL, has GCP Bare Metal Solution been assessed separately from standard Compute Engine VMs — and has the full-physical-socket licensing requirement for Bare Metal been documented?High Risk
Expert NoteGCP Compute Engine VMs follow the standard 2-vCPU-per-processor-licence BYOL rule. GCP Bare Metal Solution is fundamentally different: Oracle's licensing for physical servers applies, meaning all physical processor sockets on the bare metal server must be licensed — Oracle does not recognise GCP's logical partitioning on Bare Metal as hard partitioning. Enterprises migrating Oracle Database workloads to GCP Bare Metal for performance reasons frequently underestimate processor licence requirements by a factor of 4–8x, because they apply vCPU logic to a physical server environment. Always treat GCP Bare Metal as equivalent to an on-premises server for Oracle licensing purposes.
12For multi-cloud deployments, has a total-cost-of-ownership model been built that compares OCI BYOL (with Support Rewards) against AWS/Azure/GCP BYOL on a fully-loaded licence, support, and infrastructure cost basis?Medium Risk
Expert NoteMulti-cloud Oracle Database deployments are increasingly common, but cross-platform BYOL cost modelling is rarely performed rigorously. A common pattern is AWS primary deployment with OCI as a DR target — this requires BYOL licences for both platforms simultaneously, and the total licence count must cover peak concurrent usage across all environments. OCI's Support Rewards benefit makes this combination commercially attractive: OCI DR deployment costs generate Support Rewards credits that offset Oracle support, effectively making the OCI DR layer partially self-financing. Build a dedicated cross-cloud BYOL model before finalising multi-cloud architecture decisions.
13If the organisation is in an active Oracle ULA, has the agreement been reviewed to confirm whether cloud deployments are included within ULA scope or explicitly excluded?High Risk
Expert NoteOracle ULAs have historically excluded cloud deployments from ULA scope — meaning Oracle Database instances in AWS, Azure, or OCI were not covered by the ULA and required separate BYOL entitlement. More recent ULAs (post-2020) may include cloud-authorised deployment clauses, but these are not standard and must be explicitly negotiated. An enterprise that assumes its ULA covers cloud deployments without verifying the agreement language is typically running unlicensed cloud Oracle deployments that will be discovered at ULA certification. Review every ULA for the cloud deployment clause before migrating Oracle workloads to any cloud platform.
14At ULA certification time, are cloud deployments being excluded from the certification count (if not ULA-scoped) and the corresponding perpetual licence count validated against cloud BYOL requirements post-certification?High Risk
Expert NoteULA certification converts ULA deployment volume into perpetual processor licences. If cloud deployments are excluded from ULA scope, they are also excluded from the certification count — meaning the certified perpetual licence volume must cover the non-cloud deployment only. Post-certification, cloud BYOL must be independently licensed against the certified perpetual licences. The interaction between ULA certification volume and post-certification cloud BYOL is a complex calculation that Redress observes being incorrectly performed in approximately 60% of ULA certifications involving cloud deployments. An independent pre-certification assessment should model this interaction explicitly.
15For Oracle Middleware (WebLogic, SOA Suite, Forms) being ported to cloud under BYOL, has the Middleware BYOL metric been confirmed — Processor licences for WebLogic Server follow the same 2-vCPU rule as Database?Medium Risk
Expert NoteOracle Middleware BYOL follows the same processor licence portability rules as Oracle Database: perpetual licences with active support, edition matching, and the 2-vCPU-per-processor-licence calculation on hyperscalers. A common error is treating WebLogic Server Standard Edition as BYOL-eligible for a WebLogic Server Enterprise Edition deployment — edition matching applies to Middleware as strictly as to Database. WebLogic Suite licences convey rights to additional Oracle products (Coherence, JRF, etc.) that must also be individually validated in the cloud environment. Middleware cloud BYOL assessments are frequently under-resourced in cloud migration projects.
16For disaster recovery environments in cloud (non-production, standby, or passive), has Oracle's Active Data Guard licensing requirement been assessed — Oracle requires EE + ADG licences for active standby databases regardless of whether production is on-premises?Medium Risk
Expert NoteA common misconception is that passive Oracle Database standby instances in cloud DR environments do not require Oracle licensing. Oracle's policy requires that Active Data Guard standby databases — even if never queried outside of failover testing — are licensed with both Oracle Database EE and Active Data Guard Option licences. Physical standby databases in Data Guard configurations that are not opened read-only are not subject to ADG Option licensing, but any read-active standby or automated failover configuration requires the full EE + ADG stack. Validate DR database active status and licensing against Oracle's Data Guard licensing requirements document.
17Has a BYOL entitlement register been created that maps each on-premises perpetual licence to its cloud deployment — platform, instance ID, OCPU/vCPU count, edition, and active support status — updated quarterly?High Risk
Expert NoteThe BYOL entitlement register is the foundational governance document for any cloud BYOL deployment. Without it, the organisation cannot demonstrate to Oracle's GLAS team that BYOL claims are supported by on-premises entitlement. The register must capture: the Oracle CSI (Customer Support Identifier) of each licence, the licence metric and quantity, the cloud platform and instance specification, the vCPU/OCPU count and the resulting processor licence consumption, and the current Oracle support contract status. Redress recommends updating this register at every infrastructure change event and quarterly reconciling it against Oracle's My Oracle Support licence records. Any discrepancy in My Oracle Support should be resolved before Oracle audit notification is received.
18Are cloud infrastructure scaling events (auto-scaling, instance type upgrades) governed by a BYOL impact assessment process — to prevent unlicensed Oracle deployment during peak scaling?High Risk
Expert NoteCloud auto-scaling is the primary BYOL governance failure mode in production environments. An Oracle Database BYOL deployment that is correctly licensed at steady state can become unlicensed during auto-scaling events if additional instances exceed the available BYOL entitlement. Oracle does not provide a grace period for temporary over-deployment — every instance-hour of Oracle Database operation requires licence coverage. Implement a BYOL licence cap in cloud orchestration (AWS Systems Manager, Azure Policy, OCI Governance) that prevents Oracle workload scaling beyond the licenced instance count. Alert on any auto-scaling event that would exceed BYOL limits.
19Are Oracle Support Rewards credits (OCI only) being tracked, invoiced correctly, and applied to Oracle support renewals — with the Support Rewards balance reconciled against OCI BYOL spend?Medium Risk
Expert NoteOracle Support Rewards requires active management: credits are calculated by Oracle monthly based on OCI BYOL usage data, but enterprises must verify that the credit application matches their OCI spend. Discrepancies in Support Rewards credit applications are common when OCI tenancy structures separate BYOL and non-BYOL workloads across compartments — Oracle's reward calculation may miss BYOL usage in nested compartments not properly tagged. Implement OCI Cost Management tagging for all BYOL-eligible Oracle workloads, and reconcile Support Rewards credits against OCI invoices quarterly. Track Support Rewards separately from other Oracle commercial negotiations to preserve optionality in support renewal discussions.
20Has an independent BYOL validation assessment — not relying on Oracle account team guidance — been completed in the past 18 months covering all cloud platforms in scope?Low Risk
Expert NoteOracle's account team is not an independent source of BYOL guidance — it is in Oracle's commercial interest to identify unlicensed deployment rather than confirm compliant deployment. Independent BYOL validation provides two protections: it identifies non-compliant configurations before Oracle's GLAS team does, and it documents a compliance programme that shifts the commercial dynamic when Oracle does engage. An independent assessment covering all cloud platforms, all Oracle products under BYOL, and the interaction between ULA certification and post-certification cloud BYOL should be standard practice for any enterprise with Oracle cloud spending above £250,000 annually.
Building Your BYOL Calculation Model
A compliant Oracle cloud BYOL position requires three components working together: an accurate entitlement baseline (verified perpetual licences with active support), a correct calculation methodology for each cloud platform, and a governance process that maintains compliance through infrastructure changes, scaling events, and licence renewals. Of these, governance is the most frequently neglected — and the most likely to create audit exposure in the 12–36 months following initial migration.
The financial stakes are substantial in both directions. A correctly calculated and governed BYOL position can deliver £1M–£5M in annual cloud licence savings for a mid-large enterprise. An incorrectly calculated BYOL position — or one that drifts out of compliance through ungoverned scaling — creates Oracle audit exposure that typically results in demands exceeding the original cloud savings. The investment in getting BYOL right is almost always justified by the commercial outcome.
Download the Oracle BYOL Assessment Guide →