The License Impacts of Moving Oracle Workloads to Public Cloud
Increasingly we are seeing customers move their Oracle workloads to various cloud providers –typically ‘later’ than more routine workloads. This is understandable as customers have performance, interoperability and licensing considerations to address before moving these often sizable and complex systems to a cloud provider.
Simplistically, there are several phases involved when migrating Oracle licenses to the cloud.
1. Pre-migration — Assessment of your on-premises legacy/current Oracle workloads and planning of target environment.
2. Parallel running — Migration stage of on-premises legacy/current Oracle workloads to build-ahead target estate.
3. Post Migration — Decommissioning your legacy estate and managing your target estate.
All these phases have an impact on Oracle licensing.
Over the course of my career, I’ve been involved in numerous cloud migration projects covering a wide range of cloud vendors and varying degrees of complexity: I’ve also got ‘hands on’ experience of large migrations and associated considerations. This blog post will cover the most important elements to consider in each phase and any remediation activity to undertake.
Before Migration
This is a critical period of your migration and there are several considerations:
· Understand exactly what sort of Oracle license and support agreements you have in place, the structure of these contracts and your compliance position. Pre-migration is an ideal time to identify any compliance issues and be aware of available licenses: optimisation can be an added benefit of migration.
· Is Oracle aware of your migration? If you are moving to a competitive cloud offering, they will be very interested in your project and may also wish to incentivise their cloud offering.
· Carry out housekeeping and decommission old environments. Scrutinize your estate and optimise thoroughly; removing old unused servers and databases makes sense rather than migrating ‘just because it is there’.
· Examine the utilisation of your servers. In our experience, legacy servers are typically >80% under-utilised which is obviously very inefficient. Again you have an opportunity to understand the utilisation requirements for the target environment and ensure that this infrastructure is appropriately rightsized.
· It’s also worthwhile remembering that in the target environment, you will be deploying newer and faster hardware, so 8 core servers may only need to be 2 or 4 core instances in the target environment: another opportunity to save money. It is critical to change from the on-premises mindset of over-sizing a server and ensuring your size based on your need, growing the server in small increments where necessary. You should be running your instances ‘hot’ — 80%+ CPU utilisation.
· You can also take this time to re-evaluate the database edition that you will use in the target environment. In my experience, most customers default to Oracle Enterprise Edition Database. Consider the benefit of moving to Standard Edition 2 and whether your smaller databases can use this less expensive and easier to support database edition.
· Some cloud vendors provide ‘license included’ environments which makes the licensing side of things less transparent to you. However, you can treat this as a resource that can be scaled up and down to reduce costs accordingly, for example with dev servers.
The pre-migration is critical and it’s very important to invest as much time, analysis and resource at this stage, as possible. Plan properly and you’ll reap big rewards. Understand the potential licensing landmines and risks to avoid unbudgeted costs down the line.
During Migration
· The migration stage can be problematic. You are likely to have both your on-premises legacy/current environment and the build-ahead target cloud environment running in parallel. This means that you need enough licenses to cover any installation of Oracle in both environments. This is very important.
Customers have no inherent right to create build-ahead infrastructure and have zero cost for licenses.
· The point at which you need to put a license in place is as soon as you install the Oracle binaries on the target servers — in fact, best practice dictates that the license needs to be in place just before you install the binaries.
· Consequently, you could have (at worst) a doubling of license cost for a period of time, if you can’t reduce your target server sizes. This cost will need to be considered if you have no spare licenses and need to purchase enough to cover the migration stage. The planning stage is very important in understanding your license position, what needs to be purchased, how to minimise this cost and look at different license options such as buying term licenses (restricted in terms of the products they cover) and/or named user plus licenses.
· How long will this migration phase last? If you know that your project will last a year, then purchasing 1-year term licenses may suffice. If you plan to phase multiple systems and in effect free up licenses from your current infrastructure to cover your build-ahead, you need to keep a close eye on your entire estate, both legacy and target to ensure that the license usage v entitlement for this duration is not breached. Timing is everything particularly if you make use of minimal licenses.
· Creation of a ‘license pool’ of Named User Plus licenses to cover build-ahead may allow you to perform build ahead with sufficient coverage.
It’s very possible that Oracle may examine your estate during this parallel running period to ensure that you do not breach your license entitlement — you should be prepared for an approach by Oracle and manage your license estates carefully.
Post Migration
You have done all the migration activity and switched over successfully and all cloud systems are running.
· So, when do you decommission your on-premises deployments? As soon as you have removed your binaries from your on-premises environment, you can remove the associated license. In my experience, people take a long time to decommission servers; naturally, they are wary about switching off servers that have been in use for years. Make sure you manage the process of ‘switching off’ licenses that are no longer required, carefully.
· What does your new environment look like? Are you using more or fewer servers? And what is the resultant license requirement? (You should know this from your pre-migration analysis!) Do you need to buy more licenses, or can you optimise and remove old Oracle support contracts? Note — this is a non-trivial exercise. I won’t cover this in detail — suffice to say that there are certain rules and policies that must be adhered to, to make sure that this is done properly.
· There are also additional services that you can take advantage of when you move to the cloud. Again I won’t cover this in detail, but there are features and services (such as dynamic sizing, automatic shutdown/start-up) which you may wish to adopt in lieu of using oracle products which may decrease your overall license requirements and may be able to reduce your overall consumption of costly options such as Oracle database.
Summary
There are many considerations for moving to the cloud; Oracle licensing will require careful consideration and you should not think of ‘lift and shift’ of your Oracle workloads; there is plenty of scope to have an estate that is optimised, effective and based on minimal required licenses — bringing you and your business maximum value whilst being ‘de-risked’.
For further information, you can watch our webinar or contact us with any questions.
About The Author
Paul Bullen is Principal License Consultant here at Version 1.
