Oracle Exadata Cloud at Customer

Table of Contents

Oracle Exadata Cloud@Customer – The Complete Guide

Oracle Exadata Cloud@Customer is a hybrid cloud service that brings Oracle’s flagship Exadata database platform into your data center with a cloud consumption model. It offers the performance of Exadata on-premises while Oracle handles the infrastructure like a cloud service.

This guide provides CIOs and enterprise architects with a comprehensive overview of Exadata Cloud@Customer, including its purpose, benefits, pricing model, challenges, and expert guidance on maximizing its value.

What is Oracle Exadata Cloud@Customer?

Oracle Exadata Cloud@Customer (often abbreviated Exadata C@C) is essentially Oracle’s Exadata Database Cloud delivered on-premises.

In this model, Oracle installs an Exadata system in your own data center, but you consume it as a cloud service.

Oracle retains ownership of the hardware and manages it (just as they would in their public cloud), while you get to run Oracle databases on it behind your firewall.

Importantly, it’s not a product you buy outright – it’s a subscription service with Oracle providing a fully managed Exadata infrastructure on a lease-like basis.

Key characteristics include:

Exadata technology on-prem: You get the full Exadata platform – specialized database servers, smart storage, ultra-fast interconnects, and Oracle’s database optimization features – but deployed at your site. This means you can run Oracle Database with all Exadata enhancements (e.g., smart scans, flash cache, RDMA networking) under your roof, ideal for mission-critical workloads that demand high performance.
Cloud-managed infrastructure: Oracle handles all hardware maintenance, patching, and infrastructure administration. They monitor and support the Exadata remotely, keeping it in sync with Oracle Cloud Infrastructure (OCI) updates. From your perspective, it behaves like a cloud service: you request databases or scale up/down capacity via cloud consoles or APIs, and Oracle takes care of the underlying setup. This reduces the burden on your IT team for low-level upkeep.
Deployed behind your firewall: Unlike Oracle’s public cloud, Exadata Cloud@Customer keeps data on your premises. The Exadata rack sits in your data center, connecting to Oracle’s cloud control plane for management. You maintain direct control over data locality, security policies, and integration with other on-prem systems, which is crucial for many regulated industries.

In summary, Exadata Cloud@Customer is Oracle’s answer for organizations that want cloud benefits (agility, subscription pricing, Oracle-managed ops) without moving their databases to an Oracle public cloud data center.

It’s part of Oracle’s broader “Cloud@Customer” portfolio, which also includes offerings such as Compute Cloud@Customer and an entire OCI Dedicated Region on-premises. Exadata Cloud@Customer focuses specifically on delivering Oracle Database cloud services on Exadata hardware in your facility.

Key Benefits and Use Cases

Global enterprises are adopting Exadata Cloud@Customer to strike a balance between cloud innovation and on-premises control.

Some of the key benefits and use cases include:

Regulatory Compliance & Data Sovereignty: For industries such as banking, healthcare, and government, maintaining data on domestic soil or under specific controls is non-negotiable. Exadata Cloud@Customer lets you meet strict data residency requirements while still using a cloud service model. For example, a national bank can run its core customer databases on an Exadata Cloud@Customer in its own data center to comply with privacy laws, while still benefiting from cloud automation. Similarly, government agencies use it to ensure sensitive citizen data never leaves their premises.
Ultra-Low Latency Applications: Some workloads demand extremely low latency that even the best WAN connections to a public cloud can’t guarantee. By having the Exadata infrastructure on-site, you place data and compute near the application users. For instance, a high-frequency trading firm could deploy Exadata Cloud@Customer next to its trading engines to get millisecond response times, or a telecommunications provider might run real-time network billing or AI algorithms locally for immediate processing. In these cases, the on-prem deployment eliminates network latency issues while still providing cloud-like scalability.
Cloud Consumption with On-Prem Control: Enterprises often have significant Oracle Database estates on older infrastructure. Exadata Cloud@Customer offers a path to modernize and consolidate databases on a single, high-performance platform, eliminating the need to migrate to a multi-tenant public cloud. You get cloud-style self-service and elasticity for your on-premises Oracle databases. This is ideal for a phased cloud strategy: an enterprise might consolidate dozens of legacy Oracle databases onto Exadata Cloud@Customer to reduce hardware sprawl and improve performance, and later, it has the option to migrate some workloads to Oracle’s public cloud, as the platforms are compatible. The consistent technology stack (Exadata and OCI services) means that applications can be moved or integrated between on-premises and cloud environments more easily.
Reduced Operational Overhead: Because Oracle manages the infrastructure, your team can focus on higher-level tasks. Database administrators (DBAs) spend less time on patches, backups, and hardware issues, and more on architecture and optimization. If you opt to use Oracle Autonomous Database on the Exadata Cloud@Customer, even routine DBA tasks (like tuning and indexing) are automated by Oracle’s AI-driven features. Many organizations see this as a way to leverage Oracle’s expertise to handle the “undifferentiated heavy lifting”, resulting in fewer staffing headaches and potentially higher uptime. It’s like having Oracle operate part of your data center, under your guidance.
Financial Flexibility: Exadata Cloud@Customer shifts database infrastructure spending from capital expenditures (CapEx) to operational expenditures (OpEx). There’s no large upfront purchase of Exadata hardware; instead, you pay a monthly fee. This can be attractive for budget planning and can align costs with usage over time. Enterprises that prefer subscription models or need to treat costs as operational expenses find this model beneficial. Additionally, consolidating databases onto a single platform can sometimes reduce total licensing and support costs if it leads to higher utilization of the resources you’re paying for. (However, as discussed later, you must manage the capacity commitments to realize cost efficiency.)

