Placing an Oracle E-Business Suite Estate While Azure Owns the Analytics Layer
Northwind Retail runs Oracle E-Business Suite 12.2 on-premises: a 14 TB database, 1,200 concurrent users across three plants, and a quarter-end batch window that must finish inside six hours. Azure is the company's strategic cloud - the data lake, Synapse, and the new AKS storefront all live there - and the board has committed to exiting the data centre in nine months. Three options are on the table: (a) move the whole EBS stack to an OCI region in Ashburn and connect to Azure with Oracle Interconnect for Azure; (b) adopt Oracle Database@Azure in the same Azure region as the analytics stack and run the application tier on Azure VMs; (c) rehost the database on Azure VMs with premium SSD. A pilot of option (c) ran the nightly batch four times slower than on-premises, and Oracle Support has already questioned whether the EBS application tier is certified on Azure. The DBA team of three knows OCI tooling; the Azure platform team has forty engineers and owns all landing-zone standards. Existing on-premises connectivity is a single 1 Gbps FastConnect that cannot be upgraded before the migration date.
1. Which of the three options should you recommend, and what evidence must exist before the board commits?
Read the worked answer
Recommend option (a): the entire EBS stack, application tier and database, in OCI, with Azure analytics reading across Oracle Interconnect for Azure.
Reasoning chain:
- Option (c) is disqualified twice over: the pilot already shows a 4x batch regression, and EBS is certified on OCI and on-premises, not on Azure VMs. Buying an uncertified platform means every SR becomes a negotiation.
- Option (b) is attractive because Oracle Database@Azure runs in the same Azure region, giving the lowest possible latency to AKS and Synapse. But Database@Azure delivers the database, not the EBS application tier - that still lands on Azure VMs, which is exactly the certification problem you were trying to escape. EBS forms are chatty; splitting the app tier from the database across a cloud boundary adds round trips to every page render.
- Option (a) keeps the certified pairing intact and confines cross-cloud traffic to batch and reporting feeds, which tolerate a few milliseconds.
Evidence to require before sign-off: an OCI benchmark of the quarter-end batch on the target shape and block volume policy; measured round-trip latency over the interconnect at peak; a sizing review with Oracle; confirmation that the 1 Gbps FastConnect can carry the on-premises EBS user traffic plus replication during cutover; and a written licensing position from Oracle LMS.
2. Finance asks whether option (b) is 'cheaper because it is Azure' and whether existing EBS licences can simply be carried to Azure VMs. What is the correct commercial framing?
Read the worked answer
Separate three questions that finance tends to merge.
What is being bought. Oracle Database@Azure is an Oracle Cloud Infrastructure service operated inside Azure data centres and sold through Azure Marketplace. It consumes Azure commitment (MACC) and appears on the Azure invoice, which is why it feels like Azure - but it is an OCI environment for licensing and support purposes, and it is administered through OCI IAM and the OCI Console. Option (a) is billed by Oracle; option (b) is billed by Azure. That difference matters for budget ownership more than for unit price.
Whether existing licences can follow. Running Oracle Database on Azure VMs (option c) places you in an Authorized Cloud Environment, where BYOL is permitted but core counting follows the published core-factor rules; features such as RAC are generally not authorized there - verify with Oracle LMS rather than assuming. Option (b) does not have that problem because the database runs on OCI infrastructure.
The hidden line items. Option (b) still requires Azure VM capacity for the EBS application tier, plus the cross-cloud egress and interconnect cost for batch feeds, plus a second operational skill set. Ask for a three-year total cost of ownership per option, not a per-core price comparison, and insist that the EBS application tier certification question is resolved in writing before any contract is signed.
3. Assuming option (a), who owns what operationally, and where are the support seams?
Read the worked answer
The seam is not the network - it is the change and incident process.
Ownership split:
- OCI side (three DBAs plus a small cloud ops function): EBS application tier, database, FastConnect virtual circuits, DRG, VCN security, OCI Vault keys, backups and patching of the EBS stack.
- Azure side (forty engineers): landing zone, AKS, Synapse, the Azure half of the interconnect, Entra ID as the identity provider for both clouds.
Seams to document explicitly:
- The interconnect itself is ordered through both providers; a circuit-down incident has two vendors and two ticket queues. Write a joint escalation path with named contacts and a target response time, and test it before go-live.
- Identity crosses the boundary: Entra ID federates into OCI Identity Domains, so an Entra outage blocks OCI console access. Keep two break-glass OCI local users in a sealed process.
- Analytics feeds: define the interface contract (schema, delivery time, late-arrival handling) and make one team the owner of the extraction job, not both.
- Monitoring: OCI alarms must route into the same on-call tooling the Azure team uses, or the interconnect will be monitored by nobody at 03:00.
Run a joint game day covering a FastConnect failure and an Entra sign-in outage; the runbooks that fall out of it are the actual deliverable.