CIO Playbook: Oracle Cloud@Customer Deployment Strategy

What Is Oracle Cloud@Customer?

Oracle Cloud@Customer is a family of infrastructure services that Oracle deploys, owns, and operates inside your data centre. Rather than migrating workloads to Oracle's public cloud regions, you receive the equivalent cloud hardware and software on your own premises — Oracle retains ownership and operational responsibility for the equipment while you consume services billed on a subscription model. The result is a hybrid delivery model that preserves data sovereignty without sacrificing access to Oracle's cloud automation, patching, and managed service capabilities.

The primary Cloud@Customer offering for database workloads is Exadata Cloud@Customer — an Exadata X10M system managed by Oracle as a cloud service in your data centre. For general compute workloads, Compute Cloud@Customer extends OCI compute, storage, networking, and Kubernetes services into your facility. For organisations requiring a full OCI region footprint on-premises, OCI Dedicated Region provides the complete public cloud stack, starting at a five-year commitment of approximately $5 million.

All three offerings share the same core value proposition: data never leaves your premises, you meet local data-residency and sovereignty requirements, and you gain access to Oracle's cloud automation and support model — without ceding physical custody of your infrastructure. Understanding where each offering is appropriate, and where the commercial risks concentrate, is the foundation of a sound Cloud@Customer strategy.

Why CIOs Choose Cloud@Customer

The primary use cases driving Cloud@Customer adoption are data residency regulation, latency sensitivity, large existing Oracle investments, and compliance requirements that preclude public cloud deployment. Financial services firms under GDPR, DORA, or local banking regulations frequently cannot place database workloads in a multi-tenant public cloud region. Healthcare organisations with strict data-sovereignty mandates face the same constraint. Defence contractors and public sector entities often operate in air-gapped or restricted-connectivity environments where public cloud access is structurally impossible.

For these organisations, Cloud@Customer provides the operational model and tooling of OCI without the data transfer to Oracle's facilities. The licensing and commercial model, however, requires careful navigation to avoid paying significantly more than an equivalent self-managed on-premises deployment. The cloud subscription wrapper can obscure a cost structure that, without active commercial management, escalates faster than traditional on-premises alternatives.

Deployment Architecture: Exadata Cloud@Customer X10M

The current generation — Exadata Cloud@Customer X10M — represents a material architectural advance over the X8M and X9M generations. The system runs a 100 Gbps RDMA over Converged Ethernet (RoCE) internal network fabric that connects database and storage servers with extremely low latency. This fabric enables the storage offload, Smart Scan, and IORM capabilities that differentiate Exadata performance from standard database server configurations running equivalent software.

Rack Configurations and Scale

Exadata Cloud@Customer X10M is available in configurations scaled from a base system through to full rack deployments. The base configuration — two database servers and three storage servers — is the starting point for most deployments, equivalent in compute to a quarter-rack in previous-generation terminology. Organisations scale horizontally by adding database and storage servers, with a fully expanded X10M system supporting up to 32 database and 64 storage servers across multiple racks. This provides up to 6,080 usable database server cores, 87.5 TB of usable database server memory, 2,880 GB/sec analytics throughput, and 5 PB usable storage capacity.

From a licensing perspective, the ability to start small is significant. Beginning with the base configuration allows an organisation to license only the OCPUs actually in use, then scale as business requirements grow. Every additional OCPU activated requires corresponding licence coverage, so capacity planning and licence planning must proceed in tandem from day one of the deployment programme.

Control Plane Architecture

Oracle deploys two Control Plane Servers (CPS) in your data centre alongside the Exadata hardware. These servers form the bridge between your on-premises environment and the Oracle Cloud Infrastructure control plane in a designated OCI region. The CPS handles cloud automation, lifecycle management, patching scheduling, health telemetry, and monitoring integration — all the operational functions that would otherwise require dedicated on-premises engineering effort.

The CPS requires four uplinks (two per server) to your corporate network. Supported connection types include 10 Gbps RJ45 copper, 10 Gbps SFP+ fibre, and 25 Gbps SFP28 fibre. Outbound TCP port 443 access to five specific OCI endpoints in your designated OCI region is mandatory — without this connectivity, cloud automation and management capabilities do not function. The minimum bandwidth requirement is 50/10 Mbps download/upload. Oracle does not require inbound TCP port 443 access, which satisfies most enterprise security policies without architectural exceptions.