In short, Exadata Cloud@Customer is best utilized when an organization needs the advantages of cloud (scalability, ease of provisioning, offloaded maintenance) but cannot relinquish control over data location or accept the latency of a remote cloud.

It’s a strategic solution for modernizing Oracle environments under strict requirements.

Architecture and Operational Model

From an architecture perspective, Oracle Exadata Cloud@Customer brings a slice of Oracle’s cloud inside your data center.

Understanding how this is set up and operated is crucial for enterprise architects.

Exadata Hardware on Site: Oracle delivers a configured Exadata rack (or multiple racks) to your facility. This includes database servers, storage servers, networking, and all the specialized Exadata components. The hardware is the same as used in Oracle’s cloud and in Exadata appliances generally – for example, the latest generations (X8M, X9M, X10M, etc.) featuring powerful CPUs, persistent memory, and fast networking. The rack is physically installed in your data center space, and you are responsible for providing power, cooling, and physical security for it (just as you would for any on-prem equipment).
Cloud Control Plane: Although the hardware is on-premises, it is still tethered to Oracle’s cloud systems. Oracle establishes a secure network link from the Exadata rack back to Oracle Cloud Infrastructure. Through this link, Oracle performs remote monitoring, management, and updates. You will interact with the Exadata Cloud@Customer via cloud-based interfaces – e.g., Oracle’s OCI web console, APIs, or command-line tools – as if it were a resource in the public cloud. When you create a database service or adjust OCPU capacity, those requests are orchestrated by Oracle’s cloud control plane on your on-prem Exadata. Think of the Exadata rack as an extension of Oracle’s cloud region, except dedicated solely to you.
Managed by Oracle, Used by You: A clear delineation of responsibilities exists. Oracle handles infrastructure-level management, monitoring the health of the hardware, replacing failed components, applying firmware updates, and keeping the system software (hypervisor, clusterware, etc.) up to date. They ensure the Exadata infrastructure is running optimally and securely. Your IT team, on the other hand, is responsible for everything above that infrastructure: you create and manage the databases or VMs on the Exadata, configure how your applications use those databases, and manage your data and users. In practice, this means that if you’re using the non-autonomous Database Service, your DBAs will still create databases, set up schemas, and possibly configure some aspects of the database; however, they won’t need to modify OS-level settings or storage configuration – that’s all pre-optimized by Oracle. If you’re using Autonomous Database on Exadata Cloud@Customer, Oracle’s automation takes on much of the database tuning and administration as well, further reducing your operational effort. In all cases, Oracle does not access your actual data; that remains under your control and is governed by your security and access policies.
Shared Security Model: Similar to public cloud, Cloud@Customer operates under a shared responsibility model. Oracle secures the infrastructure and the Exadata platform (ensuring patches are applied, enabling encryption features, etc.), while you must secure your databases, user accounts, and any integration points. For example, Oracle encrypts data at rest by default; however, you should manage database user roles and protect network access to the system. Collaboration between your team and Oracle is needed to align on security and compliance. Oracle will provide documentation on what they cover versus what you need to handle (very much like how they document responsibilities in OCI public cloud).
Connectivity and Integration: The Exadata Cloud@Customer environment integrates with both your internal networks and Oracle’s cloud. You’ll typically set up network connectivity so that your applications and users can connect to the databases on the Exadata just as they would to any on-prem database. At the same time, connectivity to Oracle’s cloud means you can optionally use other Oracle Cloud services in tandem (for example, you could connect an analytics cloud service or backup to Oracle Cloud Object Storage). However, a reliable, low-latency network link to Oracle is mandatory for Oracle to manage the service. Planning this connectivity (usually via a VPN or FastConnect link) is a crucial part of the deployment, ensuring that Oracle’s remote management can function and that you can utilize any hybrid cloud workflows.

