How to Maintain Oracle License Compliance When Migrating

Share on linkedin
Share on twitter
Share on facebook
jeshoots-com-LtNvQHdKkmw-unsplash (1)

Considering the cost of Oracle software and Oracle’s propensity to audit their customers maintaining license compliance is of utmost importance to many organizations. When migrating from one platform to another, whether it be a simple hardware upgrade or a move to a cloud vendor such as AWS, there will likely be a time where the old platform and the new platform are running at the same time. This transition period is the time frame that this article is to address.

In the Oracle contract there is no “oh but you were migrating, never mind your are ok” clause, it simply states that license is required for “all processors where the Oracle programs are installed and/or running.” Regardless, of an upgrade and/or migration you are expected to maintain license compliance. Ignoring this and upgrading/migrating without maintaining license compliance can get very expensive if Oracle were to audit you. House of Brick has seen Oracle take a very strict view on adherence to the letter of the software licensing contract(s) even for clients caught in a transition period when performing a software audit.

In this article we will discuss several strategies for maintaining compliance during the transition period while performing an upgrade/migration. These include:

  • Shelf license – the use of unused licenses
  • The shuffle game – migrate licenses between the old and new environments
  • AWS RDS License Included – use AWS RDS License Included if possible
  • Term licenses – purchase term licenses from Oracle
  • New licenses – purchase new licenses

Shelf License

For a variety of reasons many organizations have shelf-licenses; simply unused/unassigned licenses. If this describes your situation, then the shelf-licenses can be applied to the new environment until the upgrade/migration has completed. Once the upgrade/migration has completed and the old environment has been uninstalled then the old environment licenses can be resigned to the new environment.

When using the shelf license strategy, the new environment may not need the same number of licenses or the same metric. For example, if moving to AWS use a smaller instance size until the upgrade/migration has completed. Additionally, is not likely that the new environment will have very many users on it at first. It may be possible to license the new environment on the NUP metric instead of the processor metric until the old environment license can be reassigned.

The Shuffle Game

The next strategy is the shuffle game, and there are several variations on a theme when employing this one. The short summary is you free up some licenses by decommissioning and/or consolidating something that is already running. There will be some risk when doing this, however this can usually be mitigated by completing the upgrade/migration as quickly as possible. Some possible examples are:

  • In an Oracle RAC environment simply remove one node from the cluster. That frees up the licenses that can then be reassigned to the new environment.
    • You do loose the HA that RAC provides for a time.
  • In a virtualized environment simply remove one or more physical hosts from the cluster. This frees up licenses to assign to the new environment.
    • Do watch for possible over subscription issues.
  • Use DR licenses by decommissioning the DR environment for a time. Depending on risk tolerance maybe use a portion of DR.
    • For example, if DR has four hosts licensed, can you live with two for a time?
    • Use a backup-only DR strategy for a short time. This allows the DR licenses to be used in the new environment while still maintaining DR, just with longer RTO/RPO times.
  • Use non-production licenses. Similar to the DR solution above, reduce the number of non-production hosts for a period of time.

When using non-production and/or DR licenses do double check your contract to ensure that they are full use licenses. It is somewhat common for non-production and/or DR licenses to be specifically tied to the environment.

NOTE: As noted above Oracle software must be licensed where “installed and/or running”. When playing the shuffle game simply turning off a server or RAC node may not actually meet this threshold.

AWS RDS License Included

This strategy is use case specific, but when migrating to AWS while using Oracle Standard Edition 2, it may prove effective. This strategy involves leveraging the ability of AWS to provide SE2 licenses on-demand for their Relational Database Service (RDS) offering. As discussed here (4. What About Oracle license?) AWS is allowed to include Oracle licenses for SE2 when using RDS. This can allow for on-demand licensing to help aid in the migration. Additionally, if this is a viable solution, simply moving to RDS LI may be a longer-term solution for your organization.

Term License

If the other strategies have not freed up enough licensing for the upgrade/migration the next option is to use term license. A term license is a software license that you purchase for a specified period of time, then at the end of the term you are to discontinue its use, basically a temporary license.

The benefit of a term license is that term licenses are cheaper than perpetual licenses and there are no on-going support costs. However, term licenses are still expensive enough that we generally only recommend their purchase when other methods are simply not available. Additionally, we would recommend purchasing as little as possible; do not license the entire new or old environment, but rather just enough to get the shuffle game started.

Historically Oracle allowed customers to purchase term licensing ranging from one to five year terms for all products. However, in Q3 2020 Oracle made a change and they no longer allow terms longer than one year and term licenses are no longer available for all products. However nearly all database products are still available for a one-year term license. As all new term licenses are restricted to a one-year term; if this strategy is needed it does provide a built-in deadline for completing the upgrade/migration.

New License

Sometimes it is just time to add new Oracle licenses and if the requirements of the new environment justify it, it may be time. In this strategy the new purchase is used to license the new environment, in whole or in part, while the upgrade/migration is on-going. As with the shelf license or shuffle game the new purchase may be just enough to get you started. Is it likely that you start off with a scaled down environment to start and then expand as workloads are moved off the old environment.


With the available strategies we find in practice that multiple are used in conjunction to help felicitate any particular project. It truly does come down to the questions of what are you trying to do? and what Oracle licenses do you already have? This is one of those situations where every customer is different and there is no one way of accomplishing the task. If your organization finds that is needs help coming up with a good way to maintaining license compliance or charting a path to a license-compliant and performant cloud migration do not hesitate to contact us, we are always happy to help.

Table of Contents

Related Posts

House of Brick focuses on cloud adoption & secure management for enterprise applications and databases