In isolated mode — available as of October 2025 — Oracle supports deployments in environments with strict security requirements, disconnected from the internet and from your OCI tenancy. This mode enables Exadata Cloud@Customer deployment in air-gapped, classified, or high-security environments where continuous OCI connectivity is structurally not permitted. This is a significant development for defence, intelligence, and sovereign cloud deployments that previously could not consider the Cloud@Customer model at all.

Licensing Models: BYOL vs Licence-Included

The licensing model you select for Exadata Cloud@Customer is the single most consequential commercial decision in the entire deployment. The two options — Bring Your Own Licence (BYOL) and Licence-Included — carry dramatically different costs and create different commercial dynamics in your Oracle relationship going forward.

Bring Your Own Licence (BYOL)

Under BYOL, you apply existing Oracle Database Enterprise Edition and Database Option licences against the OCPUs provisioned on your Exadata Cloud@Customer system. The cloud infrastructure subscription costs are substantially lower as a result. Oracle's published data indicates that BYOL reduces Autonomous Database compute costs by approximately 76% compared to the licence-included rate. On Exadata Cloud@Customer, the BYOL rate is roughly one-quarter of the licence-included list price for equivalent compute capacity.

BYOL is the correct choice for organisations that already own sufficient Oracle Database Enterprise Edition licences from on-premises deployments. If you are consolidating workloads from servers that were previously running Oracle databases with active support contracts, those licences can be applied to Cloud@Customer at full BYOL value. Oracle permits complete licence mobility between on-premises environments, Oracle Cloud Infrastructure, and Oracle Cloud@Customer. Adopting Cloud@Customer does not lock your licences into the cloud deployment — they remain portable across your estate.

A critical qualifier applies: only active, fully supported licences qualify for BYOL. Licences on expired or lapsed support contracts cannot be moved to cloud environments under Oracle's BYOL terms. Before finalising your BYOL strategy, commission an independent audit of your exact support status across every licence pool you intend to apply. Discovering a lapsed support contract after contract execution is a costly and avoidable mistake.

Licence-Included

Under the licence-included model, Oracle's subscription rate covers both infrastructure and database software licensing. There is no separate on-premises Oracle licence requirement, and no support contract to maintain alongside the cloud subscription. This model suits organisations that do not own Oracle Database Enterprise Edition licences and are starting a net-new Oracle cloud deployment.

The licence-included rate is materially higher than BYOL — at list prices, approximately four times the BYOL infrastructure rate for equivalent capacity. For a large, steady-state deployment running continuously, this premium accumulates to a substantial sum over a multi-year term. Over a five-year term, the delta between BYOL and licence-included for a medium-to-large Exadata Cloud@Customer environment can exceed the original licence acquisition cost, making it economically rational in many cases to acquire licences upfront and use BYOL.

Oracle Support Rewards

Oracle operates a Support Rewards programme under which every dollar spent on OCI services generates credits that reduce on-premises Oracle support fees. The reward rate is approximately 25 cents of support reduction per dollar of OCI consumption. For organisations maintaining large on-premises Oracle estates alongside Cloud@Customer deployments, this credit mechanism partially offsets the ongoing cost of on-premises support. Oracle support fees increase by 8% every year under Oracle's standard pricing model — a $2 million support obligation today becomes $2.94 million in five years. Cloud@Customer BYOL combined with Support Rewards credits is the most effective available mechanism for managing that compounding trajectory.

OCI Service Availability on Cloud@Customer

A key differentiator of Oracle Cloud@Customer versus competitive private cloud offerings is the breadth of OCI services available on-premises. Service availability has expanded significantly with each generation, but not every OCI service is available in every Cloud@Customer configuration. Understanding the service boundary before contract execution prevents post-deployment disappointment.

Core Services on Exadata Cloud@Customer

