The Stranded Licence Problem
Oracle license optimization after a cloud migration starts with a simple recognition: the migration does not touch your licences. When an on-premises server is decommissioned, the perpetual Database and option licences that ran on it do not disappear — they become stranded or "shelf" licences. They remain under support, they keep billing, and they are no longer deployed against anything. For a large estate, the gap between what is owned and what is used is almost always wider than the IT team expects.
Left unmanaged, those stranded entitlements quietly fund Oracle for retired infrastructure. Managed well, they are an asset — either redeployed into the cloud as Bring Your Own Licence, or shed from the support bill. This is the post-migration extension of the discipline in our licence harvesting guide and the wider advanced Oracle licensing framework: match what you own to what you actually run, then remove the cost that no longer earns its place.
The Three Leaks Every Estate Has
Across benchmarked Oracle estates, the same three leaks recur — and a migration is the moment they become both visible and recoverable.
| Leak | What happens | Recovery |
|---|---|---|
| Phantom options | Database options switched on, never logged or removed | Disable and document before audit exposure crystallises |
| Support on shelf licences | Support keeps billing on licences nobody deploys | Terminate, consolidate, or repurpose as BYOL |
| Over-counted users | Named-user counts sit well above real need | Re-census and right-size to actual usage |
The phantom-options leak is the most dangerous, because an option switched on but unlicensed is an audit finding waiting to happen — exactly the kind of exposure that drives the triggers covered in our audit frequency analysis. A migration is the natural point to disable unused options and document the change, because the workload is being rebuilt anyway.
Reclaiming Value Through BYOL
The most direct way to recover stranded value is to redeploy it. Bring Your Own Licence lets you apply existing perpetual licences under active support to cloud capacity, capping your licensing to the vCPUs you actually deploy rather than the whole physical host. On Oracle Cloud Infrastructure, BYOL applies one Oracle processor licence per 2 OCPUs — so a workload sized to 8 OCPUs consumes just 4 processor licences. Against an on-premises model that often required licensing an entire multi-socket box, that ratio alone can free a substantial pool of entitlement.
Repurposing also extends to disaster recovery: stranded licences from a decommissioned server can back a cloud DR configuration, getting value from a sunk cost rather than buying fresh capacity. The interaction with public-cloud rules matters here — the Oracle on AWS BYOL rules and OCI pricing comparison determine which target environment recovers the most value, and the answer is rarely the one the migration team assumed at the outset.
BYOL only works on licences under active support. The moment you terminate support to save money, you forfeit the right to redeploy those licences in the cloud — which is why the support decision and the BYOL decision must be made together, not in sequence.
Reducing Support Without Losing Rights
Once licences are genuinely surplus — not needed for BYOL, DR, or future growth — the support stream attached to them is the saving. There are three routes, each with consequences. You can terminate support on the unused licences, consolidate certificates to simplify the estate, or move qualifying products to third-party support. The trap is Oracle's matched-set and repricing rules: terminating support on part of a licence set can trigger repricing of the licences you keep, wiping out the saving. This is the same mechanism that makes support reinstatement fees so punitive, and it is why partial termination must be modelled before it is executed.
One offset is worth building into the business case. Oracle Support Rewards credits $0.25 against your annual Oracle support bill for every $1 of OCI spend (more for ULA customers). For an enterprise with meaningful OCI consumption, that can absorb a real share of the remaining on-premises support — but only on OCI spend, so it should be modelled, not assumed.
The Optimisation Sequence
Order matters. First, inventory the true deployment against the entitlement, exposing the stranded pool. Second, redeploy what BYOL and DR can absorb, applying the 2-OCPU ratio to size the requirement. Third, model the support decision on whatever remains, testing for matched-set repricing before acting. Fourth, document everything — because a migration is itself an audit trigger, and clean records are the difference between an optimised estate and an exposed one. The metric discipline from our EPM Cloud and Oracle vendor intelligence work applies throughout.
For the full optimisation model — the inventory templates, the BYOL sizing calculator and the support-decision framework — download the Oracle Negotiation Playbook, or request a confidential briefing before you finalise your post-migration licensing position.