This case study follows a mid sized bank as it moved a substantial Oracle Database estate to the cloud using a Bring Your Own License strategy, the model in which a buyer carries entitlements it already owns onto cloud infrastructure rather than buying new licences or consuming a vendor's bundled licence cost. The bank is anonymised, but its situation is common, because many regulated organisations want the operational benefits of cloud without abandoning the perpetual licences they have already paid for. The bank reached the cloud while protecting its entitlements and reducing its overall Oracle cost, and the way it did so is instructive.
The starting position.
The bank ran a large perpetual Oracle Database estate under an active support stream, and its infrastructure team wanted to migrate a significant share of those workloads to a public cloud over two years. The finance team's concern was that migration would mean buying licence capacity again on the cloud while still paying support on the perpetual estate, doubling the cost during the transition. The infrastructure team, meanwhile, had not fully mapped which entitlements could legally be carried to which cloud, so the project risked either overspending or falling out of compliance.
The bank's first task was to understand BYOL as a contractual question rather than a technical one, because whether a licence can move depends on the agreement and the target environment, not just on the workload. This framing is set out in the BYOL deal page, and the cloud context in the autonomous database pricing note.
Mapping the entitlements.
The bank began by mapping exactly what it owned and what each entitlement permitted. It consolidated its agreements and orders, confirmed which licences were perpetual and fully paid, and checked the metric on each, because how processors are counted on cloud infrastructure differs from on premise and determines how many licences a workload consumes. This work, which mirrors the discipline in the named user plus counting note, revealed that the bank owned more usable entitlement than it had assumed, enough to cover most of the migration without new purchases.
The mapping also exposed the cloud counting question directly, because Oracle's policy for counting cores on authorised cloud environments differs from its on premise processor rules, and the difference changes how far the bank's licences would stretch. Getting this right was essential, since an error would either waste entitlement or create a shortfall, the risk explored in the soft partitioning note.
Designing the BYOL path.
With the entitlements mapped, the bank designed a migration path that carried its perpetual licences onto the cloud rather than buying capacity there. It sequenced the migration so that as workloads moved, the corresponding on premise deployments were retired, freeing the entitlement to cover the cloud footprint and avoiding the double cost the finance team had feared. The design kept the bank within its existing licences for the bulk of the estate, with only a small incremental purchase for net new capacity.
The bank also negotiated the cloud commitment itself carefully, declining to over commit to consumption credits before the migration timeline was certain, a discipline covered in the data egress negotiation note. By matching the cloud commitment to a realistic migration pace, the bank avoided paying for capacity it could not yet use, the trap many buyers fall into when Oracle bundles a cloud commitment into a renewal.
Protecting the position.
A BYOL migration creates compliance exposure if it is not documented, because the bank had to be able to prove which entitlements covered which cloud deployments at any moment. The bank built a continuous record linking each migrated workload to the entitlement carried to cover it, so that if Oracle questioned its cloud usage it could demonstrate compliance immediately. This record, the kind described in the compliance posture note, turned the migration from a source of audit risk into a defensible position.
The bank also kept the negotiation in writing where it mattered, capturing Oracle's confirmation of how the entitlements could move and on what terms, the documentation discipline set out in the document trail note. This mattered because BYOL terms can be ambiguous, and a written confirmation protected the bank against a later reinterpretation.
The renewal effect.
The migration changed the bank's renewal position in its favour. As workloads moved to the cloud under carried entitlements and on premise deployments were retired, the bank could drop support on the licences it no longer needed, reducing its support stream. At the next renewal the bank held a smaller, cleaner estate, a credible cloud alternative it had already begun executing, and the entitlement data to prove its position, which together let it negotiate the renewal down rather than absorbing an uplift.
The credible alternative was the strongest lever, because the bank was visibly reducing its Oracle footprint and could continue to do so, which changed how Oracle approached the renewal. This dynamic, where a real migration reshapes the renewal, is the same one explored in the manufacturing renewal case study, and it is the leverage our cloud migration advisory service helps buyers build.
What the bank learned.
The bank drew several lessons. The first was that BYOL is a contractual question that must be answered before the technical migration begins, because the value of the strategy depends on carrying entitlements correctly rather than buying capacity twice. The second was that entitlement mapping is the foundation, since the bank only avoided new purchases because it could prove what it already owned and what each licence permitted on the cloud. The third was that documentation protects the saving, because an undocumented BYOL position invites the compliance challenge that erases the benefit.
The bank also learned that migration and renewal are connected, and that a well sequenced cloud move strengthens the renewal that follows. The product context it now tracks is in the Oracle Database product page, and the full framework behind the approach is in the Oracle Negotiation Playbook.
Applying the pattern.
A buyer considering a cloud migration can apply the same pattern. Treat BYOL as a contractual question first, map your entitlements and the cloud counting rules before moving any workload, sequence the migration so retired on premise deployments free entitlement for the cloud, document the carried position continuously, and use the reduced footprint as leverage at the next renewal. Done in this order, a migration that might have doubled cost during transition instead reduces cost and strengthens the buyer's hand.
The bank reached this outcome with independent advice on the buyer side, because the BYOL counting rules and cloud commitment terms are where buyers most often go wrong without help. An advisor who has guided many of these migrations brings that knowledge to a buyer making the move for the first time, which is what our cloud migration advisory service exists to provide.