Exadata Cloud@Customer X10M provides access to Exadata Database Service, Autonomous Database (both Autonomous Transaction Processing and Autonomous Data Warehouse), Oracle Data Guard for high availability and disaster recovery, Oracle GoldenGate for data replication, and full OCI Identity and Access Management integration via your OCI tenancy. Autonomous Database on Exadata Cloud@Customer delivers the full self-driving capabilities — automatic patching, automatic indexing, automatic scaling — while keeping data physically within your data centre. For regulated industries, this combination of cloud automation and on-premises data custody is the primary commercial justification for the Cloud@Customer premium.

Compute Cloud@Customer and OCI Dedicated Region

Compute Cloud@Customer extends OCI compute, block storage, object storage, virtual networking, load balancing, and Oracle Container Engine for Kubernetes into your data centre. The X11 generation, released in October 2025, introduced enhanced networking and expanded storage configurations. This offering addresses application workloads that are not Oracle Database-centric but still require on-premises data sovereignty — workloads that would otherwise land on AWS Outposts, Azure Stack, or Google Distributed Cloud.

OCI Dedicated Region provides the complete OCI service stack on-premises, requiring a five-year minimum commitment of approximately $5 million. This competes directly with AWS Outposts and Azure Stack in scope, but with the specific advantage of full OCI service parity and pricing identical to Oracle's public cloud regions. No other cloud provider currently offers on-premises deployment at full public cloud parity without tiered or restricted service availability.

Network and Data Centre Prerequisites

Deploying Exadata Cloud@Customer successfully requires advance planning across networking, physical space, power, cooling, and security controls. Failures in any of these areas cause deployment delays and, in some cases, contract penalties where minimum subscription charges continue regardless of whether the system is operational.

Network Architecture Requirements

Beyond Control Plane Server connectivity, Exadata Cloud@Customer requires dedicated VLANs for client traffic, backup traffic, and administrative access. Oracle specifies minimum bandwidth and latency requirements for each network segment, and deviation from these specifications is a documented source of performance issues post-deployment. FastConnect — Oracle's dedicated interconnect service — is an option for connecting your data centre to an OCI region for hybrid workloads, though it is not mandatory for a standalone Cloud@Customer deployment.

DNS and NTP services must be continuously accessible from the Control Plane Servers. Outbound TCP port 443 must be permanently maintained to Oracle's OCI endpoints — if firewall policy changes or network segmentation breaks this connection, cloud automation and management capabilities degrade immediately until connectivity is restored. This dependency should be treated as a critical infrastructure dependency from a change management and incident response perspective.

Security and Responsibility Division

Oracle publishes a detailed security controls document for Exadata Cloud@Customer that defines the shared-responsibility boundary. Oracle is responsible for hardware security, firmware, hypervisor, and the cloud management software stack. The customer is responsible for database user access controls, application-level security, network perimeter controls, and physical security of the facility housing the equipment. Understanding this boundary is essential for security audits and compliance certifications, particularly ISO 27001, SOC 2, and sector-specific frameworks such as DORA and NIS2.

Cost Modelling: Total Cost of Ownership

Oracle Cloud@Customer cost models involve multiple components that are frequently presented in disaggregated form during the sales process, making the total cost of ownership less visible than it should be before contract execution. A complete five-year cost model must include all of the following components.

Infrastructure Subscription

The base infrastructure subscription covers the hardware Oracle deploys in your data centre. For Exadata Cloud@Customer, this is a fixed monthly fee based on the system size contracted. A base configuration (two database servers, three storage servers) carries an infrastructure subscription of approximately $8,000 per month at list price. A full rack configuration runs approximately $43,200 per month for the infrastructure component. Enterprise negotiations typically achieve discounts of 20 to 40 percent depending on term length, total commitment value, and the credibility of alternative options presented during negotiation.

OCPU and Storage Consumption

Beyond the infrastructure subscription, database compute is billed per OCPU (or ECPU on X10M generation) provisioned to VM clusters. Under BYOL, the OCPU rate is significantly reduced compared to licence-included. OCPU scaling is elastic — you can scale up and down dynamically — but this also creates billing risk if scaling governance is not established at deployment. Storage consumption is billed separately: high-performance Exadata Smart Flash Cache storage is charged per TB provisioned, and object storage for backups carries per-GB charges. Storage costs are frequently the largest source of budget overrun in Cloud@Customer deployments, driven by backup retention policies and insufficient data compression planning.

