Which Oracle Software Can You Run on Oracle Cloud at Customer?

What Is Oracle Cloud at Customer?

Oracle Cloud at Customer (Cloud@Customer) is a hybrid cloud deployment model in which Oracle delivers its cloud infrastructure hardware and software into a customer's own data centre. Unlike traditional on-premises deployment, the hardware is owned, managed, patched, and upgraded by Oracle — the customer simply provides the physical space, power, cooling, and network connectivity. From a software and workload perspective, Cloud@Customer runs the same Oracle Cloud Infrastructure (OCI) stack as Oracle's public cloud regions, but with data and processing remaining physically within the customer's facility.

Oracle offers Cloud@Customer in two primary infrastructure variants. The first is Oracle Exadata Cloud at Customer, which delivers Oracle's Exadata engineered system (purpose-built for Oracle Database performance) under a cloud subscription model in the customer's data centre. The second is Oracle Dedicated Region Cloud@Customer, which delivers a full OCI region — including compute, storage, networking, and Oracle platform services — into the customer's facility. This guide covers both variants, since the software eligibility and licensing rules differ between them.

Oracle Database Software on Cloud at Customer

Oracle Database is the core workload for most Cloud@Customer deployments, and the full range of Oracle Database products is supported. The specific configuration depends on the Cloud@Customer variant:

Oracle Database on Exadata Cloud@Customer

Exadata Cloud@Customer supports Oracle Database Enterprise Edition with all available options and packs. The Exadata hardware provides extreme performance for OLTP and data warehousing workloads, with Oracle Exadata's storage server technology delivering features such as Smart Scan, Hybrid Columnar Compression, and I/O Resource Management. Oracle Database Enterprise Edition with Real Application Clusters (RAC) is fully supported on Exadata Cloud@Customer for high availability deployments. Oracle Data Guard for disaster recovery and standby database management is also fully supported.

Licensing on Exadata Cloud@Customer is based on OCPUs (Oracle CPU units). One OCPU is equivalent to one physical processor core. You bring your existing on-premises Oracle Database processor licences (each covering two OCPUs) to the Cloud@Customer deployment under Oracle's BYOL terms. The licence counting on Exadata Cloud@Customer uses the OCPU metric specifically, not Oracle's traditional on-premises core factor table — this is a favourable distinction that Oracle has engineered to make Cloud@Customer commercially attractive compared to on-premises Exadata licensing.

Oracle Autonomous Database on Exadata Cloud@Customer

Oracle Autonomous Database — both Autonomous Transaction Processing (ATP) and Autonomous Data Warehouse (ADW) — is available on Exadata Cloud@Customer. This allows organisations that require data to remain on-premises to use Autonomous Database's self-driving, self-securing, self-repairing capabilities without sending data to Oracle's public cloud. Oracle explicitly certified PeopleSoft, JD Edwards, and Siebel to run with Autonomous Database on Cloud@Customer — meaning you can take your legacy Oracle ERP application's database tier and move it to Autonomous Database on Exadata Cloud@Customer, gaining Oracle's autonomous management while keeping the application server tier and data within your facility.

Licensing for Autonomous Database on Cloud@Customer is typically subscription-based, charged per OCPU per hour, with BYOL options available for customers who hold existing Oracle Database Enterprise Edition licences. The BYOL discount for Autonomous Database on Cloud@Customer is typically 50% of the standard subscription rate — a material saving for organisations with large existing Oracle Database licence estates.

Oracle Fusion Middleware on Cloud at Customer

Oracle's Fusion Middleware portfolio — the middleware layer that includes Oracle WebLogic Server, Oracle SOA Suite, Oracle Service Bus, Oracle Forms, Oracle Internet Directory, and related products — is fully deployable on Oracle Dedicated Region Cloud@Customer. On this infrastructure variant, which delivers a full OCI region into the customer's data centre, Oracle middleware runs on OCI compute instances in the same way it would on public OCI.

An important caveat for Oracle Middleware on Cloud@Customer: the BYOL model requires that you have active support contracts on your existing on-premises licences. You are not simply using perpetual licences passively — you must be paying Oracle support on those licences to qualify for BYOL on Cloud@Customer. This means the support cost savings from third-party support providers are not straightforwardly compatible with a Cloud@Customer BYOL strategy, since Oracle requires active Oracle support as a condition of BYOL eligibility.

Oracle Enterprise Applications: PeopleSoft, JD Edwards, Siebel

Three of Oracle's major on-premises enterprise application suites — PeopleSoft, JD Edwards EnterpriseOne, and Siebel CRM — are fully supported on Oracle Cloud@Customer. This is commercially significant because these are the largest categories of Oracle legacy application users, and Cloud@Customer provides a migration path that keeps the application running (eliminating migration risk) while shifting operational responsibility for infrastructure management to Oracle.

PeopleSoft on Cloud@Customer

Oracle PeopleSoft HCM, Financials, and Campus Solutions can run on Oracle Dedicated Region Cloud@Customer with their Oracle Database hosted on Exadata Cloud@Customer or standard OCI compute. Oracle's approach for PeopleSoft on Cloud@Customer typically involves running the PeopleSoft application servers on OCI compute instances (virtual machines within the Dedicated Region), while the PeopleSoft database runs on Exadata Cloud@Customer — optionally migrated to Autonomous Database. This architecture delivers Oracle-managed infrastructure with the PeopleSoft application layer still under the customer's operational management. PeopleSoft licences brought to Cloud@Customer under BYOL are counted on a per-user basis (Named User Plus) as per the on-premises PeopleSoft licence terms, not converted to OCPU-based metrics.

JD Edwards EnterpriseOne on Cloud@Customer

