Migrating Oracle E-Business Suite, PeopleSoft, JD Edwards, Hyperion, or Siebel to Microsoft Azure creates complex licensing questions. Which technology licences are bundled with the application? What additional licences does Azure require? How do Oracle’s vCPU counting rules apply? This guide gives CIOs the complete framework for licensing Oracle enterprise applications on Azure compliantly and cost-effectively.
Before migrating any Oracle enterprise application to Azure, CIOs must understand the fundamental distinction between application licences and technology licences — because Azure affects them differently.
Rights to use specific business functionality: EBS Financials, PeopleSoft HCM, JD Edwards Distribution. Licensed per user, per employee, or by business metric. These do not change when you move to Azure. Your existing user counts and module licences carry over unchanged.
Rights to use the underlying Oracle Database, middleware (WebLogic, Application Server), and infrastructure tools. Licensed per processor or per named user. These are directly affected by Azure migration because the counting method changes in a cloud/virtual environment.
Some Oracle applications include restricted-use technology licences (e.g., EBS bundles Oracle Database EE and WebLogic). These bundled rights carry over to Azure — but only for the specific application workload. Using them for anything else triggers full licence requirements.
Some applications (PeopleSoft, JD Edwards, Siebel) do not bundle the Oracle Database. You need separate DB licences, and on Azure, these must be sized using Oracle’s cloud vCPU counting rules (2 vCPU = 1 processor licence for most Azure VMs).
“Azure does not change what Oracle applications you are licensed to use. It changes how you must licence the Oracle technology those applications run on. The application licences are the same; the technology licences need recalculation for Azure’s virtual environment.”
Oracle EBS is a special case because Oracle provides certain technology licences bundled with the application purchase. Understanding the scope and limits of these bundled rights is essential for a compliant Azure deployment.
| Component | Bundled with EBS? | Restrictions | Azure Impact |
|---|---|---|---|
| Oracle Database Enterprise Edition | ✅ Yes (restricted use) | Only for EBS data. Cannot host non-EBS schemas or custom applications. | No additional DB licence needed if only running EBS. BYOL the bundled entitlement to Azure. |
| WebLogic / Application Server | ✅ Yes (restricted use) | Only for EBS forms, reports, and standard extensions. Custom Java deployments may require full licence. | Bundled entitlement carries to Azure. Watch for customisations that exceed restricted-use terms. |
| Oracle Database Options (RAC, Partitioning, etc.) | ❌ No | Must be licensed separately if used | Full processor licences required based on Azure vCPU count. RAC is particularly expensive on cloud VMs. |
| Oracle Management Packs | ❌ No | Diagnostics Pack, Tuning Pack, etc. require separate licences | Commonly deployed inadvertently; audit risk. Verify usage before Azure migration. |
Using EBS out-of-the-box with no schema modifications or custom Java deployments. The bundled DB EE and WebLogic licences cover you completely. BYOL these entitlements to Azure VMs. No additional Oracle technology licences required.
Standard customisations (reports, forms, minor Java programs) are generally covered by the bundled entitlements. However, deploying custom Java applications on WebLogic may require a separate WebLogic licence. Review Oracle’s EBS technology rules carefully. See Customised Database Technology & EBS.
If you modify the EBS database schema (adding custom tables, triggers, or non-EBS application schemas), Oracle requires you to purchase full-use Oracle Database EE licences for the entire environment. This eliminates the bundled DB entitlement entirely and can increase costs by $200K–$1M+ depending on Azure VM sizing.
For EBS module details, see Complete Oracle EBS Application Module List and Oracle EBS Price List.
Unlike EBS, PeopleSoft and JD Edwards do not bundle Oracle Database licences with the application. This has material implications for Azure deployments.
| Component | PeopleSoft | JD Edwards | Azure Licensing Impact |
|---|---|---|---|
| Oracle Database | Not bundled. Separate licence required. | Not bundled. Separate licence required. | BYOL existing DB licences to Azure. Size based on vCPU (2 vCPU = 1 processor). Or use a non-Oracle DB where supported. |
| WebLogic / Tuxedo | PeopleTools includes restricted-use WebLogic and Tuxedo | JDE Tools includes restricted-use middleware | Bundled middleware carries to Azure for application use. Custom deployments may require full licence. |
| Application licences | Per-user or per-employee. Unchanged on Azure. | Per-user or per-employee. Unchanged on Azure. | No change. Existing user counts and modules carry over. |
| Non-Oracle DB option | Microsoft SQL Server supported for some versions | Microsoft SQL Server supported for some versions | If using SQL Server on Azure, no Oracle DB licence needed. Use Azure SQL or SQL Server on Azure VMs. |
Beyond EBS, PeopleSoft, and JD Edwards, enterprises commonly run other Oracle applications on Azure. Each has its own licensing characteristics.
Hyperion requires a separate Oracle Database licence (not bundled). On Azure, licence the DB based on vCPU count. Hyperion application licences (per-user) are unchanged. OBIEE components may require additional WebLogic licensing.
OBIEE includes restricted-use WebLogic but requires a separate Oracle Database for the repository. On Azure, ensure the OBIEE repository DB is properly licensed. Named user or processor licensing applies to the OBIEE application itself.
Siebel does not bundle the Oracle Database. Separate DB licences required on Azure. Siebel application licences (per-user or per-seat) carry over unchanged. Siebel’s web server components (Oracle HTTP Server) may have restricted-use entitlements.
Oracle’s identity and access management products require separate Oracle Database and WebLogic licences. On Azure, these must be sized per vCPU. Often overlooked in compliance assessments because they run as infrastructure rather than business applications.
Oracle Management Packs (Diagnostics Pack, Tuning Pack) are the most common hidden compliance risk when migrating any Oracle application to Azure. These packs are often enabled by default in Oracle Database installations but require separate per-processor licences. A single 8-vCPU Azure VM running Oracle DB EE with Diagnostics and Tuning Packs enabled represents 4 processor licences × 2 packs = 8 additional licence entitlements. At list price, this can exceed $200K. Disable packs you are not licensed for before migrating to Azure.
Oracle’s cloud licensing policy determines how many processor licences are needed based on the Azure VM’s virtual CPU count. Understanding this formula is essential for accurate cost modelling.
| Azure VM Type | vCPU Hyper-Threading | Oracle Licence Calculation | Example |
|---|---|---|---|
| Standard VMs (most types) | Hyper-threaded (2 threads per core) | 1 processor licence per 2 vCPUs | 8 vCPU VM = 4 processor licences |
| Constrained-core VMs | Hyper-threaded but fewer active vCPUs | Based on available vCPUs, not physical cores | E16-4as_v5 (4 active vCPUs) = 2 processor licences |
| AMD EPYC VMs | Check specific VM series | Same 2:1 ratio applies | Standard_E8as_v5 (8 vCPU) = 4 processor licences |
For the complete Azure licensing framework, see Oracle Licensing on Azure — Comprehensive Guide and BYOL vs Licence-Included on Azure.
Most enterprises migrating Oracle applications to Azure use the Bring Your Own Licence (BYOL) model — applying existing on-premises Oracle licences to Azure VMs. This is permitted under Oracle’s cloud licensing policy for Azure as an “authorised cloud environment.”
Your existing Oracle licence entitlements must cover the Azure vCPU count using Oracle’s 2:1 ratio. If you had 4 processor licences on-premises (covering an 8-core server), those same 4 licences cover an 8-vCPU Azure VM. However, if you scale to a 16-vCPU VM, you need 8 licences — 4 more than you own.
Oracle requires that all licences brought to Azure have active support and maintenance (S&M) contracts. Licences without active S&M cannot be used on Azure. This means you cannot BYOL unsupported or “shelved” licences. Verify your S&M status before planning the Azure migration.
If licensing by Named User Plus rather than Processor, Oracle enforces minimums (e.g., 25 NUP per processor for Database EE). On Azure, the processor count is derived from vCPUs. A 4-processor-equivalent Azure VM requires a minimum of 100 NUP licences for Database EE, regardless of actual user count.
For BYOL strategy guidance, see BYOL vs Licence-Included on Azure.
Oracle audits following Azure migrations are increasingly common. Below are the compliance risks specific to running Oracle enterprise applications on Azure.
The most expensive risk. If your EBS database contains non-EBS schemas or custom objects that violate restricted-use terms, the bundled DB licence is void and full Enterprise Edition processor licences are required. On a 16-vCPU Azure VM, this is 8 × $47,500 = $380K at list price — plus 22% annual maintenance.
Diagnostics Pack, Tuning Pack, Advanced Compression, Partitioning, and other DB options are frequently enabled by default. Each requires a separate processor licence. Oracle’s audit scripts detect these automatically. Disable or licence before migration.
Each additional vCPU increases licence requirements. Over-provisioned Azure VMs that were sized “for safety” create licence shortfalls. Oracle counts the allocated vCPUs, not actual utilisation.
If Azure VM scale sets or burstable VMs are used, Oracle may claim the peak vCPU count as the licensing basis. Avoid auto-scaling for Oracle workloads unless your licence pool covers the maximum possible allocation.
Licences with lapsed S&M contracts cannot be used on Azure under BYOL. Oracle will count them as unlicensed deployments. Verify S&M status for every licence before migration.
In our advisory practice, the average Oracle compliance finding for an Azure-migrated EBS environment is $400K–$1.2M. The primary drivers are voided bundled entitlements (custom schemas in the EBS database) and unlicensed database options. Both are entirely preventable with a pre-migration compliance assessment. The assessment typically costs 2–5% of the finding it prevents.
Moving Oracle applications to Azure creates several optimisation opportunities that can significantly reduce total licensing costs.
Use Azure constrained-core VM sizes to reduce vCPU count (and therefore Oracle licence requirements) while maintaining full memory allocation. A constrained 4-vCPU VM with 128GB RAM requires only 2 Oracle processor licences vs 8 for a standard 16-vCPU VM with the same memory.
For PeopleSoft, JD Edwards, and Siebel, evaluate replacing Oracle Database with SQL Server on Azure. Eliminates Oracle DB licensing entirely. Not available for EBS (which requires Oracle DB).
Isolate Oracle Database on the smallest possible Azure VM. Run application servers, web servers, and batch processing on separate VMs that may not require Oracle licensing. This minimises the processor count subject to Oracle fees.
When decommissioning on-premises Oracle servers during Azure migration, harvest the freed processor licences and reallocate them to Azure. Ensure the total processor count covers Azure vCPUs at the 2:1 ratio.
Situation: A US financial services company running EBS Financials, PeopleSoft HCM, and Hyperion on-premises planned migration to Azure. The initial Azure sizing called for 64 vCPUs across database and application VMs, requiring 32 Oracle processor licences — 12 more than their existing 20.
Approach: The licensing team (a) cleaned EBS database of non-EBS schemas to preserve bundled entitlements, (b) switched PeopleSoft to SQL Server on Azure (eliminating 8 Oracle DB licences), (c) used constrained-core VMs for EBS DB (reducing from 16 to 8 vCPUs), and (d) disabled unused database options (Diagnostics/Tuning Packs).
Oracle and Microsoft have established a strategic partnership (Oracle Database@Azure / OCI-Azure interconnect) that affects licensing options for Oracle workloads on Azure.
Oracle Database running on Oracle Exadata hardware hosted in Azure data centres. Licensed as OCI (Oracle Cloud Infrastructure), not as Azure BYOL. This means Oracle’s OCI licensing terms apply (OCPU-based), which can be more favourable than Azure vCPU counting for some workloads. Available for DB-only workloads; applications run on Azure VMs and connect via low-latency interconnect.
Standard approach: run Oracle applications and databases on Azure IaaS VMs using your own Oracle licences. Oracle’s standard cloud licensing policy applies (2 vCPU = 1 processor). This is the most common model and the focus of this guide.
Run Oracle Database on OCI and application tiers on Azure, connected via a dedicated low-latency interconnect. This can be cost-effective because OCI’s BYOL terms are more generous for Oracle Database. However, it adds architectural complexity and cross-cloud networking costs.
For Oracle cloud licensing options, see Oracle Cloud Licensing Guide and Oracle Universal Credits Guide.
Below is the complete licensing checklist for migrating Oracle enterprise applications to Azure.
List every Oracle product in scope: application modules, database edition, database options, middleware, and management tools. Include products that may be installed but not actively used — Oracle licences installed products, not just used ones.
For EBS: confirm the database contains only EBS schemas. For PeopleSoft/JDE: confirm middleware is restricted-use only. For all apps: identify which technology licences are bundled vs separate. Document findings.
Run Oracle’s DBA_FEATURE_USAGE_STATISTICS query to identify enabled database options and management packs. Disable anything not explicitly licensed. This is the single highest-ROI compliance action.
Benchmark workloads and select the smallest Azure VM that meets performance requirements. Use constrained-core VMs for memory-intensive Oracle Database workloads. Every 2 vCPUs saved = 1 fewer processor licence needed.
Map Azure VM vCPU counts to Oracle processor licences (2:1 ratio). Compare against your existing entitlements. Identify any shortfall or surplus. If NUP-licensed, verify minimums are met.
For PeopleSoft, JD Edwards, and Siebel: assess whether SQL Server on Azure is a viable alternative. If so, the Oracle Database licence requirement is eliminated entirely. Factor migration effort against multi-year licence savings.
Confirm all Oracle licences to be BYOL’d have active S&M contracts. Reinstate lapsed S&M before migration. Licences without active S&M cannot be legally deployed on Azure.
Create a formal BYOL mapping document: on-premises licence entitlements → Azure VM assignments → processor licence calculations. This document is your audit defence. Keep it updated as VMs are resized.
If a shortfall exists, negotiate additional licences with Oracle before migration. Time the purchase for Oracle’s fiscal year-end (May) for maximum discount. Consider an ELA or ULA if the shortfall is substantial. See Oracle Contract Negotiation Service.
After successful Azure migration, decommission the on-premises Oracle servers. Formally document the decommission and reallocate the harvested licences to the Azure pool. Reduce S&M on any surplus licences that are no longer needed.