Which Oracle Software Can You Run on Oracle Cloud at Customer
Introduction: Oracle Cloud@Customer is a family of on-premises cloud solutions that bring Oracle’s technology into your data center.
A frequent question from IT leaders is: What Oracle software can we run on these Cloud@Customer systems?
This article provides a detailed overview of the Oracle applications and databases supported on Cloud@Customer deployments.
We cover the range of Oracle software – from databases to enterprise applications – that can run in this environment, discuss licensing options for each, and outline typical workload scenarios.
The goal is to clarify how Cloud@Customer can host and support your Oracle software portfolio under a consistent hybrid cloud model.
Oracle Databases on Cloud@Customer
Oracle’s flagship databases are fully supported on Cloud@Customer, which was initially centered around database services:
- Exadata Database Service on Cloud@Customer: This is Oracle’s primary offering for databases on-prem. It allows you to run Oracle Database as a cloud service on Exadata hardware. All editions of Oracle Database (Enterprise Edition and features like RAC, etc.) are supported, and you can even deploy the Autonomous Database on Exadata Cloud@Customer. In practice, you can run Oracle Database 19c (and newer versions as Oracle releases them) in this environment, with Oracle managing the infrastructure. Autonomous Database on Cloud@Customer uses Oracle’s machine learning automation to automatically handle tuning, patching, and backups, so your DBAs can focus on data and applications rather than maintenance.
- Database versions and features: Cloud@Customer supports modern Oracle DB versions offered in Oracle Cloud. For example, Autonomous Transaction Processing and Autonomous Data Warehouse are available on Exadata Cloud@Customer. If you have specific needs (like older versions), the Cloud@Customer service will typically encourage upgrading to supported versions. However, because you control the database instances, importing older data or running compatibility modes is possible. Most Oracle Database options (Advanced Security, Partitioning, etc.) can be used – some are included by default in Autonomous deployments.
- Multiple Databases and Consolidation: One Exadata Cloud@Customer rack can host many or pluggable databases. This makes it ideal for database consolidation projects – you can take dozens of separate Oracle databases from aging hardware and move them onto one cloud-managed Exadata system on-prem. Oracle software, like Oracle Real Application Clusters (RAC) and Oracle Data Guard, is fully supported, so you can build robust HA and DR configurations within Cloud@Customer. For example, you might run a primary and standby database on Cloud@Customer across different servers for resilience (or use a second Cloud@Customer for DR at another site).
Any Oracle database on Exadata or Oracle Cloud can run on Exadata Cloud@Customer. You get the same database software capabilities delivered as a managed service in your data center.
Oracle ensures that the database software on Cloud@Customer stays current and patched, but you can create and manage databases to suit your application needs.
Read Oracle Cloud at Customer vs. Dedicated Region.
Oracle Enterprise Applications on Cloud@Customer
Many organizations run Oracle’s enterprise applications (the Oracle E-Business Suite, PeopleSoft, JD Edwards, Siebel, etc.). With Cloud@Customer, you can continue to run these applications on-premises while leveraging cloud-managed infrastructure:
- Oracle E-Business Suite (EBS): EBS is a classic on-prem ERP system. You can deploy EBS application tier servers on Oracle Compute Cloud@Customer VMs, and use an Oracle Database on Exadata Cloud@Customer as the backend. This configuration keeps the entire EBS stack in your data center but offloads the hardware management to Oracle. Oracle has published guidance and success stories for EBS on Cloud@Customer, indicating full support. The database component can even be an Autonomous Database on Cloud@Customer, which Oracle touts as a way to reduce DBA workload for EBS users.
- PeopleSoft, JD Edwards, Siebel: Similarly, these legacy Oracle applications (now Oracle-owned products for HR, ERP, CRM, respectively) are supported on Cloud@Customer. Oracle explicitly certified PeopleSoft, JDE, and Siebel to run with Autonomous Database on Cloud@Customer. For instance, you can take your PeopleSoft HR system, migrate its Oracle database into an Autonomous DB on Exadata Cloud@Customer, and run the PeopleSoft application servers on local OCI compute instances. By doing so, the application benefits from an up-to-date, auto-tuned database platform without moving to a public cloud. Essentially, any Oracle application you run on Oracle’s public cloud or on traditional Oracle infrastructure can be run on Cloud@Customer since Cloud@Customer provides equivalent infrastructure in your data center.
- WebLogic and Middleware: Many Oracle applications rely on Oracle WebLogic Server (for example, Siebel and custom Java apps use it). You can run WebLogic Server on Oracle Cloud@Customer as well. In a Compute Cloud@Customer environment, you’d install WebLogic on a VM just as on any OCI compute instance or on-prem server. Oracle even has offerings like WebLogic Cloud Service, but on Cloud@Customer, you would likely manage WebLogic manually on VMs or as part of the application deployment. The key is that Cloud@Customer’s compute service supports Oracle Linux and other OS images, so deploying Oracle middleware like WebLogic, Oracle Internet Directory, Oracle SOA Suite, etc., is fully feasible.
- Oracle Analytics and BI: If you use Oracle Business Intelligence (OBIEE/OAS) or Oracle Analytics Server, you can host these on Cloud@Customer VMs. They would connect to your Exadata Cloud@Customer database for reporting. Oracle’s analytics and middleware software aren’t SaaS; they run as applications on servers, and those servers can be the ones provided by Cloud@Customer. In short, you can treat Cloud@Customer as an extension of your existing data center for any Oracle software stack. The difference is that you’ll be using Oracle’s cloud provisioning methods and possibly get better performance on Oracle’s optimized hardware.
Important note: Running these applications on Cloud@Customer does not magically transform them into cloud SaaS; you still have to maintain and administer the applications (apply application patches, manage configurations) as you did before, but now on a modernized infrastructure.
The benefit is mainly operational – easier provisioning, scaling, and integrated management of the underlying layers.
Oracle Fusion Cloud Applications (SaaS) on Cloud@Customer
Oracle’s newest applications (Fusion Cloud ERP, HCM, CRM, SCM – collectively Oracle Fusion Applications) are provided as cloud services by Oracle. Normally, customers do not run these themselves on-prem; Oracle hosts them.
However, Oracle Dedicated Region Cloud@Customer uniquely allows Oracle to deploy Fusion SaaS applications in your data center as part of the service.
This means:
- A customer who signs up for a Dedicated Region can request Oracle to include applications like Oracle Fusion ERP, HCM, etc., running on that dedicated region’s infrastructure. Oracle operates those just as they would in the public cloud, but the servers are in your facility. For the customer, it appears to be the same SaaS application, except it is delivered from a private region. This is a special case and part of Oracle’s pitch that all Oracle Cloud services, including SaaS, are available in a dedicated Region.
- If you are not using a Dedicated Region (say you only have Exadata Cloud@Customer), you cannot self-install Oracle’s SaaS apps like Fusion ERP – those are not sold as installable software. In that scenario, you would either continue to use Oracle’s SaaS in their cloud or stick with Oracle’s on-prem applications as discussed above. So, support for Fusion Applications on-premises is limited to Oracle delivering it via a Dedicated Region arrangement.
In summary, legacy Oracle applications (EBS, PeopleSoft, etc.) are supported by the customer on the Cloud@Customer infrastructure. In contrast, modern Oracle Cloud applications (Fusion SaaS) can be included only through Oracle’s management in a Dedicated Region. This distinction is key when planning what software goes where.
Third-Party and Custom Applications
While the focus here is Oracle software, it’s worth noting that Cloud@Customer is not limited to Oracle-only workloads.
Especially with Oracle Compute Cloud@Customer or a Dedicated Region, you can run custom applications, third-party software, and open-source tools just like in any cloud or virtualized environment. For example:
- You could run a Linux VM on Cloud@Customer and install non-Oracle databases (like MySQL, PostgreSQL) or application servers (like Apache, Tomcat) if your architecture requires it. Oracle Cloud@Customer provides the infrastructure, and you aren’t restricted to Oracle software on those machines. Oracle explicitly states you can run “third-party and custom apps” on Cloud@Customer. This is helpful if your Oracle systems integrate with other software – you might also keep those integrations local by running the related components on the Cloud@Customer box.
- Many third-party enterprise applications (SAP, for instance) have their own support requirements and might not be officially certified on Oracle Cloud@Customer. You would treat it as if running on Oracle Linux or Windows on standard x86 servers (since that’s essentially what Compute Cloud@Customer provides). As long as the OS environment is supported, the software should run. Always check with the vendor if running on Oracle’s cloud infrastructure or on-premises has any support caveats.
Licensing Options on Cloud@Customer
When running Oracle software on Cloud@Customer, licensing is a critical consideration. Oracle provides two licensing models in this environment:
- License-Included (Subscription): In this model, you effectively “rent” the Oracle software license as part of the Cloud@Customer service subscription. For example, if you use an Oracle Database on Exadata Cloud@Customer under the license-included model, your hourly or monthly rate covers the Oracle Database license and support. You do not need a separate on-prem license for that database. This is straightforward – Oracle handles the licensing internally, and you just pay for the service usage. License-included pricing tends to be higher than BYOL because it bundles in the cost of the Oracle software license. Companies choose this if they don’t own the licenses already, prefer not to worry about compliance, or want Oracle to be responsible for all support as part of the service.
- Bring Your Own License (BYOL): In the BYOL model, you leverage your existing Oracle software licenses on the Cloud@Customer platform. You must have equivalent licenses with active support contracts on-premise, and you certify that you’re using those licenses for the cloud service. In return, Oracle charges you a lower rate for the infrastructure/service since you supply the licensing piece. For instance, you might bring Oracle Database Enterprise Edition licenses to cover databases running on Exadata Cloud@Customer or bring WebLogic Server licenses for middleware you install on Compute Cloud@Customer VMs. BYOL is popular for those who have invested heavily in Oracle licenses (sometimes via an Unlimited License Agreement or surplus of processor licenses) because it avoids paying twice for the same capability. It essentially extends the use of your perpetual licenses into Oracle’s subscription environment, maximizing your ROI on those licenses.
Licensing for Oracle Applications:
For applications like EBS or PeopleSoft, the application software licenses are typically separate from Cloud@Customer. If you are migrating an existing EBS instance to Cloud@Customer, you would maintain your EBS application licenses as is (usually perpetual user or module licenses) – Cloud@Customer doesn’t include those licenses.
What Cloud@Customer can include is the underlying technology licenses (database, WebLogic, etc.) if you choose license-included for those.
However, many Oracle apps come with a restricted-use database license when on-prem; in a Cloud@Customer scenario, it might be cleaner to use BYOL and cover the database with your existing license, or if moving to Autonomous DB, convert that license to an Autonomous BYOL credit.
Microsoft and other software licenses:
If running non-Oracle software on Cloud@Customer, you must also consider those licenses. For example, suppose you run Windows Server on a VM in Oracle Cloud@Customer.
In that case, you need to properly license Windows (Oracle has guidance for Microsoft licensing on OCI, which would apply similarly on Cloud@Customer). Oracle Cloud@Customer doesn’t cover third-party software licenses magically, so standard rules apply (either bring your license or see if a cloud subscription model exists).
The bottom line on licensing: Oracle Cloud@Customer supports both license-included and BYOL, giving you flexibility.
CIOs often evaluate cost trade-offs: BYOL can be cheaper if you have underutilized licenses (because the cloud service rate is lower), whereas license-included might be simpler if you want an all-in-one subscription and have no spare licenses.
Importantly, Oracle’s Universal Credits apply to Cloud@Customer usage, so if you negotiated a pool of cloud credits, you can use them in these on-prem services.
Also note that compliance is monitored – if you use more database OCPUs than your BYOL covers, Oracle will notice (since they operate the infrastructure). You’d need to address that to avoid compliance issues.
Read Oracle Exadata Cloud at Customer Optimization.
Typical Workload Scenarios
To illustrate how Oracle software runs on Cloud@Customer, here are a few scenario examples:
- Case 1: On-Prem ERP with Autonomous Database. A manufacturing company runs Oracle E-Business Suite for finance and supply chain. Due to data privacy rules, they keep it on-prem. They deploy an Exadata Cloud@Customer in their data center and migrate the EBS database to an Autonomous Transaction Processing instance. The EBS application tier is moved onto VMs on a small Oracle Compute Cloud@Customer appliance. The core ERP system remains on-prem in this setup but now benefits from an autonomous database (no tuning, auto-indexing, etc.) and easily scalable app servers. The company uses BYOL for the database (converting their previous licenses), and license-included for the Exadata infrastructure. The result was lower DBA effort and improved performance, with no change in EBS’s user experience.
- Case 2: Data Warehouse Modernization. A retail enterprise has a large Oracle data warehouse on old hardware. They install Exadata Cloud@Customer and move the data warehouse onto it, perhaps using Oracle Autonomous Data Warehouse. They also install Oracle Analytics Server on a VM on the Cloud@Customer box, connecting to that database. All their BI reporting now runs on Cloud@Customer. They use a license-included model for the Autonomous DB (renting the DB license) since they didn’t have enough database licenses, but they BYOL their Oracle Analytics server license. Performance improves drastically thanks to Exadata, and they didn’t have to move any data off-site, satisfying internal security policies.
- Case 3: Hybrid Cloud with Dev/Test. An organization uses Oracle Cloud@Customer as part of a hybrid cloud strategy. Their production Oracle databases and apps stay on Exadata Cloud@Customer on-prem for latency and control reasons. However, they also use Oracle’s public cloud for bursty workloads or disaster recovery. Because Cloud@Customer is essentially OCI, the same automation scripts and configurations work in both environments. They run a PeopleSoft environment on-prem, and maintain a standby copy of it in Oracle’s public cloud region for DR via Data Guard. They bring their own licenses to stabilize licensing costs across on-prem and cloud. This scenario highlights Cloud@Customer’s ability to integrate smoothly with Oracle’s public cloud, giving workload portability when needed.
- Case 4: Non-Oracle apps adjacent to Oracle DB. A bank has a home-grown application that uses Oracle Database as a backend. They deploy the database on Exadata Cloud@Customer. The application is written in .NET, so they run it on Windows Server VMs on the Cloud@Customer compute nodes. They license Windows and .NET appropriately through Microsoft. The proximity (same machine or rack) of app and database yields low latency, and Oracle manages all the infrastructure. This shows that Cloud@Customer can host mixed stacks – Oracle DB plus any app – similar to how one might use an Oracle VM server on-prem, but with cloud automation.
Each scenario demonstrates that Oracle Cloud@Customer can accommodate various Oracle software deployments – from core databases to application stacks.
The key is to map which components run where:
- Use Exadata Cloud@Customer for database storage and processing.
- Use Compute Cloud@Customer for application or middle tiers.
- Integrate them using Oracle’s fast internal networking (within the rack).
- Optionally, connect to Oracle Cloud services (or other clouds) for things not on-prem (for example, maybe use Oracle Cloud Infrastructure Object Storage in a public region for backup of your on-prem databases – a supported hybrid use).
Evergreen Considerations
One should note that Oracle continues to expand Cloud@Customer offerings.
For instance, in 2022, Oracle introduced smaller-footprint Dedicated Regions and the Compute Cloud@Customer to widen the range of on-prem applications that customers can run.
This trend suggests more Oracle software will be seamlessly supported in these environments over time, including new services.
The model is designed to be evergreen: when Oracle develops a new cloud service (say, an AI service), a customer with a Dedicated Region could run it on-prem once it’s rolled out. Similarly, updates to Oracle software (database upgrades, new app versions) are made available in Cloud@Customer as they are in the cloud, keeping your environment current.
From a CIO perspective, the Cloud@Customer environment can host virtually all Oracle software your enterprise uses, provided you have the appropriate Cloud@Customer configuration (database systems for DB software, compute for apps, or the whole dedicated region for everything).
It essentially extends the compatibility of Oracle’s public cloud to your premises. This means less re-architecting – you can move existing Oracle-based workloads onto Cloud@Customer with minimal changes, just gaining cloud-like management.
It’s a way to modernize how Oracle software is delivered, without abandoning the software you rely on.