In essence, the operational model is cloud-like for the infrastructure (Oracle takes care of it), and on-prem for the data and application use (you operate your databases and apps).

This hybrid approach requires close coordination: you’ll work with Oracle during installation and for any support issues, almost as if they are an extension of your ops team.

Many CIOs appreciate that this frees up internal resources, but it also means relying on Oracle’s responsiveness and trusting their processes. It’s wise to have clear SLAs and support plans, which we’ll touch on later.

Pricing Model and Licensing Considerations

Exadata Cloud@Customer introduces a distinct cost structure compared to traditional on-premises systems. Instead of buying hardware and licenses upfront, you commit to a subscription model with both fixed and variable components.

Understanding this model will help you budget and optimize costs:

Subscription and Term: Oracle requires a multi-year commitment for Exadata Cloud@Customer, typically a 4-year term on the infrastructure. You don’t purchase the Exadata hardware; you essentially lease it for the duration of the contract. A monthly infrastructure base fee is charged for the Exadata hardware and cloud infrastructure software. For instance, a small “Base System” rack might have a base fee of approximately $8,000 per month, whereas a full rack might be $ 40,000 or more per month, depending on the Exadata model and size. (Newer generation systems and larger configurations cost more.) This base fee covers the cost of having dedicated Exadata capacity on-site and is typically fixed for the duration of the agreement.
Pay-per-use cloud resources: On top of the base fee, you pay for the actual consumption of database resources – primarily measured in OCPUs or ECPUs (Oracle compute units) for database CPU usage, plus any additional storage or optional services. This works much like public cloud billing: for every hour that a database CPU is running, you incur charges. However, there are minimums: Oracle enforces a minimum number of OCPUs to be activated per Exadata node (for example, each database server requires at least 8 OCPUs to be active). This means even if your databases are idle, you may be paying for a baseline level of compute. Storage is often included up to a certain amount with the base system, but additional storage or backup usage may incur charges as well. The rates for OCPU hours and other resources are generally at parity with Oracle’s public cloud pricing – the difference is you’re using those resources on dedicated on-prem hardware.
License-Included vs. BYOL: A critical aspect of cost is whether you use Oracle’s software licenses as part of the service (license-included) or Bring Your License (BYOL). With license-included pricing, the OCPU hourly rate is higher because it includes Oracle Database licenses in the cost. With BYOL, you apply your existing Oracle Database licenses to the Exadata Cloud@Customer deployment, thereby paying a significantly lower rate for OCPU hours. For example, Oracle’s list price for an Exadata Cloud@Customer OCPU is approximately $1.34 per hour, including the license, but only around $0.32 per hour if you bring your license. That’s roughly an 80% difference in the hourly rate. The savings with BYOL can be massive over time – a workload using 50 OCPUs full-time could cost on the order of $ 50,000 per month, license-included, versus approximately $ 12,000 per month with BYOL (plus whatever support you continue to pay for your licenses). Therefore, if your organization already owns Oracle database licenses (and they’re the correct editions for Exadata), leveraging them in a BYOL model is a huge cost optimization. Many enterprises use a mix: BYOL for steady-state workloads to save money, and license-included for new or transient workloads where they might not have spare licenses.
Universal Credits and Annual Commitment: Oracle typically sells Cloud@Customer services through its Universal Cloud Credits model. In practice, this means you agree to an annual cloud spend and you draw down against it as you consume OCPUs and other services. Most deals are not pure pay-as-you-go, month-to-month; instead, you commit to spending a certain amount each year (like a cloud prepaid plan) in exchange for discounts. Volume discounts can be significant – for example, committing around $ 500,000 per year might yield ~10% off, $ 1,000,000 per year might get ~15% off, and very large deals have seen much higher discounts (30-50% off list prices) negotiated. Enterprises should right-size their commitment by negotiating a yearly minimum spend that reflects realistic usage, so you’re not left with unused credits (which expire if not used). It’s often wise to start with a conservative commitment and then increase it later if needed, rather than overcommitting from the start. Also consider negotiating a ramp-up: perhaps a lower commitment in year 1 (while you migrate workloads) and a higher one in later years as usage grows. This aligns costs to actual adoption.
Support Rewards and Bundling: Oracle has introduced programs like Support Rewards, where your spend on Oracle Cloud (including Cloud@Customer) can earn credits to offset your on-prem support bills (e.g., $0.25 credit for every $1 spent, if eligible). This effectively can reduce your overall Oracle spend if structured properly. Additionally, Oracle sales sometimes offer bundle deals – for instance, “commit to Oracle Cloud usage and we’ll give you a discount on your existing database support or licenses.” While these can improve short-term economics, be cautious: don’t commit to more Cloud@Customer capacity than you need just to get a separate discount. Always calculate the net effect. The key is to ensure any incentives truly align with your plans and that you’re not left paying for unused cloud services.
No Ownership, Renewal Considerations: Since you do not own the hardware, at the end of the 4-year term, you have two options: either renew the subscription (possibly with refreshed hardware) or return the equipment and do without it. There is no buy-out option to keep the hardware. This means you should plan for the end of term well in advance. Ideally, negotiate renewal price caps or at least clarity on how a renewal will be priced; otherwise, you could face a steep increase or a tough choice between migration and paying more. Some contracts allow for the conversion of the investment to Oracle Cloud public services or other flexibility options if you choose not to continue with Exadata on-premises, but such clauses must be negotiated. Essentially, treat the relationship with Oracle as an ongoing service partnership rather than a one-time purchase.