JD Edwards EnterpriseOne is officially certified and supported on Oracle Cloud@Customer deployments. The deployment model mirrors PeopleSoft: JD Edwards application servers run on OCI compute instances within the Dedicated Region, while the JD Edwards Oracle Database runs on Exadata Cloud@Customer. Oracle has specific reference architectures for JD Edwards on Cloud@Customer that guide the sizing, network topology, and high availability configuration. JD Edwards licences brought to Cloud@Customer under BYOL retain their on-premises metric (NUP or Processor as per the original licence agreement).

Siebel CRM on Cloud@Customer

Siebel CRM is the third Oracle legacy application that Oracle has explicitly certified for Cloud@Customer, including with Autonomous Database on Exadata Cloud@Customer as the database tier. Siebel on Cloud@Customer represents one of the cleaner transformation paths for organisations running on-premises Siebel that are not ready to migrate to Oracle Fusion Sales Cloud, since it modernises the infrastructure layer without requiring an application migration.

Oracle Software NOT Eligible for Cloud at Customer BYOL

Not all Oracle software can be deployed on Cloud@Customer under BYOL terms. The following categories have important restrictions or are explicitly excluded:

• Oracle Real Application Clusters (RAC) with certain BYOL configurations: RAC on Cloud@Customer is subject to specific configuration restrictions under BYOL. Oracle's BYOL policies for RAC on OCI are more complex than for standard Oracle Database Enterprise Edition and require careful review of the specific licence terms.
• Oracle E-Business Suite (EBS): Unlike PeopleSoft, JD Edwards, and Siebel, Oracle E-Business Suite certification for Cloud@Customer has not been formally announced by Oracle. EBS customers typically use Oracle's public OCI regions (BYOL) or remain on-premises. This may change, but as of 2026 E-Business Suite customers planning Cloud@Customer deployments should verify current support status directly with Oracle.
• Oracle software without active Oracle support: Any Oracle product deployed under third-party support (Rimini Street, Spinnaker, etc.) is not eligible for Cloud@Customer BYOL. Oracle requires active Oracle Annual Support as a condition of BYOL eligibility across all Cloud@Customer products.
• Older Oracle software versions beyond Extended Support: Software running on Oracle Sustaining Support (past Extended Support end dates) may not be eligible for Cloud@Customer deployment under standard support terms. Verify version-specific support status before planning a Cloud@Customer migration for legacy product versions.

BYOL Licensing Mechanics for Cloud at Customer

The Bring Your Own Licence (BYOL) model for Oracle Cloud@Customer works as follows: you hold perpetual Oracle software licences with active Oracle Annual Support contracts. You notify Oracle that you are deploying those licences on Cloud@Customer infrastructure. Oracle applies a discount to the Cloud@Customer infrastructure subscription rate (typically 50% for Oracle Database) because you are supplying the software licensing component. Your existing Oracle support fees continue — you pay both the (reduced) Cloud@Customer infrastructure subscription and Oracle support for your perpetual licences. Bear in mind that Oracle's annual support fees increase by 8% per year: this compounding escalation means your total Oracle spend under BYOL grows steadily each year, making a full total cost of ownership comparison with public OCI (where subscription pricing is more stable) essential before committing to Cloud@Customer long-term.

The OCPU is the licence unit on Cloud@Customer for most Oracle technology products. One Oracle Database Processor licence covers two OCPUs on Cloud@Customer. This is a more favourable conversion than on-premises licensing in some scenarios: an on-premises server with 32 physical cores requires 16 Oracle Database Processor licences (32 × 0.5 core factor). Those same 16 licences cover 32 OCPUs on Cloud@Customer. For organisations moving to Cloud@Customer from on-premises Exadata or standard servers, this equivalency typically means your existing licence count maps cleanly to your Cloud@Customer OCPU requirement without requiring additional licence purchases.

There is an important distinction between Oracle's BYOL policy document and your actual Oracle Master Agreement: Oracle's BYOL policy document is explicitly non-contractual. The terms of your OMA, ULA, or PULA take precedence over the published BYOL policy. Before deploying any Oracle product on Cloud@Customer under BYOL, confirm that your specific licence agreements support this deployment model. This is particularly important for ULA holders — Cloud@Customer deployments may or may not count as "qualifying deployments" under your ULA's scope of coverage, depending on how the ULA was written.

Cloud at Customer vs Public OCI: Software Eligibility Comparison

The range of Oracle software eligible for Cloud@Customer is in most respects equivalent to what is available on public OCI, with the primary difference being the physical infrastructure location. Organisations choosing between Cloud@Customer and public OCI typically make this decision on the basis of data sovereignty requirements, regulatory constraints (financial services, healthcare, government), network latency requirements, or contractual obligations that prevent data from leaving a specific jurisdiction — not on the basis of software eligibility differences.

The key commercial difference is cost. Cloud@Customer infrastructure subscription costs are typically higher than equivalent public OCI costs, reflecting the complexity of delivering and managing on-premises hardware. For organisations with genuine data sovereignty requirements, this cost premium is justified. For organisations exploring Cloud@Customer purely to avoid cloud migration effort, public OCI almost always delivers better economics.

Key Questions to Ask Before Deploying on Cloud at Customer

• Does your specific Oracle licence agreement explicitly permit Cloud@Customer BYOL deployment, or does it need to be amended?
• Are you currently paying Oracle Annual Support on all licences you plan to bring under BYOL, or have any been moved to third-party support?
• For ULA holders: does your ULA's product scope and deployment geography cover Cloud@Customer installations?
• For PeopleSoft, JD Edwards, or Siebel: are the application server software licences (not just the database licences) covered by your BYOL agreement for Cloud@Customer?
• What is the net licence cost impact — does BYOL reduce your total Oracle spend, or does the Cloud@Customer subscription effectively add a layer of cost on top of existing support fees?