Part 1: The EBS Cloud Reality Check — Why “Lift and Shift to VMs” Doesn’t Work for ERP

If you’ve spent any significant time managing Oracle E-Business Suite (EBS), there’s an uncomfortable truth that EBS teams know well: it’s not a workload you casually split across network boundaries. Latency gets blamed most often, but the real reason EBS has historically stayed anchored on-prem is a three-part trap: punishing licensing math, rigid VM sizing, and the non-negotiable requirement for tier co-location. Get any one of these wrong, and the business case collapses—or worse, you end up paying more in the cloud than you did on-prem.

This series focuses on EBS 12.2 running on Oracle Database 19c—the current supported release and the standard deployment target for Database@Azure. 

EBS isn’t just an app and a database. It’s an ERP gravity well. Consider the “satellites” that orbit the core system:

• Tax engines (like Vertex or Avalara)
• Barcode and label printing systems
• Integration runtimes and file-based interfaces
• BI and reporting feeds

These satellites aren’t optional, and the architecture assumes everything lives in the same low-latency domain. Split the ERP island, and you don’t just risk slower forms—you risk operational coupling failures that show up at the worst possible times: month-end close, payroll runs, order-to-cash cycles that depend on sub-second round-trip times between the application tier and the database.

The T-Shirt Size Trap Becomes a Licensing Trap

In Azure, Virtual Machines come in “T-shirt sizes.” For typical stateless web workloads, that’s convenient. For EBS databases, it can be punishing.

EBS databases are notoriously memory-hungry and I/O intensive. The VM family that finally meets your memory target almost always drags a massive CPU footprint along with it. If your Oracle licensing is core-based, you end up paying steep Oracle software costs for “ghost” CPUs you didn’t actually need—just to buy the RAM you did.

Consider a mid-size EBS database that requires 768GB of RAM and moderate CPU utilization—say, 16 cores of actual sustained demand. On Azure, meeting that memory requirement pushes you into an M-series VM with 96 vCPUs. Under Oracle’s Authorized Cloud Environment licensing policy, every 2 vCPUs equals 1 processor license. That’s 48 processor licenses—for a workload that genuinely needs 16 cores of compute. You’re licensing at 3x your actual CPU requirement, purely because of the memory-to-CPU ratio of the available VM shapes.

There is a second nuance that makes the math even more painful—especially for customers migrating from Unix platforms. On-prem, many infrastructure teams rely on the Oracle Processor Core Factor Table to reduce license counts. Customers running on SPARC (core factor 0.25) or POWER (core factor 1.0) platforms have historically benefited from favorable multipliers that significantly reduce the number of processor licenses required.

When moving to Azure VMs, Oracle’s Authorized Cloud Environment policy applies a fixed counting rule: 2 vCPUs = 1 processor license (for hyper-threaded x86). Customers migrating from non-x86 platforms with favorable core factors can see their license requirements increase significantly—sometimes doubling—for the same effective compute capacity. And unlike on-prem, where hard partitioning (Oracle VM, Solaris Zones) can limit the licensable footprint, Azure VMs require you to license every vCPU allocated to the instance.

The Constrained vCPU “Gotcha”: Azure offers constrained vCPU VM variants—instances that retain full memory allocation while reducing the active vCPU count (for example, a 96-vCPU class VM constrained to 48 active vCPUs). These look like the perfect technical fix for memory-heavy databases.

Oracle’s cloud licensing policy does reference vCPU counts as the licensing basis, and recent guidance suggests constrained counts may be recognized. However, interpretations have shifted over time, and enforcement can vary. Most enterprise customers treat this as a conversation to have with Oracle licensing specialists before committing to a deployment model—not an assumption to build a business case on.

That’s the CPU tax: in the wrong architecture, your Oracle software cost will rapidly eclipse your infrastructure cost.

The Shift: Oracle Database@Azure is Not “Oracle on a VM”

Attempts to split the difference—running the EBS application tier in Azure and the database elsewhere—tend to fail in production reality. EBS must move as a cohesive unit.

This is why Oracle Database@Azure fundamentally changes the playbook. It is Oracle delivering OCI-managed database services—on Exadata infrastructure—physically colocated inside Azure datacenters. You provision the infrastructure through the Azure portal and Azure APIs; it appears as a native Azure resource, billed on your Azure invoice. Deeper database management—patching, Data Guard configuration, performance diagnostics—is handled through the OCI console, accessible directly from the Azure portal.

For EBS, this means you can move the entire ERP island into an Azure region without violating the physics of tier co-location, and without forcing your database into generic VM sizing patterns that create licensing waste.

And for Azure-first organizations with existing Microsoft commitments, there’s a commercial detail that matters: Database@Azure spend counts toward your Microsoft Azure Consumption Commitment (MACC). Your Oracle database infrastructure cost draws down the same Azure commitment you’re already managing—no separate Oracle infrastructure contract required. We’ll cover the commercial mechanics in detail in Part 2.

How It Actually Connects: The Network Architecture

Understanding why Database@Azure delivers sub-millisecond latency to the EBS application tier requires a look at how the networking works—because this is fundamentally different from the older OCI–Azure Interconnect model.

In the Interconnect model (still available, but not what we’re discussing in this series), traffic between Azure and OCI traversed a cross-cloud network link between separate datacenters. Latency was typically 1.5–2ms—workable for some applications, but too high for EBS forms, concurrent managers, and high-frequency PL/SQL calls that can generate thousands of database round trips per user session.