Overall, the Cloud@Customer pricing model can offer cost benefits if you utilize the capacity well and leverage discounts/BYOL. But it also introduces commitment risk – you’re on the hook for a significant spend over several years.

Enterprises need to carefully analyze the TCO: compare the 4-year subscription cost (plus any license/support costs in BYOL scenario) to the alternative of buying hardware and licenses outright or using public cloud.

In many cases, Exadata Cloud@Customer will be more cost-effective for large-scale Oracle environments or when factoring in operational savings; however, due diligence is key. The next section on challenges will highlight some cost-related pitfalls to be aware of.

Challenges and Pitfalls to Avoid

While Oracle Exadata Cloud@Customer offers clear advantages, it also presents constraints and potential pitfalls that CIOs should proactively manage.

Here are some common challenges and how to address them:

Long-Term Lock-In & Refresh Cycles: The standard 4-year term means you are effectively locked in for that duration. You can’t just drop the service without penalty if needs change. Additionally, since you don’t own the hardware, you’ll need to either renew (often with new hardware) or migrate off at the end of the term. This forced refresh every few years can be double-edged: you get up-to-date hardware, but you lose the flexibility to extend the life of an asset. Mitigation: Negotiate terms upfront for what happens at renewal – e.g., a cap on price increases for renewal or flexibility to transition to the cloud. Also, have an exit strategy; know how you would migrate databases elsewhere if needed. Planning for the end at the beginning is essential.
Overprovisioning (Oversizing the System): Oracle’s sales team may propose a larger Exadata configuration than you truly need (full rack when a quarter rack might do) or suggest high OCPU counts “for future growth”. Remember that a larger system not only incurs higher base fees, but also carries higher minimum OCPU charges (since each database server has a minimum requirement). Buying excess capacity can lead to paying for idle resources. Mitigation: Right-size the environment based on current and near-term needs. Start with the smallest configuration that meets your requirements and ensure the contract allows scaling up later. Many companies save millions by starting with a base or quarter rack and only expanding when growth occurs.
Minimum Usage Commitments: As mentioned, Oracle imposes a minimum usage commitment. If each node has, say, an 8 OCPU minimum, a quarter rack with two nodes means you pay for at least 16 OCPUs all the time, even if your actual usage is less. This can catch customers off guard, especially if they initially migrate only a few small databases. Mitigation: Be fully aware of the built-in minimums of your chosen Exadata configuration. Consolidate workloads to use fewer nodes if possible (to avoid multiplying the idle core costs). Plan your migration to utilize the capacity you’re paying for. It may be wise to delay starting the cloud billing until you have a certain number of databases ready to go, so you’re not wasting credits on an empty platform.
Cost Overruns from Overcommitment: In an annual commit model, if you overestimate your usage and commit too high, you end up paying for cloud credits that expire unused. This is essentially wasted budget. Conversely, if you underestimate and use more, you’ll pay on-demand rates (though Oracle often keeps your discount for overage, it’s not guaranteed that you’ll get a better rate without renegotiating). Mitigation: Forecast cautiously and choose a commit level on the lower end of what you expect to use. It’s easier to increase later than to swallow unused spend. Also, negotiate the ability to adjust the commitment. Some flexibility (such as carry-over of unused credits or a mid-term adjustment clause) can sometimes be achieved with Oracle if you request it.
Complex Contracts & Hidden Charges: The Cloud@Customer contract can be quite complex, with many line items and terms. Additional charges may apply for optional services, networking, or specific features. Additionally, the SLA terms and support processes may differ from what you expect. Mitigation: Thoroughly review the contract and SLA documents. Engage your procurement and legal teams, and if possible, an Oracle licensing expert. Clarify details such as: what support is included? How quickly will Oracle respond to issues with on-premises hardware? What happens if you need more capacity mid-term? Are there any charges for returning the hardware? Understanding and negotiating these details will prevent unpleasant surprises later. Key areas to focus on are outlined in the FAQ (like ensuring you have terms for SLAs and exit conditions).
Organizational Readiness: Adopting Exadata Cloud@Customer isn’t just a technical install; it’s an operational change. If your team treats it like just another on-prem box, you might miss out on the benefits or, worse, run into friction with Oracle’s processes. For example, your DBAs need to learn Oracle’s cloud tooling and adapt to not having full system admin rights. Your data center team must coordinate with Oracle for hardware fixes. Mitigation: Invest in training and process updates. Ensure your team is familiar with using the OCI console for managing Exadata C@C, and update your procedures for backup, recovery, monitoring, and other related tasks to integrate with the Oracle-managed aspects. Plan the division of responsibilities clearly (who calls Oracle when an issue arises? How do you escalate the issue? Who monitors usage and cost?). With proper preparation, you’ll smoothly integrate the on-prem cloud into your operations rather than treating it as a foreign element.

