Saving money on Oracle Licensing in any cloud…and why regular reviews are important

15 November 2023
Job Vacancy Image

Inoapps Oracle Licensing Series: Part One

By Hazel Hopes
Licensing Consultant at Inoapps

At Inoapps, we see a lot of customers considering a move to cloud and the big question is always ‘which one?’ Rapidly followed by ‘how?’ and ‘how much will it cost me?’

An area often considered ‘at the last minute’ during a migration plan is how the environment will be licensed. This means, in its simplest form, that every Oracle product you deploy and/or use must have an associated license (or subscription) purchased from the vendor.

Cloud decisions aren’t easy, and can be governed by the products you’ve already deployed, budgets, legacy systems and the expertise to make the move.

The most widely used cloud options are Oracle, Azure or Amazon Web Services (AWS). Oracle customers will likely end up deployed on one of these, but it’s easy to miss the bigger picture when you’re lost in the weeds of technical details, migration plans, obstacles and fire-fighting.

By bigger picture, I mean considering areas like future financial costs, commitment to training your employees in cloud best practice techniques, and business goals for expanding or retracting usage.

A colleague and I ran a webinar to talk about how potential cloud adoptees can save money when moving to cloud and the areas to look at to ease the cloud migration process. In this blog, I’m going to revisit some areas we discussed.

What type of license do I need?

There are two main types of license to consider:

  1. Subscription. This means purchasing your licenses through a subscription with your chosen cloud provider. Subscriptions are usually for 12 months but can be longer, depending upon the agreement with your provider, and will “true-up” if you over-consume the cloud service. So you need some confidence in what you think you’ll consume.
  2. Bring Your Own License (BYOL). If you have existing licensing for your Oracle products from your on-premises/data center environments, you may be able to bring some of these into your cloud deployment. There are specific ratios and rules to consider though, so care is required here.

BYOL or Subscription: evaluating your options

Here are some questions to help evaluate your options:

  1. Subscription
    - Will this mean monthly rising costs due to a lack of control in your cloud environments, which may see increased OCPU consumption?
    - How can you track deployments and prevent spiraling expenditure?

  2. BYOL
    - In BYOL scenarios, your on-premises license footprint must be sufficient to cover your cloud deployments and there are specific ratios to consider. Does what you’re using in cloud match what you’ve bought for your on-premises environments? Are you able to accurately calculate the ratios between on-premises licenses and cloud?
    - Do you have legacy systems that you must keep active?

You can address some of these questions with a review that evaluates your estate, either before you commit to a migration or as a sanity check of your cloud environment afterwards. It has many benefits and will reveal:

  • Pre-migration, which environments you can actually move. Some legacy products won’t translate to a cloud environment.
  • How many of your on-premises licenses can be used for BYOL.
  • Where you may be non-compliant.
  • How you could mitigate problem areas.
  • ROI in your cloud choices. Many customers have high power environments by default and can reduce costs on compute power and editions.
  • Which non-production environments can be ‘switched off’ over weekends or evenings when not needed.

A note on applications / Software as a Service (SaaS)

SaaS environments are very different to on-premises environments in the way they’re measured because most subscriptions are by user and controlled by the allocation of roles and privileges.

Some roles and privileges are created by default when services are started and if they aren’t removed, part numbers (or SKUs) for services you didn’t sign up for could appear in your usage reports. Oracle calls these ‘predefined’ roles and offers a list of them to check against your deployments.

Oracle will not do this for you. It’s your responsibility to check and ensure you’re only using what you’ve licensed!

SKU’s also ‘share’ roles and privileges, which can lead to confusion. There are reports available to Oracle in SaaS environments as a way to track usage, so early housekeeping and regular reviews are crucial to avoid the need to defend under audit and potential associated future costs.


The key to a successful migration and keeping costs down is to monitor and control your cloud environments once they’re active. It’s very different to on-premises, so think about who in your organization takes on responsibility for managing licenses, controlling and administering the cloud environment and providing reporting and accountability to the management structure. And if that requires overheads in training or reskilling, or if you’d prefer to outsource to a trusted partner.

Inoapps has extensive experience in managing Oracle licensing and is a certified Oracle License Management Services (LMS) partner. To discuss how our experts can help you license, manage and optimize Oracle software and cloud services in any Oracle approved cloud, contact us today. For more information on our services visit our Oracle License Optimization page.

In Part Two of this licensing series, we look at Right-sizing before a cloud migration

Share this