Support Fee Trajectory

If using BYOL licences with active support contracts, those support fees increase by 8% per year under Oracle's standard pricing model. A $3 million support obligation today becomes $4.41 million in five years and $6.47 million in ten years. Building this trajectory into your total cost of ownership model — and quantifying it in writing during negotiation — is one of the most effective levers for securing meaningful commercial concessions. Oracle's sales teams have authority to offer infrastructure discounts, OCPU rate locks, and Support Rewards enhancements to make deals close. They cannot easily override the standard support escalation model, but demonstrating that you understand its compound impact demonstrates commercial sophistication that typically elicits better outcomes.

Phased Deployment Strategy

The most successful Oracle Cloud@Customer deployments follow a phased approach that begins with a limited-scope pilot, validates the operational model, and expands incrementally — with each phase tied to measurable business outcomes and verified licence compliance at each step.

Phase 1: Readiness and Commercial Baseline (Months 1–3)

Before signing any Cloud@Customer contract, commission an independent licence inventory. Identify every Oracle Database Enterprise Edition and Database Option licence you own, verify active support status for each, and map each licence to current production deployments. This inventory becomes your BYOL asset register and determines whether you have sufficient licences for the planned Cloud@Customer deployment or whether additional licence acquisition is required — and at what cost from Oracle's current price list.

In parallel, build a complete five-year total cost of ownership model. Include infrastructure subscription, OCPU consumption at projected peak and average load, storage consumption, support fee escalation at 8% per year compounded, one-time network preparation and site readiness costs, and migration project costs. This model should be prepared independently, not derived from Oracle's sales tools, which systematically understate certain cost components.

Phase 2: Pilot Deployment (Months 3–9)

Deploy the minimum base configuration and migrate one or two non-critical workloads as a pilot. Validate network performance across all required VLANs, test the management tooling, exercise backup and recovery procedures, and confirm the operational handoff model with Oracle support. Document every deviation from expectation during this phase — these deviations are your documented evidence for commercial review before committing to production scale.

Phase 3: Production Expansion and Optimisation (Months 9–24)

Migrate production Oracle workloads in business-priority order, starting with those best suited to Exadata capabilities: high-throughput OLTP, large-scale analytics, and workloads that benefit from Autonomous Database self-management. Monitor OCPU and storage consumption monthly. Activate additional OCPUs only when sustained demand warrants it, maintaining a licensed headroom buffer appropriate to your peak capacity requirements without over-provisioning. Review your overall licence position quarterly — as workloads migrate from on-premises servers, those servers may become under-utilised, creating an opportunity to reduce the on-premises licence footprint and redeploy licences to Cloud@Customer BYOL.

Commercial Negotiation: Oracle Q4 and Contract Terms

Oracle's fiscal year ends May 31. The Q4 window — March through May — is the period when Oracle's sales organisation is under maximum quarterly and annual pressure to close revenue. Oracle sales representatives and their managers have the greatest discretionary authority to offer discounts, extended payment terms, OCPU rate locks, and commercial concessions during this window. Timing your procurement decision to coincide with Oracle's Q4 is the single highest-leverage tactical decision available to buyers.

High-Value Contract Terms to Negotiate

Beyond headline infrastructure discounts, the following contract terms carry significant multi-year financial value and should be negotiated explicitly: infrastructure subscription price caps for the full contract term; OCPU rate locks for at least the first three years; storage pricing commitments with defined escalation limits; Support Rewards programme participation and credit rate confirmation; the right to reduce OCPU allocation without penalty if workloads are decommissioned; and licence mobility rights that explicitly permit movement of BYOL licences between Cloud@Customer and on-premises without Oracle consent.

ULA and PULA Holders: Critical Timing Consideration

Organisations holding Oracle Unlimited Licence Agreements (ULA) or Perpetual Unlimited Licence Agreements (PULA) face a unique deployment planning consideration. Under these agreements, Oracle support fees are fixed regardless of how many additional Oracle product deployments occur during the contract term. This means that every Oracle product deployment added during the ULA or PULA term costs nothing additional in licence fees — every additional deployment is completely free from a licence perspective. Cloud@Customer deployments made during the ULA or PULA term should therefore be maximised to capture as much licence value as possible before the certification date. Once certified, those deployment volumes become your permanent licence grant at no additional cost. After certification, any further expansion requires purchasing new licences at Oracle's current price list.