By being aware of these challenges and proactively addressing them, you can avoid common pitfalls and ensure your Exadata Cloud@Customer deployment delivers the expected value. Many of these issues boil down to negotiating smartly and planning thoroughly – themes we’ll emphasize in the next section.

Recommendations

Drawing on real-world lessons, here are practical recommendations for CIOs and enterprise architects to maximize success with Oracle Exadata Cloud@Customer:

Evaluate Fit for Purpose – Don’t assume Exadata C@C is the right answer for every workload. Assess your requirements: if you don’t have strict data residency or latency needs, a simpler solution or pure public cloud might suffice. Use Exadata Cloud@Customer strategically, where it adds value (e.g., consolidating dozens of Oracle databases onto one platform, or enabling cloud services in a country where public cloud isn’t an option). Ensure the use cases justify bringing in this specialized on-prem cloud.
Perform a Full Cost-Benefit Analysis – Before signing up, rigorously compare the total 4-5 year cost of Exadata Cloud@Customer to alternatives. Include everything: base fees, projected OCPU usage costs, network connectivity, and any license expenses. Compare that against continuing on existing infrastructure, or migrating to Oracle’s (or another vendor’s) public cloud, or even non-Exadata solutions. This analysis will show the break-even point. Exadata C@C can be cost-efficient, especially at scale or when it replaces multiple siloed systems – just ensure the math works in your favor and you’re not paying a premium for capacity you won’t use.
Optimize Licensing (BYOL vs. Included) – Develop a clear licensing strategy upfront. Inventory your current Oracle Database licenses and see which can be repurposed for BYOL. By using BYOL for workloads you already have licensed, you significantly reduce cloud subscription fees. For any new workloads where you lack licenses, factor in the higher cost of license-included usage. Sometimes it may make sense to purchase more perpetual licenses to use as BYOL if that’s cheaper over the long run (and if you plan to maintain support on them). The goal is to avoid paying Oracle twice for the same capability. Also, ensure you understand Oracle’s rules, such as how many on-premises processor licenses equate to one OCPU in the cloud model, and any minimum license quantities required.
Negotiate Contract Terms Aggressively – Treat the Oracle proposal as a starting point for negotiations. Everything is negotiable: the base infrastructure fee, the OCPU unit rates, the annual commitment amount, discount percentages, and more. Enterprises with strong negotiation have secured substantial discounts well beyond the standard rate card. Additionally, negotiate important terms: try to lock in the per-unit pricing for future expansions (so Oracle can’t charge you extra if you add capacity later), and seek caps on price increases for renewal. If SLAs (uptime, performance) are critical, ensure they are contractually guaranteed with remedies (such as service credits). Use any leverage – such as considering a competitive database solution or highlighting an upcoming license renewal – to encourage Oracle to be flexible. The contract will define your financial and operational experience for years, so push to make it as customer-friendly as possible.
Plan the Deployment Meticulously – Engage early with Oracle’s team to map out the installation and migration. Make sure your data center is prepared: adequate space and power for the rack, proper cooling, and the necessary network setup (including a low-latency link to Oracle Cloud for management). Schedule the actual hardware delivery and installation for a time that minimizes impact on your facility (some organizations do it over a weekend or during a slower period). Also, plan the cutover of databases: which applications will move to Exadata C@C and in what sequence. A pilot or proof-of-concept migration of a non-critical database is highly recommended to validate performance, connectivity, and processes. This planning step is crucial to avoid surprises during go-live – essentially, measure twice, cut once.
Prepare Your IT Team – Treat Exadata Cloud@Customer adoption as a transformational project, not just another hardware refresh. Bring your DBAs, system admins, network engineers, and security team up to speed on how this model works. Identify skill gaps and provide training on OCI interfaces, Exadata specifics, and the new operational processes. Update your runbooks: for example, how are backups taken now? (Maybe using Oracle’s cloud tooling or integrated with Oracle’s backup service.) Who is responsible for monitoring database health – your DBAs via Enterprise Manager or Oracle via their tooling? How will patches and maintenance windows be communicated? Laying out these operational details and responsibilities clearly will help your staff embrace the new model rather than fight it. Early training and clear communication go a long way.
Monitor Usage and Adjust Continuously – Once the system is up and running, instill a culture of actively monitoring utilization and costs. Leverage the cloud metrics Oracle provides for Exadata C@C to track OCPU hours used, storage consumed, performance statistics, and more. This will help optimize costs – for example, you might find that non-production databases can be shut down on weekends to save OCPU hours, or that you can scale certain databases down at night. Unlike fixed on-premises systems, this platform allows for dynamic scaling, so utilize it to your advantage to control your spend. Additionally, by monitoring, you’ll know if/when you need to expand. Don’t wait until you’re at capacity; plan for capacity increases with Oracle ahead of time (and ensure the contract covers the terms for expansion). Regular reviews with your Oracle account team on usage versus commit can also help you stay on track and avoid penalties or surprises.

