Oracle Practice
Oracle Cloud at Customer. The CIO deployment playbook.
OCI in your own data center, billed as cloud. The technology case is usually sound; the programme and the commercial structure are where CIOs lose money.
OCI in your own data center, billed as cloud. The technology case is usually sound; the programme and the commercial structure are where CIOs lose money.
Oracle Cloud at Customer is a four year commercial programme wearing a technology badge. This playbook walks the CIO through the full deployment arc: the decision case, sizing the commitment, 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.
Cloud at Customer is the right call when three conditions hold at once: the workload cannot leave your building, the estate is heavily Oracle database shaped, and you can commit to four years of consumption with a straight face. Miss any one of the three and a cheaper answer usually exists.
The product puts Oracle owned, Oracle operated cloud hardware inside your data center, billed as cloud consumption. Oracle describes the family on its Cloud at Customer page. What that page does not describe is the programme you must run around it.
The family splits into two footprints, and the split decides which teams live with the deal. Choose by estate composition, not by catalog envy.
The honest disqualifiers matter as much as the fit tests. Walk away, or choose a different footprint, when any of these describes you:
Two adjacent decisions live on their own pages. The choice between Cloud at Customer and a full Dedicated Region is covered in the Cloud at Customer versus Dedicated Region comparison, with Oracle's Dedicated Region page defining the larger footprint.
The product family, the meter mechanics, and the responsibility split are set out in the Cloud at Customer licensing guide. This playbook owns the execution: what a CIO signs, builds, migrates, operates, and renegotiates.
You are signing two stacked obligations: a fixed infrastructure subscription for the rack, typically on a four year term, and a consumption commitment drawn down against Oracle's universal credit pricing. The infrastructure charge runs from activation regardless of usage. The consumption minimum is owed whether or not the workloads arrive.
Treat the two lines separately in every model. CIOs who blend them into one "cloud number" lose sight of which lever moves which cost.
The Cloud at Customer commitment stack
| Layer | What it covers | How it bills | Negotiable? |
|---|---|---|---|
| Infrastructure subscription | The rack, Oracle operations, maintenance | Fixed monthly, from activation, four year term | Rate and start date, rarely the term |
| Consumption commitment | Database and compute usage on the rack | Monthly drawdown against a committed minimum | Size, ramp schedule, credit rate |
| License posture | BYOL or license included rates | Sets the consumption rate per ECPU | Fully, and it is your choice per workload |
| Renewal terms | What happens at month 48 | Silent unless you write them in | Only before signature, in practice |
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. Cluster design is a billing decision; the mechanics are covered in the ExaCC billing article.
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's consolidation map, the application owners' cutover constraints, and finance's 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: 60 production databases on aging Exadata and VMware, consolidating onto Exadata Cloud at Customer. The consolidation map lands them in four VM clusters at a modeled steady state of 240 ECPUs by month 30.
A flat commitment at 240 ECPU equivalent from month one means paying for roughly triple the actual consumption through month 9, and the unconsumed dollars never come back. A stepped minimum priced at the same credit rate tracks the waves and shifts the slippage risk back toward the plan, where it belongs.
Ramped minimum against flat minimum, illustrative estate above
| Contract year | Modeled consumption | Ramped minimum | Flat minimum | Exposure if waves slip a quarter |
|---|---|---|---|---|
| Year 1 | 40 percent of steady state | 45 percent | 100 percent | Small against ramped, severe against flat |
| Year 2 | 70 percent | 70 percent | 100 percent | Moderate against flat |
| Year 3 | 95 percent | 90 percent | 100 percent | Low either way |
| Year 4 | 100 percent | 100 percent | 100 percent | None |
Your facility must pass Oracle's site survey on power, cooling, floor loading, and space, and your network team must deliver a permanently available management path for Oracle's remote operations. In our file, facilities and network readiness set the go live date far more often than Oracle's hardware delivery did.
Start the survey work in parallel with commercial negotiation, not after signature. A quarter of slippage on a signed meter is pure cost.
Name one owner for site readiness with authority over facilities, network, and security. In the deployments that went smoothly, that person held a weekly readiness review from signature to activation, with Oracle's delivery team in the room.
Run it as five gates, and refuse to let commercial pressure collapse them. Every troubled deployment in our file skipped or merged a gate, usually gate zero or gate two.
The five gate Cloud at Customer programme
| Gate | What must be true to pass | Typical timing |
|---|---|---|
| Gate 0: Decision case | Three way price comparison done, residency claim validated, dated migration plan exists | Months 1 to 3 |
| Gate 1: Contract | Ramped minimum, expansion option, renewal cap, and exit mechanics all in the signed order | Months 2 to 4 |
| Gate 2: Site ready | Survey passed, network path live, access protocol agreed, activation date fixed | Months 3 to 6 |
| Gate 3: First production workload | Wave 1 cut over, backup and DR proven, operating model exercised in anger | Months 4 to 9 |
| Gate 4: Steady state | All waves landed, consumption within 10 percent of plan, renewal file open | Months 24 to 36 |
Laid end to end, a well run deployment reads like this. Treat slips against it as commercial events, not merely project events, because the meter does not distinguish.
Gate three is not a technical milestone; it is the first time your operating model, Oracle's operations team, and a production workload coexist. Prove the backup restores, run one failover, raise one severity ticket, and take one patch window before wave two starts.
The rack is Oracle's deliverable. The programme is yours. Every month the two are confused belongs to the meter.
Five risks account for nearly every dollar of regret in our Cloud at Customer file. Put them on the programme risk register at gate zero with named owners, because every one of them is cheap to prevent and expensive to repair.
The Cloud at Customer risk register, from the engagement file
| Risk | How it shows up | Prevention |
|---|---|---|
| Oversized commit | Unconsumed minimum billed monthly from month one | Ramp schedule sized to dated waves |
| Site not ready | Meter starts while facilities work drags | Survey in parallel with negotiation, activation date gated |
| Wave slippage | Application owners defer cutovers, consumption lags plan | Cutover commitments signed by application owners at gate zero |
| Posture drift | BYOL entitlement mapping decays, audit exposure grows | Entitlement review each wave, owned by the consumption controller |
| Unprotected renewal | Second term reprice with no cap and no alternative ready | Cap at signature, renewal file open at month 30 |
Four years is longer than most CIO tenures and most account team assignments. The people who negotiated the protections will not be the people who exercise them.
Write the deal rationale, the protections, and the month 30 trigger into a handover note that survives personnel change. In two of our engagements, a negotiated expansion option went unused simply because nobody who remained knew it existed.
Run it as a capacity auction you control, not a product purchase you approve. The only Cloud at Customer deals in our file that landed at strong rates had a priced, validated alternative on the table when the order form was drafted.
Oracle's field team is measured on committed consumption. Understanding that single incentive explains most of what happens in the room: the push for the flat commit, the resistance to ramp schedules, the enthusiasm for a longer term.
Two questions, asked early, separate a disciplined proposal from an ambitious one. First: which month does each named database land, and who signed that date? Second: what does this structure cost if every date slips one quarter?
A proposal that cannot answer both in writing is not a proposal. It is a forecast wearing an order form.
The broader playbook for cloud commit negotiations, including credit expiry and swap rights, is covered in Oracle cloud negotiations. The moves above are the Cloud at Customer specific subset that the generic advice misses.
Oracle operates the infrastructure up to the hypervisor and management plane; everything above it, databases, VMs, access, backups policy, and cost, is yours. The deployments that struggled treated the rack as outsourced and discovered at the first incident that only half of it was.
Write the split down as a named responsibility matrix before gate three, and rehearse it. The guide's responsibility section covers the product side; your side needs owners with names.
Workloads on the rack under license included are outside classic deployment counting; BYOL workloads still rest on your entitlements and remain auditable. Keep the entitlement mapping current from wave one, because the estate is now split across two counting regimes.
Run both rates against your real support stream workload by workload, and expect a mixed answer. Estates that skipped the comparison left 20 to 35 percent on the table in our file; the mistake is picking one posture estate wide because it is administratively tidy.
BYOL applies your existing licenses to the rack at a reduced consumption rate under the published Oracle BYOL terms, and your support bill continues. License included retires that support stream for the covered workload but meters at the higher rate.
Every BYOL workload keeps its 22 percent support line alive on premises. Model the four year total as consumption plus retained support, not consumption alone. Some estates found license included cheaper in total precisely because it retired support on shelfware heavy entitlements.
The CFO sees six cost lines, and the Oracle proposal prices exactly two of them. Building the full model before signature is the difference between a defensible business case and a surprise in year two.
The six line Cloud at Customer cost model
| Cost line | In Oracle's proposal? | What to model |
|---|---|---|
| Infrastructure subscription | Yes | Fixed monthly across 48 months from activation |
| Consumption commitment | Yes | Committed minimum, plus the slip scenario where waves land late |
| Retained support on BYOL licenses | No | The 22 percent stream on every entitlement carried into the rack |
| Facilities | No | Power, cooling, space, and physical security for Oracle owned hardware |
| Migration and dual running | No | Old estate costs continue until each wave lands; budget the overlap honestly |
| Exit and renewal exposure | No | Cost of leaving at month 48, and the uncapped reprice if no cap was negotiated |
Migration waves overlap with the estate they replace, and both bill simultaneously. In the illustrative estate above, months 4 through 16 carry old hardware, old support, and the new minimum at once. Present that overlap to the CFO before signature; discovering it in the year one actuals costs credibility as well as money.
A rack in your data center still needs a recovery story, and the licensing of that story is its own discipline. Standby capacity on the rack bills as consumption; a standby in a public region follows cloud counting rules.
The cloud side rules are covered in Oracle disaster recovery cloud licensing. Price the DR tier into the model before the commit is sized, because recovery capacity is consumption too.
An unprotected Cloud at Customer deal creates the weakest renewal position in enterprise infrastructure: your data sits on Oracle's hardware in your building, your alternatives need a year of lead time, and the vendor knows both. The second term is where the economics of the first term get recovered.
The defense is entirely front loaded. Every renewal protection worth having is negotiated at original signature, while competitive tension still exists.
Renewal strength is built, not found. The estates that renewed well shared four artifacts: a capped rate in the original paper, a consumption history within 10 percent of plan, a validated alternative priced by month 36, and a data handover procedure already tested once.
The estates that renewed badly shared one: an assumption that four years of good behavior would be rewarded. It was not, in any file we hold.
The common advice says size the commitment generously, because the unit rate improves with volume and the estate will grow into it. We disagree, and the file is unambiguous: in roughly 8 of the 10 to 15 evaluations Fredrik Filipsson ran in 2024 and 2025, the better unit rate on the larger commit was fully erased by unconsumed minimums before month 30. Oracle sells the discount curve; the buyer lives the consumption curve. The cheaper structure in practice was consistently the smaller ramped commit with a contractual expansion option at the same rate, because consumption risk priced higher than the incremental discount ever paid back. Generosity in sizing is not optimism. It is a transfer payment.
Source: Redress Compliance advisory engagement file, 2024 to 2025.
The Oracle practice runs commercial diligence on Cloud at Customer deals, and Vendor Shield keeps the consumption position reviewed through the term.
Plan 4 to 8 months from signature to first production workload. Site survey, power, network readiness, and your own change process set the pace; Oracle's hardware delivery is rarely the constraint in practice.
Expect a fixed infrastructure subscription on a four year term plus a committed consumption minimum billed against universal credits. Both run whether or not workloads arrive on schedule, which is why the ramp schedule matters more than the headline rate.
Commit 40 to 60 percent of modeled steady state in year one, stepping up on dated migration waves. In roughly 8 of the 10 to 15 evaluations we ran, flat commits cost more in unconsumed minimums than the volume discount saved.
Run both rates workload by workload against your actual support stream; the right answer is usually mixed. Owned stable workloads favor BYOL, new workloads lean license included, and estates that skipped the analysis left 20 to 35 percent on the table.
Power, cooling, floor loading, and space that pass Oracle's site survey, plus a standing secure network path for remote operations. Start the survey in parallel with the negotiation, because facilities readiness is the most common cause of a slipped activation date.
Oracle operates and patches the infrastructure through the management plane; you still operate the databases, VMs, access, and backup policy above it. Your DBA team changes location of work, not headcount, in most estates.
The shortfall is still owed; unconsumed commitment does not roll into the next year unless your contract explicitly says so. This is why sizing to a dated migration plan and holding back roughly 20 percent as an uncommitted buffer protects the economics.
Only if the expansion option is written into the original order. Without contractual language, incremental capacity is priced as a new negotiation, at a moment when your alternatives are at their weakest.
Cloud at Customer delivers Exadata or core OCI services in your data center at a lower entry point; Dedicated Region delivers the full OCI catalog at a materially higher minimum. The comparison has its own dedicated analysis on this site.
No. License included workloads move outside classic deployment counting, but BYOL workloads still rest on your entitlements and remain auditable. The estate splits into two counting regimes, so keep the entitlement mapping current from the first wave.
Notice windows, rack removal timeline, data handover obligations, and a written cap on the renewal rate. None are standard, and all are dramatically cheaper to obtain at signature than at month 46.
The rack is Oracle's property and leaves your data center when the contract ends. Data migration off the platform is physically simple but contractually unpriced unless you fixed the handover mechanics at signature.
Practically, no. The infrastructure subscription and the committed minimum run for the term you signed; scale down flexibility exists only above the committed floor. This asymmetry is exactly why year one should be committed lean.
A single accountable executive owner with a named platform owner, consumption controller, and site readiness lead beneath them. Deployments run by a committee of infrastructure, DBA, and procurement stakeholders without one accountable name slipped gates in our file.
Commit sizing worksheets, ramp templates, BYOL versus license included analysis, and the exit clause checklist.
Used across more than five hundred enterprise engagements. Independent. Buyer side. Built for procurement leaders running the next renewal cycle.
