Oracle Cloud at Customer, ten steps, two license traps.

Migrating to Oracle Cloud at Customer is a ten step sequence, and the two steps buyers get wrong, entitlement baselining and BYOL mapping, are the two that set the cost for the whole term.

When does Oracle Cloud at Customer actually fit?

Cloud at Customer fits when data residency, latency, or regulation keeps workloads on premises but the estate wants OCI economics and operations. Oracle installs and manages Exadata Cloud at Customer hardware in your data center, billed as cloud subscription.

It does not fit as a default refresh path for every Exadata estate. The committed minimums and term lengths make it a capacity bet, and idle committed capacity is the most common regret we see.

What are the ten migration steps in order?

The sequence below front loads the licensing work, because entitlement decisions made early are leverage and the same decisions made late are exposure.

1. Baseline entitlements: full inventory of database, option, and middleware licenses with support status.
2. Verify deployment reality: reconcile what runs where against the entitlement baseline.
3. Classify workloads: residency bound, latency bound, and free to move to public OCI.
4. Model BYOL versus license included: per workload, with option packs mapped explicitly.
5. Size the configuration: against measured utilization, not Oracle proposed capacity.
6. Negotiate the contract: minimums, term, expansion pricing, and support rewards together.
7. Map license conversions: document which entitlements convert, park, or terminate.
8. Pilot the first workload: a contained database with measured cutover and rollback.
9. Migrate in waves: residency bound workloads first, opportunistic moves later.
10. Govern consumption: quarterly reviews against minimums, with the true up calendar diarized.

Where do the two license traps sit?

The traps sit in steps one and four. Skipping the entitlement baseline lets Oracle scope the deal against its own audit view of your estate, and rushing the BYOL mapping prices the configuration against entitlements you do not cleanly hold.

The support rewards interaction

Oracle BYOL terms and Oracle Support Rewards interact: consumption earns credits that retire tech support spend. On large estates the rewards materially change the BYOL versus included math, so model them in before choosing, not after.

Where the common advice on Cloud at Customer is wrong

The standard advice is to treat Cloud at Customer as a technical platform decision and bring licensing in at contract time. We disagree. In roughly 7 of the 10 to 15 Oracle infrastructure deals we advised in 2024 to 2025, the commercial outcome was decided before the contract phase, by whether the buyer or Oracle held the entitlement picture first. The buyer side move is to complete the baseline and the BYOL map before the first sizing workshop. Whoever brings the inventory controls the negotiation.

Cloud at Customer is sold as infrastructure. It is signed as a licensing contract. Prepare for the second one.

Which Oracle documents govern the commercial mechanics?

Two public references anchor the model: the Oracle Cloud at Customer program page and the Oracle Support Rewards terms. Read the rewards accrual mechanics closely; the rate differs by agreement type, and the difference changes the business case.

How do you negotiate the Cloud at Customer contract?

Negotiate four things together: the committed minimum, the term, expansion pricing, and the treatment of existing support spend. Trading them separately lets Oracle win each one on its own logic.

• Minimums: commit at 70 to 80 percent of honest forecast; expansion at locked rates covers the upside.
• Term: shorter beats longer unless the rate concession is structural.
• Expansion pricing: future racks and capacity at signature rates, not future list.
• Support treatment: support rewards, parked licenses, and any ULA interaction documented in the order.

What to do next

The moves below put the licensing work ahead of the hardware conversation, where it belongs.

A sequence you can run this quarter

1. Run the entitlement baseline: licenses, options, support status, and deployment reconciliation.
2. Classify workloads by residency and latency constraint before any Oracle workshop.
3. Build the BYOL versus license included model per workload with option packs mapped.
4. Size against measured utilization and commit at 70 to 80 percent of forecast.
5. Negotiate minimums, term, expansion pricing, and support treatment as one package.
6. Pilot one workload, then migrate in waves with quarterly consumption governance.

White Paper · Oracle

Oracle Cloud at Customer Licensing

Oracle Cloud at Customer enterprise licensing framework. Read it free.

Read the white paper

Frequently asked questions

What is Oracle Cloud at Customer?

Cloud at Customer is Oracle managed cloud infrastructure, including Exadata, installed in your own data center and billed as a cloud subscription. It targets workloads that regulation, residency, or latency keeps on premises.

Is Cloud at Customer cheaper than public OCI?

Usually not; you pay for dedicated capacity and on premises delivery. It wins on constraint satisfaction, and its economics depend heavily on BYOL mapping and honest capacity sizing.

Should you use BYOL or license included on Cloud at Customer?

BYOL wins on database heavy estates with clean entitlement positions, while license included contains risk where positions are contested or capacity is growth. Model both per workload, including option packs and support rewards, before choosing.

How long are Cloud at Customer commitments?

Typical terms run around four years with committed minimums. Estates that committed at full forecast left 25 to 35 percent of capacity idle by year two in our file, so commit below forecast with locked expansion pricing.

Does migrating to Cloud at Customer trigger an Oracle audit?

Not formally, but the sales cycle surfaces your deployment data, and unbaselined estates saw compliance findings appear during negotiations. Completing the entitlement baseline first removes that leverage.

How does a ULA interact with Cloud at Customer?

Mid ULA migrations change certification math because deployment counts at certification set the perpetual position. Sequence the migration against the ULA calendar deliberately rather than treating them as separate events.