Moving Your Existing Oracle Licenses to AWS
Oracle licensing is crucial when moving Oracle workloads to Amazon Web Services (AWS). Many companies have existing Oracle licenses and often question whether these licenses can simply be moved to AWS. The short answer is yes. Oracle allows license mobility to AWS through its “Bring Your Own License” (BYOL) policy. However, there are important considerations and practices you must follow to ensure compliance and avoid pitfalls.
In this article, we’ll explore the practical aspects of moving your Oracle licenses to AWS clearly and practically, helping you understand exactly what Oracle’s policies mean for your business.
Read Oracle on AWS Licensing FAQs 4 of 4.
Understanding Oracle’s License Mobility to AWS
Oracle does not have a formal “license mobility” program similar to Microsoft’s. Instead, Oracle’s policy is simple—existing Oracle licenses can be moved and used on authorized cloud platforms, including AWS, Azure, and Google Cloud Platform (GCP). Oracle explicitly recognizes AWS as an “Authorized Cloud Environment,” making it straightforward to migrate your licenses there.
Verify Your License Agreements
Your first step should always be to check your existing Oracle license agreements. Most Oracle licenses follow the Oracle Master Agreement (OMA) or Oracle License and Services Agreement (OLSA). These agreements typically do not explicitly forbid deploying Oracle licenses in third-party cloud environments like AWS.
Oracle has provided guidance (non-contractual but widely respected) explicitly permitting license use in AWS environments. However, you should always read your contracts carefully. Confirm there aren’t any clauses specifically preventing third-party hosting.
For example, if your organization owns 10 Oracle Database Enterprise Edition licenses under a standard OMA, you can generally use these licenses on AWS. Oracle requires no special application or notification, provided you follow standard policy guidelines.
Maintaining Oracle Support
Moving Oracle licenses to AWS doesn’t change your existing support relationship with Oracle. It’s essential to continue paying for and maintaining active Oracle support on these licenses, even if your workloads are hosted on AWS infrastructure.
Oracle support agreements apply consistently regardless of whether the software runs in your data center or a cloud like AWS. Thus, your standard support contract remains valid and fully operational. For instance, if you run into a software issue with your Oracle database while hosted on AWS, Oracle support will help troubleshoot it just as they would for your on-premises infrastructure.
Remember:
- Keep your support current.
- Maintain documentation of your support contracts.
- Reach out to Oracle support for issues without hesitation; the cloud does not limit your support eligibility.
No Extra Fees for Oracle License Mobility
One common concern is whether Oracle imposes additional charges for using your licenses in the cloud. Oracle explicitly does not charge transfer or mobility fees for deploying existing licenses onto AWS.
Here’s how this might practically work:
- Suppose you currently have 10 Oracle processor licenses in your on-premises data center.
- Your team will shift four of these licenses to cover an AWS EC2-based Oracle database.
- You simply allocate those four licenses for internal AWS usage.
- No financial penalty, special notification, or approval is required from Oracle.
This flexibility makes migrating workloads to AWS straightforward from a licensing perspective. However, to avoid compliance issues, always ensure you’re accurately tracking how many licenses remain allocated on-premises after migration.
Beware of Legacy Licensing Clauses
While current Oracle licensing is cloud-friendly, older agreements occasionally contain specific language restricting cloud deployments. Legacy agreements may have terms like “Application Service Provider (ASP)” or “outsourcing” clauses, explicitly requiring Oracle’s consent before using the software on hardware you do not own directly.
If your Oracle agreements are particularly old—signed 10 or 15 years ago—it’s prudent to have these clauses reviewed by legal experts familiar with Oracle licensing. Typically, Oracle no longer actively enforces these legacy restrictions in modern contexts, especially given Oracle’s public stance and clear policy permitting cloud deployments.
However, clarity is essential. In rare cases where you find legacy restrictions in your agreement, you should consult directly with Oracle licensing experts or legal counsel to secure explicit permission or a revised agreement explicitly allowing cloud deployments.
Internal Documentation and Audit Preparation
Oracle audits license compliance regularly. Therefore, it’s critical to document meticulously how you allocate licenses between your on-premises environments and AWS. Keeping clear, well-organized records helps immensely in the event of an Oracle license audit.
Recommended documentation practices include:
- Record exactly how many licenses (processors or Named User Plus) you own.
- Document exactly which licenses are allocated to each AWS EC2 or RDS instance.
- Maintain details of instance types, number of vCPUs, Oracle software installed, and license numbers or identifiers.
- Review and update these records regularly whenever your AWS deployment changes (e.g., scaling EC2 instance sizes up or down).
Here’s a practical example for clear documentation:
- “License #ABC123 for Oracle Database EE: 8 Processor Licenses”
- “Allocation: AWS EC2 Instance ID i-123abc456 (c5.4xlarge, 16 vCPUs) — 8 Licenses”
- “Remaining licenses on-premises: 0 Licenses”
- “Date allocated to AWS: June 15, 2024”
Such detailed internal records become invaluable during audits. Oracle auditors will request proof of licensing compliance. Your internal documentation clearly shows how each license you own covers specific deployments.
Practical Example of Moving Licenses to AWS
Consider an enterprise with 20 Oracle Database Enterprise Edition processor licenses, all currently deployed across two large data centers:
- They chose to migrate the workload of five processor licenses to AWS.
- These workloads are hosted on AWS EC2 instances totaling ten vCPUs (assuming hyper-threading enabled, meaning 2 vCPUs per license).
- They internally reassign five licenses to AWS clearly in their documentation.
- They ensure their remaining 15 licenses cover their on-premises deployments accurately, without oversubscription or shortfall.
The outcome is simple and compliant. No extra fees or additional Oracle approvals are needed. The company continues paying normal Oracle support fees, now clearly split between AWS-based and on-premises deployments.
License Mobility with Oracle Unlimited License Agreements (ULA)
While standard Oracle licenses can move easily, organizations with Oracle Unlimited License Agreements (ULAs) have specific additional considerations:
- ULAs typically allow unlimited Oracle software use for a defined period (often three years).
- Oracle allows deployment to AWS under ULA without issue during this unlimited usage period.
- However, standard ULAs explicitly forbid counting AWS-based Oracle deployments during ULA certification at the end of the term. This limitation means you must separately address AWS licensing at ULA expiration—often by purchasing perpetual licenses for AWS instances or renegotiating the ULA terms, specifically allowing cloud certification.
If your licenses are under a ULA, always carefully consider your strategy around cloud migration to avoid unexpected non-compliance issues at the end of your contract period.
Summary of Best Practices
Here’s a summary of recommended best practices when moving Oracle licenses to AWS:
- Review License Terms Carefully: Verify that your license agreement allows AWS deployments.
- Maintain Active Support: Continue regular Oracle support payments and terms.
- Clear Internal Documentation: Keep meticulous records of which licenses cover specific AWS instances.
- No Additional Fees: Oracle does not charge AWS license transfer fees.
- Audit Preparation: Regularly check your documentation accuracy for compliance audits.
- Legacy Clause Check: Older contracts need legal review to ensure that no ASP or outsourcing clauses restrict cloud deployment.
Conclusion
Moving your existing Oracle licenses to AWS is straightforward due to Oracle’s clearly stated BYOL policies. Oracle explicitly considers AWS an authorized cloud environment, allowing license mobility without additional charges or complicated approval processes.
Careful internal documentation and maintaining Oracle support are key to ensuring ongoing compliance and preparedness for Oracle audits. Following these practical guidelines, you can smoothly and confidently leverage your existing Oracle software investments as you adopt and scale AWS cloud solutions.
