Part 2: Oracle EBS Economics: Oracle on Azure VMs vs Oracle Database@Azure — A Real TCO Comparison

In Part 1, we outlined the architectural “trap” that keeps Oracle E-Business Suite (EBS) anchored on-premises: generic cloud VMs force you to over-provision CPUs just to meet memory requirements, triggering an avalanche of Oracle software licensing costs.

But theory is one thing; actual cloud bills are another. To truly understand the financial impact of this trap—and how Oracle Database@Azure solves it—we need to look at the cold, hard numbers.

Drawing from a real-world analysis, let’s break down the economics of migrating a complex Oracle workload to the cloud. We will compare a traditional “Azure Native” approach (Oracle on standard Azure VMs) against the consolidated power of Oracle Database@Azure backed by Exadata.

The Customer Landscape

When we talk about an EBS migration, we are rarely talking about a single database. For this customer, the production landscape was a sprawling ecosystem. It included the core EBS application, Identity Management (IDM), SOA, BI, and change management, alongside custom applications like XX1, XX2, and planning ASCP.

But the real story is in the last column: # of Test/Dev. That ‘5’ for the core EBS database means for every one production environment, there are five non-production copies. In a traditional on-prem world, this might be managed with storage snapshots or clever cloning. In a “lift and shift” cloud model, this often translates to five additional sets of VMs, each triggering its own infrastructure and potential software licensing costs.

After reviewing the AWR and SAR statistics, we have a clear picture of CPU and disk requirements for this workload. We are not planning to size the cloud to match the on-premises architecture.

Scenario 1: The Azure-Native VM “Lift and Shift”

If we attempt a traditional lift-and-shift of this footprint into standard Azure Virtual Machines, the architecture quickly becomes a game of “VM Tetris.”

To meet the high I/O and memory demands of Oracle databases, the customer is forced into massive, costly VM shapes (like the M32-LS and M16-MS series) across their Production, UAT, and DR environments. Because Oracle’s cloud licensing policy does not allow the use of the Processor Core Factor Table in authorized public clouds, the customer has to license every single vCPU on those massive VMs.

The result is a complex web of VMs for Production (ORAP prefix), Test/UAT (ORAT), and Disaster Recovery (ORADR).

The Year 1 financial impact is staggering. While the raw cloud infrastructure costs between the two architectures are relatively similar, the Azure VM approach triggers a massive licensing penalty. To legally run this sprawling VM architecture, the Year 1 total cost included a new license purchase of over 1.6M (with recurring support at around 300,000, growing at 8% year-over-year).

Also note that Real Application Clusters (RAC) was the HA solution on-premises, and RAC is not part of Azure-native VMs, as it is not supported. For high availability in the VM model, we need to stand up a Data Guard-protected instance. This often means a second, fully-licensed VM, effectively doubling your production Oracle license costs for HA before you even consider disaster recovery.

Scenario 2: The Database@Azure Consolidation Play

Now, let’s look at the alternative: Oracle Database@Azure, specifically using the Exadata Database Service.

Instead of deploying dozens of oversized, underutilized Azure VMs, we consolidate the entire database estate onto Exadata infrastructure, colocated right inside the Azure data center. Using an X11M Elastic Configuration, we carve out highly dense, dedicated clusters. We deploy one VM cluster dedicated to Production in Region 1. In Region 2, a second Exadata system hosts a consolidated Non-Production cluster (for all Test/Dev/UAT workloads) and serves as the Data Guard standby target for the production databases.

This isn’t just a technical win; it completely rewrites the economics. Because Exadata is engineered specifically for Oracle workloads, you achieve extreme performance without the CPU bloat. You only provision and enable the OCPUs (Oracle CPUs) you actually need, licensing them with BYOL or a new subscription. Since the storage has intelligence and understands Oracle workloads, the compute layer’s CPU requirements are much lower than those of commodity hardware or non-Exa cloud VMs.

Furthermore, the PaaS (Platform as a Service) nature of Exadata Database Service means critical security and management features are included at no additional cost. You get Transparent Data Encryption (TDE) for tablespaces, Diagnostics, Tuning, Real Application Testing, and Data Masking. In a native VM build, these are premium add-ons that drive up your bill and your DBA’s workload.

The 5-Year Verdict: 44% Savings

When you project these two architectures over a five-year lifecycle, the “CPU Tax” of the native VM approach becomes impossible to ignore.

• 5-Year TCO for Azure Native (Oracle on VMs): $8,970,000
• 5-Year TCO for Oracle Database@Azure (ExaCS): $5,010,000

By migrating to Database@Azure and consolidating on Exadata, the customer avoids the licensing trap and achieves over 44% in total savings (nearly $4 million) over five years. And the performance improvement is an added bonus. Most batch programs and integration jobs complete in a fraction of the time they used to take on-premises.

The TCO figures here are not just database service costs. The model includes the full supporting stack typically required for an EBS/Oracle estate in Azure, including:

In other words, the $8.97M vs $5.01M comparison reflects an all-up platform view, not a narrow “database-only” comparison.

The Bottom Line

If there’s one lesson here, it’s this: cloud economics are rarely determined by the cost of compute hardware alone. They’re determined by how efficiently your software can use that hardware—and whether your architecture forces you to pay for capacity (and licenses) you don’t truly need.

But the win isn’t only about cost.

Once the Oracle databases were migrated to Oracle Database@Azure, the customer also gained a more natural integration path to the rest of their Azure ecosystem. With the database platform living inside Azure datacenters, it becomes much easier to connect into Azure services for BI/reporting and to modern data platforms like Snowflake—especially when you leverage real-time replication services like OCI GoldenGate, which integrates seamlessly with Database@Azure to stream data from the ERP core into analytics platforms. The highlight is the operational simplicity: fewer brittle network workarounds, fewer “special integration islands,” and a cleaner path for real-time data movement from the ERP core.

In other words: Database@Azure improved both sides of the business case—it reduced the licensing-driven oversizing that inflated TCO, and it made the Azure integration story feel seamless instead of stitched together.

Up Next in Part 3: The economic win is clear, but what about risk? Consolidating your entire database estate onto a single platform can feel daunting. In Part 3, The Resilient ERP, we’ll dive into how the Database@Azure architecture—including Data Guard, RAC, and the integrated Autonomous Recovery Service—actually strengthens your backup, recovery, and cyber-resiliency posture, turning a perceived risk into a strategic advantage.