The Situation: An ExaCC Estate Built for a Workload That Never Arrived
A global insurance group with primary operations in Europe and North America had purchased two Exadata Cloud@Customer racks four years earlier to consolidate a legacy Oracle Database EE estate and prepare for a planned actuarial analytics platform. The actuarial platform shifted onto Snowflake at programme reset two years in. The ExaCC racks — 396 OCPU of provisioned capacity across two regions — were left running at 31% average CPU utilisation, with $14.2M of three-year renewal cost on the next Oracle commitment. The CIO's question was unambiguous: defend the stranded capacity, exit the over-sized footprint, and relocate the remaining Oracle Database EE workloads onto a control plane the group already standardised on. The destination was Oracle Database@Azure under BYOL.
The estate, when our forensic team ran the inventory, was twenty-three production Oracle Database EE workloads. Fourteen were policy-administration systems on Database EE with the Partitioning Option, Advanced Compression and Diagnostics Pack. Six were claims and reinsurance workloads on Database EE plus Real Application Clusters. Three were the residual analytics workloads that should have migrated to Snowflake but had not. The aggregate sustained workload was 124 OCPU. ExaCC was provisioned for 396 OCPU. The migration target — Oracle Database@Azure on Exadata Database Service hardware running inside Microsoft Azure datacentres — would right-size to 132 OCPU with headroom, against the right-sized BYOL Processor licence pool the group already held under a Master Agreement signed in 2019.
Why Database@Azure Was the Right Destination, Not OCI
Oracle's preferred retention play for ExaCC customers is migration to Oracle Database Service on OCI. The OCI account team had pre-positioned the conversation for nine months. The group's procurement function pushed back, correctly, on three grounds. First, Microsoft Azure was the group's strategic public cloud and the application estate that touched Oracle Database — claims, policy administration, the actuarial residue — already ran in Azure. Second, Oracle Database@Azure provides the same Exadata Database Service hardware as ExaCC, with the same Exadata storage cell architecture, sitting inside Microsoft Azure datacentres on a Microsoft-billed consumption model with BYOL admitted for existing Oracle Database EE Processor licences. Third, the Database@Azure billing flows through the group's existing Microsoft Azure enterprise commitment, which carried a deeper discount than any equivalent OCI Universal Credits position Oracle was willing to offer. The right answer for the group was Database@Azure under BYOL on the existing Processor licence pool. The right answer for Oracle's account team was anything else. We built the negotiation on the assumption that Oracle would push back hard, and Oracle did.
Our Approach: 22 Weeks, Two ExaCC Racks, One Right-Sized Database@Azure Footprint
-
Forensic ExaCC Utilisation and Workload Inventory
Every Oracle Database workload on the two ExaCC racks was profiled by sustained CPU, memory, storage I/O, and licence-bearing options. The audit established that 396 OCPU of provisioned capacity was carrying 124 OCPU of sustained workload — a 32% utilisation profile that Oracle's own LMS team would have used as the evidence base for an upsell, but which we used as the evidence base for an exit. Diagnostics Pack, Tuning Pack and Advanced Compression usage was reconciled against the entitled licence pool to close any latent compliance gap before the migration began.
-
Database@Azure Sizing and BYOL Entitlement Reconciliation
The target Database@Azure footprint was sized at 132 OCPU across two Microsoft Azure regions — equivalent to 66 Processor licences after applying the Core Factor Table on the Exadata hardware. The group's existing Oracle Database EE Processor pool was 74 licences with 12 idle. The migration was achievable under BYOL with no incremental Oracle licence purchase. We also reconciled the option metric entitlement (Partitioning, Advanced Compression, Diagnostics Pack, Tuning Pack, RAC) to confirm coverage of the Database@Azure target with the same Processor count basis.
-
ExaCC Exit Negotiation and Audit Moratorium
Oracle's account team opened with a three-year ExaCC renewal at $14.2M, then dropped to $11.6M, then offered an OCI migration credit pool. We pushed back on the renewal model entirely on the grounds that the provisioned capacity was demonstrably unused. The settlement: a 6-month wind-down ExaCC subscription at $1.8M to cover the migration window, full BYOL credit on the relocated Database@Azure footprint, and a 24-month audit moratorium covering the historical ExaCC period and the post-migration Database@Azure footprint. The audit moratorium was non-negotiable from our side and was signed.
-
Phased Database Migration to Database@Azure
The twenty-three production workloads migrated in five waves across 14 weeks. Policy administration first, as the lowest-risk Database EE workload class. Claims and reinsurance second, with the RAC topology preserved on Database@Azure's Exadata storage. The residual analytics workloads were retired into Snowflake during the same window — a separate workstream that closed a long-running migration debt. Each wave used Oracle Zero Downtime Migration where supported and Data Guard switchover where not. No production incidents attributable to the migration.
-
ExaCC Decommission and Exit Documentation
The two ExaCC racks were decommissioned at week 18 and 20 respectively, after the final workload had been on Database@Azure for 30 days with no rollback events. The exit documentation — what was on ExaCC, what moved when, what is now on Database@Azure, where the BYOL Processor pool sits — was produced as a board-grade artefact and is the defence record if Oracle's LMS team re-opens the historical window inside the audit-moratorium term.
Stranded Capacity on an Over-Sized ExaCC Estate?
If Oracle's account team is pushing an ExaCC or OCI renewal on capacity you do not use, the relocation to Database@Azure or Database@AWS under BYOL almost always pays for itself inside the renewal window. Former Oracle insiders, buyer-side only.
Request an ExaCC Exit Briefing →The Results
By month five the group's Oracle Database EE estate had collapsed from 396 OCPU of provisioned ExaCC capacity to 132 OCPU of consumed Database@Azure capacity, billed through Microsoft Azure on the existing enterprise commitment, with the entire Oracle Database licence position covered by the pre-existing BYOL Processor pool. The two ExaCC racks were decommissioned and physically returned. Oracle's account team made one further attempt to re-open the conversation at fiscal Q4; the audit-moratorium clause and the exit documentation closed it. The retained run-rate Oracle ExaCC spend at the group: zero. The total three-year benefit, net of Database@Azure consumption and Microsoft Azure billing: $9.4M.
"We had two ExaCC racks running at 31% utilisation and Oracle wanted us to renew the lot. The decision to move to Database@Azure was strategic — Azure was our cloud — but the negotiation was the harder problem. Having buyer-side advisers who had built the original ExaCC sizing models and knew exactly how Oracle would defend the renewal made the difference. The audit moratorium was the piece we would not have got without them."— Chief Procurement Officer, Global Insurance Group
Key Takeaways for ExaCC Customers Considering Database@Azure
What a Defensible ExaCC to Database@Azure Migration Demands
- Profile actual ExaCC OCPU consumption before negotiating the renewal. Oracle's renewal quote assumes you will renew the provisioned capacity, not the consumed capacity. The provisioned number is almost always materially over-sized.
- Right-size the Database@Azure target on sustained workload, not on the ExaCC provisioning baseline. Database@Azure runs the same Exadata storage architecture; you do not need to replicate the over-provisioned ExaCC capacity to keep the workload profile.
- Reconcile the BYOL Processor entitlement and the option-metric entitlement (Partitioning, Advanced Compression, Diagnostics, Tuning, RAC) before signing the Database@Azure order. Oracle's LMS team will revisit option usage on the migrated estate; the reconciliation is the defence record.
- Negotiate the ExaCC exit as a wind-down subscription, not as a cancellation. Oracle's account team will defend the renewal harder than the exit; a wind-down that covers the migration window plus a credible audit moratorium is the achievable outcome.
- Database@Azure billing flows through the Microsoft Azure enterprise commitment, not through an Oracle Universal Credits pool. If your strategic cloud is Azure, that is a materially better commercial position than the equivalent OCI relocation Oracle's account team will push.
Oracle Database@Azure Decision Framework
When Database@Azure beats OCI Exadata Database Service, when ExaCC remains the right answer, and the BYOL reconciliation playbook Oracle's account team will not volunteer. Written by former Oracle insiders.
Download the Decision Framework →