Database@Azure eliminates that gap entirely. Oracle Exadata infrastructure is physically deployed inside Azure datacenters. Connectivity between your Azure VMs (running the EBS application tier) and the Database@Azure instance uses a delegated subnet within your existing Azure Virtual Network (VNet). Traffic never leaves the Azure datacenter fabric. Measured latency is typically under 0.5ms—comparable to what you’d see between two Azure VMs in the same VNet.

• Your Azure VNet contains your standard subnets for EBS application tier VMs, bastion hosts, load balancers, and any adjacent services (tax engines, reporting, integration runtimes).
• A delegated subnet is created within the same VNet, specifically for Database@Azure. This subnet is delegated to the Oracle.Database/networkAttachments resource provider.
• The EBS application tier connects to the database using standard Oracle Net (TNS) over this private network path. No public endpoints, no internet traversal, no VPN tunnels.
• Network Security Groups (NSGs) can be applied to control traffic flow, and standard Azure routing and DNS resolution apply.

The practical result: your entire EBS estate—application tier, database tier, and all adjacent satellite systems—lives within a single Azure VNet in a single Azure region. From a network topology perspective, it looks and behaves like a fully Azure-native deployment. The fact that the database tier runs on Oracle-managed Exadata hardware is transparent to the application layer.

Right-Sizing the Estate: Choosing Your Service Tier

It’s important to say this plainly: Exadata isn’t the right starting point for every EBS customer. For smaller enterprises or smaller database estates, Exadata capacity and cost can be overkill.

Exadata Database Service for Large Estates: For large EBS environments—those with databases exceeding multiple terabytes, heavy concurrent user loads, and demanding batch processing windows—Exadata Database Service (ExaDB-D) on Database@Azure is the natural fit. You get dedicated Exadata infrastructure with the I/O performance, Smart Scan offloading, and storage compression that EBS database workloads benefit from. Compute and storage scale independently, which directly addresses the T-shirt sizing trap: you allocate the memory and OCPUs your workload actually needs, not what a generic VM shape forces on you.

Base Database Service for Smaller Estates and Non-Prod: This is where Oracle Base Database Service on Database@Azure becomes a highly pragmatic option. It provides broader choices across Oracle database services natively in Azure. The key advantage—especially for Bring Your Own License (BYOL) customers—is that you provision the database capacity you actually intend to license, rather than being forced into an oversized Azure VM. Base Database Service utilizes BYOL consumption pricing (ECPU-based) and is positioned specifically as a lower-cost, highly flexible way to run Oracle Database. You still get the integrated Database@Azure operating model, but with a service tier that naturally aligns to the size of your environment.

We’ll explore the full service catalog—including Exadata Database Service on Exascale, which introduces elastic, granular scaling for mid-size estates—in Part 5.

Operations: Azure Teams Don’t Have to Become OCI Experts

A common operational fear is: “Do my Azure engineers now need to learn OCI?”

The short answer is no. Microsoft and Oracle have established a clear division of labor. You provision Oracle Database@Azure using the Azure portal and Azure APIs, and the infrastructure/cluster resources are managed natively in Azure. Meanwhile, deeper database management tasks can be performed using the OCI console or using your current familiar tools.

This split maps perfectly to how real enterprise teams actually work:

• Azure Cloud Engineers stay in Azure for provisioning, network routing, monitoring, and broader operational workflows. Database@Azure resources appear as native Azure resource types, manageable through the Azure portal, CLI, ARM templates, and Terraform AzureRM provider.
• DBAs use OCI-side tooling when they need deeper database performance troubleshooting, patching, and Oracle-native diagnostics. This is accessed directly from the Azure portal via a linked OCI console—no separate OCI tenancy setup or credential management required for basic operations.

OEM for EBS Operations

For EBS-specific operations, Oracle Enterprise Manager (OEM) remains the primary management tool—and it works with Database@Azure exactly as it does with any other Oracle database. OEM runs on an Azure VM alongside the EBS application tier and connects to the Database@Azure instance over the same low-latency private network. Your EBS DBAs’ existing OEM workflows—concurrent manager monitoring, workflow mailer management, EBS patching and cloning operations, AD/TXK administration—carry forward unchanged.

A Note on Identity and Governance

One operational detail worth flagging early: Database@Azure operates across two control planes. Azure Entra ID (formerly Azure AD) governs portal access and resource-level RBAC. OCI IAM governs database-level administration policies. In practice, this means your cloud platform team manages access and governance in Azure as they do for any other Azure resource, while your DBA team gets a linked OCI tenancy for database operations. We’ll cover the identity and governance model in detail in Part 5.

It’s a practical workflow that maps to how real enterprise teams actually work—and it prevents the “everyone must retrain on everything” fear from blocking your cloud migration.

The Bottom Line

EBS becomes “legacy” when it is trapped behind aging hardware and a cloud sizing model that punishes memory-heavy databases. The blocker was never “the cloud” itself—it was the mismatch between EBS reality and generic VM economics.

Oracle Database@Azure—whether Exadata Database Service for large production estates or Base Database Service for smaller environments—finally creates a credible Azure-first path to move EBS forward: without splitting tiers, without paying for capacity you don’t actually use, and with your Oracle database spend counting toward the Azure commitments you’re already managing.

In Part 2, we’ll put real numbers behind this—comparing the total cost of ownership for EBS on Azure VMs versus Database@Azure, and showing where the economics decisively shift.