By following these recommendations, enterprises can significantly reduce the risk associated with their Exadata Cloud@Customer initiative and maximize the value gained. In essence: do your homework (fit and cost analysis), negotiate smartly, prepare your people, and keep a close eye on usage.

Checklist: 5 Actions to Take

For a quick actionable plan, here’s a five-step checklist for CIOs and enterprise IT teams considering or implementing Oracle Exadata Cloud@Customer:

Identify Candidate Workloads – Make a list of the databases and applications that truly require an on-premises cloud solution. Prioritize those with compliance constraints, latency-sensitive requirements, or those earmarked for consolidation. Confirm that these workloads are supported on Exadata Cloud@Customer and will benefit from the Exadata environment (e.g., Oracle Database workloads that would gain performance or operational improvements).
Assess Your Oracle License Inventory – Document all Oracle database licenses (and other Oracle software) your organization currently owns, along with their editions and support status. Determine which of these licenses could be used in a BYOL model on Exadata C@C. This step will highlight any license shortfalls for the planned workloads and help you determine if you need to purchase additional licenses or utilize Oracle’s license-included subscription for specific components. It also ensures you remain compliant with Oracle’s policies when moving licenses to an on-prem cloud deployment.
Verify Infrastructure Readiness – Check that your data center facilities can accommodate Oracle’s Exadata rack. This includes confirming you have sufficient rack space (including floor loading and rack height clearance), enough power circuits and UPS capacity to handle a full Exadata rack power draw, and proper cooling. Additionally, set up the required network connectivity: typically a reliable high-bandwidth connection to Oracle Cloud (OCI FastConnect or VPN) for Oracle to manage the system and for any hybrid cloud integration. Also prepare IP addresses and DNS entries for the Exadata as needed in your environment. Iron out all the on-prem hosting requirements before the hardware arrives.
Form a Cross-Functional Negotiation Team – Assemble a team that includes IT leadership, procurement/contracts, finance, and legal. Develop a negotiation game plan for the Exadata Cloud@Customer contract. This plan should outline your target discounts, must-have contract clauses (like renewal terms or exit options), and a walk-away cost threshold. Engage with Oracle’s sales team with a united front: having technical folks to validate sizing, finance to model costs, and legal to catch unfavorable terms will help you secure a better deal. Leverage any internal benchmarks or alternative proposals to strengthen your negotiating position.
Draft a Migration and Governance Plan – Before Exadata is live, create a high-level migration plan for moving selected workloads onto it. Define waves or phases of migration (perhaps starting with dev/test databases, then non-critical production, and finally critical production). Include the timing for each phase, the responsible parties, and the fallback plans. In parallel, establish a governance model for ongoing operations: decide who on your team will interface with Oracle for support, how you will monitor usage and performance (e.g., daily or weekly reviews), and how costs will be tracked and reported. Having this plan will ensure a smooth rollout and continuous management once the Exadata Cloud@Customer is in use.

