A four year commercial programme wearing a technology badge
Oracle Cloud at Customer is not a hardware decision. This playbook walks the CIO through the full deployment arc: the decision case, sizing the commitment, the data center and network prerequisites, the migration ramp, the operating model after the rack is live, the BYOL choice, and the renewal position the deal creates. The platform decision is usually defensible. The programme around it usually is not.
Prepared by Redress Compliance · August 9, 2026 · Oracle advisory. Based on roughly 10 to 15 Cloud at Customer evaluations and deployments advised 2024 to 2025.
Executive summary
Sizing honesty is the single biggest cost lever, and the commits ran high. In our 2024 to 2025 evaluations, signed minimums ran 1.5x to 2x realistic year one consumption because sizing followed the migration ambition slide, not a dated migration plan.
The rule that removed more cost than every rate negotiation combined is to size from a named, dated plan and commit to 40 to 60 percent of modeled steady state in year one, stepping up on dated migration waves with a contractual expansion option at the same rate.
The sizing workshop needs three inputs on the table at once, the DBA consolidation map, the application owners' cutover constraints, and finance's run rate; any exercise missing one produces a number Oracle will happily sign.
You are signing two stacked obligations, and every dollar of the minimum is owed whether workloads arrive or not. A fixed infrastructure subscription for the rack runs from activation on a four year term regardless of usage, and a consumption commitment draws down against a committed minimum.
Treat the two lines separately in every model, because CIOs who blend them into one cloud number lose sight of which lever moves which cost.
Inside the floor sits another floor: on Exadata Cloud at Customer each database server carries a minimum activation of eight ECPUs per database node, so a two node VM cluster never bills below sixteen ECPUs whether or not a database is busy. Cluster design is a billing decision.
Skipped BYOL analysis left 20 to 35 percent of run cost on the table.
The bring your own license against license included comparison was skipped in most first proposals, and it should be run workload by workload before signature because the license posture sets the consumption rate per ECPU and is fully your choice per workload.
The levers that actually move the price are commit size honesty, a stepped ramp that follows the waves rather than a flat minimum, the credit rate, which follows commit size and credible alternatives rather than goodwill, the license posture, and renewal protection.
None of them are goodwill; all of them are arithmetic, and the arithmetic has to be on the table before Oracle still wants the deal.
Month 48 is where unprotected estates get repriced, so cap the second term in the original order. Nobody owned month 48 in most of the deals we saw: no renewal cap, no exit mechanics, no data handover terms in the original paper, which is exactly where the leverage has already changed hands.
Plan 4 to 8 months from signature to first production workload, because the site survey, power and network readiness set the pace, not Oracle's delivery, and first workload dates slipped by a quarter or more while the meter terms were already agreed.
The renewal terms are silent unless you write them in, and in practice they are only negotiable before signature, while Oracle still wants the deal.
When it is the right call, and who should not buy
| Test before any commercial conversation | What clears it | What fails it |
|---|---|---|
| Residency or latency | A regulator, sovereignty rule, or sub 2ms adjacency genuinely blocks a public region | A preference for on premises, where the regulator accepts an in country public region |
| Estate shape | The workloads moving in are Oracle databases and their close dependencies | A general purpose application estate, which points at public OCI or a hyperscaler |
| Commitment | You can name the databases, the wave dates, and the steady state for four years | An aspirational migration plan with no signed cutover dates |
| Volume | A serious database estate where consolidation justifies the rack | A handful of databases, where the infrastructure floor dominates and public OCI wins |
| Direction | An estate you are keeping and consolidating onto Oracle | A portfolio you intend to shrink or move off Oracle |
The family splits into two footprints, and the split decides which teams live with the deal.
Exadata Cloud at Customer is the database rack, the landing zone for regulated Tier 1 estates, RAC clusters and consolidation programmes.
Compute Cloud at Customer is a broader slice of OCI services on premises for VMs, containers and storage beside the databases, a smaller entry point with a narrower catalog than a public region.
Both together are common in sovereign estates, but each carries its own subscription and its own floor, so two racks means two meters, not one. Choose by estate composition, not by catalog envy.
The choice between Cloud at Customer and a full Dedicated Region sits in the comparison, and the family, meter and responsibility split in the licensing guide.
The anatomy of the four year commitment
- Infrastructure subscription: the rack, Oracle operations and maintenance, billed fixed monthly from activation on a four year term. The rate and start date are negotiable, the term rarely.
- Consumption commitment: database and compute usage on the rack, a monthly drawdown against a committed minimum. Size, ramp schedule and credit rate are all negotiable.
- License posture: BYOL or license included, which sets the consumption rate per ECPU and is fully your choice per workload. Run it workload by workload before signature, because skipping it left 20 to 35 percent of run cost unexamined.
- Renewal terms: what happens at month 48, silent unless you write them in, and in practice only negotiable before signature. Cap the second term rate in the original order while Oracle still wants the deal.
- The floor inside the floor: each database server carries a minimum activation of eight ECPUs per database node, so a two node VM cluster never bills below sixteen ECPUs. Multiply that across every cluster your architects draw and the idle floor becomes real money.
The Cloud at Customer strategy playbook
The decision case, the sizing math, the phase gates, and the renewal position, worked through a benchmark estate.
Get the white paper →Sizing the commit so it survives contact with reality
Size from a dated, named migration plan and commit to 40 to 60 percent of modeled steady state in year one. That single rule, applied with discipline, removed more cost in our engagement file than every rate negotiation combined.
The sizing workshop needs three inputs on the table at once: the DBA team consolidation map, the application owners cutover constraints, and finance view of the current run rate. Any sizing exercise missing one of the three produces a number Oracle will happily sign.
Take an illustrative estate of 60 production databases on aging Exadata and VMware, consolidating onto Exadata Cloud at Customer, where the consolidation map lands them in four VM clusters at a modeled steady state of 240 ECPUs.
A flat commit to the full 240 from day one pays for capacity that arrives over two years; a stepped commit that opens near 40 to 60 percent and rises on dated waves pays for what is actually running, with a contractual expansion option holding the rate for the capacity still to come.
The stepped minimum beats the flat minimum every time migration risk exists, and migration risk always exists.
Plan 4 to 8 months from signature to first production workload, because the site survey, power and network readiness set the pace rather than Oracle delivery.
And first workload dates slipped by a quarter or more in our file while the meter terms were already agreed, which means the ramp has to assume the slip rather than the slide.
The migration ramp mechanics and the BYOL choice underneath the rate sit in the BYOL versus license included comparison, and the disaster recovery footprint, which quietly doubles a cluster count, in the DR cloud licensing guide.
- Percentile standing for your exact deal size and industry, from real closed transactions
- Scenario simulation before the call: test alternative terms and see the financial impact of each
- A negotiation playbook, talking points, and a two page executive brief on day one
What we saw across Cloud at Customer deployment programmes, 2024 to 2025
Across roughly 10 to 15 Cloud at Customer evaluations and deployments Fredrik Filipsson advised between 2024 and 2025, the platform decision was usually defensible and the programme around it usually was not. The recurring gaps were consistent, and they were programme gaps, not technology gaps:
How far signed minimums ran above realistic year one consumption, because sizing followed the migration ambition slide rather than a dated migration plan.
How far first production workload dates slipped while the meter terms were already agreed, because facilities readiness was assumed rather than surveyed.
The BYOL against license included comparison was skipped in most first proposals, leaving 20 to 35 percent of run cost unexamined, and nobody owned month 48, so there was no renewal cap, no exit mechanics and no data handover terms in the original paper.
The operating model after the rack is live is a shared one most teams have not run: Oracle owns the infrastructure and its patch cadence, you own the guest operating system, Grid Infrastructure and database patching.
And the escalation path between the two has to be agreed before go live rather than discovered at the first storage cell fault.
The renewal at month 48 is the moment the whole programme either pays off or unwinds, because an estate that arrives at term end with no cap negotiates repricing from Oracle's number, exactly as an audit finding negotiated after disclosure does.
The commercial levers for the negotiation itself sit in Oracle cloud negotiations, the meter mechanics in the ExaCC billing article, and the drawdown and forfeiture rules in OCI cost optimization. This playbook owns the execution: what a CIO signs, builds, migrates, operates and renegotiates.
Your first five moves
- Run the three tests before any commercial conversation: residency or latency, estate shape, and a four year commitment you can name databases and wave dates against. Preference is not a mandate.
- Size from a dated migration plan, not the ambition slide, and open the commit at 40 to 60 percent of modeled steady state with a contractual expansion option at the same rate.
- Survey the site before you agree the meter: power, network and floor readiness set a 4 to 8 month pace, and a slipped first workload against an agreed minimum is paid in idle ECPUs.
- Run BYOL against license included workload by workload before signature, the analysis that recovers 20 to 35 percent of run cost.
- Write month 48 into the original order: a second term rate cap, exit mechanics, and data handover terms, agreed while Oracle still wants the deal. The Oracle practice runs the programme with you.
Frequently asked questions
Is Oracle Cloud at Customer a technology decision or a commercial one?
Primarily commercial. It is a four year programme wearing a technology badge: a fixed infrastructure subscription for the rack running from activation regardless of usage, plus a consumption commitment owed whether or not the workloads arrive.
The platform itself is usually defensible for a regulated, database shaped estate, but the cost outcome is decided by the programme around it, the sizing, the ramp, the license posture, and the renewal terms, not by the hardware.
How should you size a Cloud at Customer commitment?
From a dated, named migration plan, committing to 40 to 60 percent of modeled steady state in year one and stepping up on dated migration waves, with a contractual expansion option at the same rate.
In our 2024 to 2025 evaluations, signed minimums ran 1.5x to 2x realistic year one consumption because sizing followed the ambition slide. The sizing workshop needs the DBA consolidation map, the application cutover constraints, and finance's run rate all on the table at once.
What is the ECPU minimum activation on Exadata Cloud at Customer?
Each database server carries a minimum activation of eight ECPUs per database node, running and billing whether or not a database is busy on it. A two node VM cluster therefore never bills below sixteen ECPUs.
Multiply that across every VM cluster your architects draw and the idle floor becomes real money, which is why cluster design is a billing decision, not only an availability one.
Should you choose BYOL or license included on Cloud at Customer?
Run the comparison workload by workload before signature, because the license posture sets the consumption rate per ECPU and is fully your choice per workload. Skipping the analysis left 20 to 35 percent of run cost unexamined in most first proposals.
BYOL uses entitlements you already own against a lower consumption rate; license included folds the license into the rate. The right split is per workload, decided on your actual entitlement position and migration horizon.
How long does a Cloud at Customer deployment take?
Plan 4 to 8 months from signature to first production workload. The site survey, power and network readiness set the pace, not Oracle's delivery, and in our engagement file first workload dates slipped by a quarter or more while the meter terms were already agreed.
Because the infrastructure charge runs from activation regardless of usage, a ramp that assumes the slip rather than the ambition slide is what keeps early idle capacity off the invoice.
Why does month 48 matter on a Cloud at Customer deal?
Because it is where unprotected estates get repriced.
The renewal terms are silent unless you write them into the original order, and by term end the leverage has already changed hands, so an estate with no second term rate cap, no exit mechanics and no data handover terms negotiates repricing from Oracle's number.
Cap the second term rate in the original paper, while Oracle still wants the deal, rather than at term end when it does not.
How to Negotiate the Oracle Java Employee Agreement: Honest Leverage in a Captive Deal
Priced per employee, every employee, from $15 down to $5.25. At renewal your leverage is thin and OpenJDK threats rarely land. The one-year runway, trading through the wider Oracle relationship, and containing what you sign.
