The Last Datacenter Exit: Migrating Oracle E-Business Suite to Azure with Database@Azure

For years, “Azure-first” organizations had a last holdout in their cloud portfolio: Oracle E-Business Suite (EBS). While web apps, data platforms, and modern microservices moved to Azure with relative ease, EBS often stayed behind—tethered to the real-world economics of Oracle licensing, workload sizing, and the unforgiving performance requirements of a tightly coupled ERP stack.

When a customer says “we still have legacy on-prem,” they usually don’t mean a lonely Oracle database sitting on commodity servers. They mean something much bigger: the entire EBS domain never moved. That includes the EBS application tier, the database tier, and the adjacent systems that must remain close for performance and operational reasons—tax calculation services, barcode/label solutions, BI/reporting pipelines, interface runtimes, and the file-based workflows that still power real-world ERP processes. And they stayed together for a simple reason: EBS is latency-sensitive by design. Split the tiers and performance suffers fast.

As we move through 2026, a practical answer is emerging. The Oracle–Microsoft partnership has matured from “interconnect and coexist” to something far more actionable: Oracle Database@Azure—Oracle Exadata-based database services running in Azure datacenters, deployed on Oracle Cloud Infrastructure (OCI) hardware, yet accessible directly from Azure VNets with sub-millisecond network latency. The infrastructure is managed by Oracle; the consumption appears on your Azure bill. The earlier OCI–Azure Interconnect was a start, but cross-region latency made it impractical for latency-sensitive workloads like EBS. Database@Azure changed the equation by placing Oracle infrastructure in Azure data centers.

In the Database@Azure model, the EBS database tier runs on Oracle-managed Exadata infrastructure inside Azure. The EBS application tier—concurrent managers, forms/web servers, and adjacent services—runs on standard Azure VMs (typically E-series or D-series Linux instances) in the same Azure VNet, connected to the database via the low-latency private fabric.

This series explores why Oracle Database@Azure is emerging as the most realistic bridge for EBS: it enables enterprises to keep their ERP core intact, keep tiers co-located for performance, and still close the door on the last remaining dependency on aging datacenter infrastructure—without forcing an OCI migration decision.

Over the next five parts, we’ll walk through the decisions that actually matter.

In Part 1, we’ll unpack the EBS architectural dilemma beyond “latency is bad.” We’ll get specific about the “T-shirt sizing” trap—where high-memory ERP workloads can force oversized compute footprints, driving up both infrastructure and licensing exposure.

In Part 2, we’ll go deep on the economics. We’ll compare the real TCO of “Azure-native Oracle” (Oracle on VMs) versus the performance-weighted value of Oracle Database@Azure, including what changes when Exadata-class database capabilities show up inside Azure.

In Part 3, we’ll focus on resiliency and recovery—because modernizing ERP without modernizing recovery is only half a migration. We’ll cover Zero Data Loss Autonomous Recovery Service in the Database@Azure ecosystem: how it simplifies backup operations, improves recoverability with automated validation, and strengthens cyber-resiliency planning (including ransomware scenarios).

In Part 4, we’ll tackle the platform migration problem that many EBS shops still face: moving from legacy Unix (Solaris, HP-UX, AIX) to Azure-standard Linux footprints while shrinking cutover windows and keeping functional risk manageable.

And in Part 5, we’ll demystify the catalog—database service options and licensing choices available within Oracle Database@Azure, including BYOL and license-included paths, and how to think about them for prod vs non-prod estates.

The result: organizations can finally decommission their last on-premises Oracle footprint, consolidate to a single cloud operational model, and do it without the risk of a full OCI migration or the performance penalties of a split-tier architecture.