By completing these five action items, your organization will be well-prepared not only to adopt Exadata Cloud@Customer but to get real value from it quickly and efficiently.

FAQ

Q1: How is Oracle Exadata Cloud@Customer different from Oracle’s public cloud or a traditional on-prem setup?
A: Exadata Cloud@Customer is essentially the same technology and cloud services that Oracle offers in its public cloud (OCI), but deployed on your premises. The key differences are in location and control. With Cloud@Customer, all hardware resides in your data center (you provide the floor space, power, cooling), and data never leaves your site – which is unlike Oracle’s public cloud, where data is in Oracle’s data centers. However, like the public cloud, Oracle manages the infrastructure and updates remotely. Compared to a traditional on-prem setup, Cloud@Customer is rented (not owned) and managed by Oracle (not your admins). You get cloud APIs and a cloud consumption model on-prem, whereas a traditional Exadata would be fully owned and managed by you. In short, Cloud@Customer provides a private, single-tenant cloud experience within your data center, combining the on-premises control of traditional deployments with the operational model of Oracle’s cloud.

Q2: What are the primary use cases for Exadata Cloud@Customer in large enterprises?
A: The most common use cases involve scenarios where public cloud is not viable or optimal, but the organization still wants cloud benefits. This includes regulatory or data sovereignty cases (e.g. a healthcare company keeping patient data on-site to meet privacy laws, using Exadata C@C to run their databases), ultra-low latency applications (manufacturing or trading systems that must have the database next to the application to meet real-time requirements), and mass database consolidation or modernization efforts (replacing dozens of old Oracle servers with one Exadata C@C platform to use automation and reduce footprint). Additionally, some use it as a stepping stone to the cloud – for instance, an enterprise might not be ready to jump to a public cloud, so they use Cloud@Customer to start their cloud journey on-premises, gradually migrating some workloads to Oracle Cloud later. In summary, any case where you need cloud tech on-premises for control, compliance, or performance reasons is a good fit for Exadata Cloud@Customer.