Contract Terms to Reject

Oracle's standard Cloud@Customer contracts contain several provisions that systematically create value for Oracle at the customer's expense. Minimum spend commitments that significantly exceed projected consumption create a "use it or lose it" dynamic that Oracle exploits in expansion and renewal conversations. Automatic renewal clauses with short cancellation windows reduce your leverage at renewal. Provisions requiring Oracle's written consent for licence mobility restrict your ability to manage your overall Oracle estate optimally. Each of these terms is negotiable, but only before contract execution — not after.

Common Deployment Pitfalls and How to Avoid Them

Advisory experience across Cloud@Customer and Exadata deployments reveals a consistent set of avoidable mistakes that inflate costs, delay deployments, and permanently damage the customer's commercial position in the Oracle relationship.

Modelling Support Fees as Flat

The most pervasive analytical error is treating Oracle support fees as a constant in five-year cost models. Oracle support increases by 8% annually, compounding without ceiling. An organisation with $5 million in Oracle support today will pay $7.35 million in five years and $10.79 million in ten years if the obligation is not actively managed. Cloud@Customer BYOL combined with Support Rewards credits is the most powerful mechanism for slowing this trajectory, but the commercial structure must be designed for this purpose from contract inception.

Signing Without an Independent Licence Inventory

Oracle's sales process creates momentum toward contract execution before the customer has completed an independent licence audit. Signing a Cloud@Customer contract with an inaccurate BYOL position leaves you either under-licensed — creating an audit exposure that Oracle will pursue — or over-licensed, paying for support on licences you cannot efficiently use. The independent inventory must precede commercial commitment, not follow it.

Accepting Consumption Surprises

Cloud@Customer's elastic OCPU and storage scaling is a genuine technical benefit, but without consumption governance it creates billing surprises. Define maximum OCPU provisioning limits in your OCI tenancy settings, establish an approval workflow for scaling above baseline provisioning, and implement spending alerts before go-live. Oracle LMS actively monitors Cloud@Customer environments and will use any gap between provisioned capacity and licensed quantities as an audit trigger. Quarterly licence reconciliation is not optional on Cloud@Customer — it is operationally mandatory.

Key Questions Every CIO Must Answer Before Signing

No Oracle Cloud@Customer contract should be executed until every CIO can answer the following questions with precision derived from independent analysis: What is your exact BYOL licence inventory, independently verified? What is the five-year total cost of ownership including support fee escalation at 8% per year, OCPU scaling to projected demand, and storage consumption at your retention and compression parameters? What are the specific contract terms for minimum spend commitments, scaling flexibility, and licence mobility? What is your exit or renegotiation strategy at the end of the initial term? Have you benchmarked Oracle's proposed pricing against the cost of continued on-premises deployment and against hyperscaler alternatives for workloads that could run outside Oracle's ecosystem?

If any of these questions cannot be answered before negotiation begins, the probability of signing a commercially disadvantageous contract is high. Oracle's contract structure is designed to create multi-year dependency; independent expertise before signature is the highest-return investment in the entire Cloud@Customer procurement process.

Summary: Making Cloud@Customer Work for Your Organisation

Oracle Cloud@Customer is the appropriate infrastructure choice for organisations with genuine data residency constraints, substantial existing Oracle estates, and the governance maturity to manage an elastic cloud subscription effectively. It is not appropriate for organisations primarily seeking to reduce Oracle dependency, for organisations without active Oracle Database Enterprise Edition licences, or for organisations unable to meet the facility and network prerequisites without major investment.

Where Cloud@Customer is the right technical choice, the commercial outcome is entirely determined by how the contract is structured. BYOL vs licence-included selection, OCPU commitment levels, minimum spend floors, support fee trajectory management, scaling flexibility provisions, and licence mobility rights collectively determine whether the deployment delivers projected value or becomes a source of sustained cost escalation. Engage independent Oracle advisory expertise at the earliest stage of the procurement process — before Oracle's sales teams have established the commercial framing — and ensure every commercial term is negotiated with full awareness of its five-year financial consequence.