Q3: How does the pricing of Exadata Cloud@Customer compare to regular cloud or owning hardware outright?
A: The pricing model of Exadata C@C is similar to Oracle’s cloud in that you pay monthly for what you use, but there is also a fixed fee for the dedicated hardware. Whether it’s cheaper or more expensive depends on your situation. If you fully utilize Exadata (i.e., run it near capacity), the cost per database workload can be on par with or even less than that of the public cloud, especially after negotiating discounts. Oracle often provides better pricing per unit if you commit to a large capacity. On the other hand, if you only use a small fraction of Exadata’s power, you’ll still be paying the base fee for the whole machine, which could make it more expensive than a purely elastic cloud service. Compared to owning hardware, Exadata C@C may appear pricier over a four-year period, but remember that it includes hardware maintenance, support, and cloud management services. Owning an Exadata outright requires a big upfront purchase and ongoing support fees, and you’d still need DBAs and admins to manage it entirely. Cloud@Customer shifts that to a pay-as-you-go model with Oracle sharing the management. For many enterprises, the value comes in flexibility and offloading work, not just the raw dollar-to-dollar infrastructure cost. Each organization should do a TCO analysis: sometimes the pure expenditure will be higher with Cloud@Customer, but the strategic benefits and avoided costs (staff effort, faster projects, etc.) justify it.

Q4: What are our responsibilities versus Oracle’s in this managed model?
A: Oracle Exadata Cloud@Customer is a fully managed service, but it’s a partnership between your organization and Oracle. Oracle is responsible for all infrastructure-level tasks, including delivering and installing the Exadata rack, monitoring hardware health, replacing failing components, applying patches and upgrades to the Exadata infrastructure, and ensuring the platform runs as promised. Your team is responsible for the database and application layers: you set up and manage the databases (unless using autonomous mode), manage your data, configure your applications to use the databases, and handle user access and security at the database level. Additionally, your team is responsible for providing the physical hosting needs (space, power, and network) and must maintain the network link that enables Oracle to manage the system. A useful way to think of it: Oracle provides and cares for the engine and the car; you decide where to drive it and handle the passengers and cargo. Both sides collaborate on security: Oracle secures the box and cloud service; you secure your accounts, data, and compliance aspects. It’s essential to review Oracle’s documentation on the shared responsibility model for Cloud@Customer to ensure nothing falls through the cracks.

Q5: What key points should we negotiate or watch out for in the contract?
A: Focus on the commitment, pricing protections, and exit strategy. Specifically: (1) Commitment size and term – ensure the minimum OCPU/core commitment and the term length match your needs; negotiate them down if Oracle’s proposal is more than you require. (2) Discounts and unit rates – push for better rates on both the base infrastructure and OCPU hourly charges; large commitments usually have room for extra discount beyond the initial quote. Also, clarify how prices could change over time (e.g., can Oracle raise rates mid-term? Ideally, no, so lock them). (3) Service Level Agreements (SLAs) – get clear uptime and support SLAs from Oracle, and ideally remedies (like service credits) if those aren’t met. Since this will run critical workloads, you need assurance of performance and support response. (4) Upgrade/Expansion Terms – it’s wise to pre-negotiate the cost of any expansion (like adding more OCPUs or another rack later) and how upgrades to new hardware generations will be handled. (5) Exit and End-of-Term – have a plan in writing for what happens at the end of the term or if you want to terminate early. For instance, can you transition to an Oracle public cloud service or get a smaller configuration if needed? Ensure that provisions are in place for data extraction and migration assistance if you choose not to renew. The goal is to avoid being stuck or surprised at renewal time. Finally, involve your legal and security teams to include any necessary data protection clauses, since the equipment is on your premises but managed by Oracle. Covering these points in the contract will save you headaches later and ensure a smoother experience throughout the service’s lifecycle.

Need a partner to help you move to ExaCC?

Author

Fredrik Filipsson

Fredrik Filipsson is the co-founder of Redress Compliance, a leading independent advisory firm specializing in Oracle, Microsoft, SAP, IBM, and Salesforce licensing. With over 20 years of experience in software licensing and contract negotiations, Fredrik has helped hundreds of organizations—including numerous Fortune 500 companies—optimize costs, avoid compliance risks, and secure favorable terms with major software vendors. Fredrik built his expertise over two decades working directly for IBM, SAP, and Oracle, where he gained in-depth knowledge of their licensing programs and sales practices. For the past 11 years, he has worked as a consultant, advising global enterprises on complex licensing challenges and large-scale contract negotiations.
View all posts

Oracle Exadata Cloud at Customer – The Complete Guide