Article Summary:
An evidence-led Oracle licensing checklist for infrastructure change, including editions, options, virtualisation and operational records.
Oracle Database licensing can be affected by edition, options, deployment architecture, contracts and how the environment is operated. A migration, cluster expansion or cloud redesign should include licensing discovery before the target is committed. This guide is a preparation checklist, not legal advice or a substitute for reading your agreements.
Start with contracts and entitlements
Collect ordering documents, licence schedules, support renewals, amendments and any cloud or outsourcing terms. Record metric, quantity, edition, options, support status and legal entity. Do not infer entitlement from an installed binary or a procurement-system description.
Reconcile deployment and feature evidence
Oracle's 19c Licensing Information and 26ai Licensing Information describe edition availability and separately licensed features for those releases. Use the document that matches the deployed version. Collect inventory and feature-usage evidence, then investigate exceptions with the database and application owners.
- Database version and edition
- Hosts, processors and cloud services
- Clusters and virtualisation
- Multitenant and pluggable databases
- Options, packs and management tools
Model the target architecture before build
Draw the current and target compute boundaries, mobility, high availability and disaster recovery. Include non-production and passive systems. Record what technical controls restrict movement or access and how those controls are operated. Ask a licensing specialist to review the design before procurement.
Separate product lifecycle from licence rights
The Oracle Lifetime Support Policy helps plan product support, but support dates do not answer every licence question. Likewise, ending support does not automatically end a licence right. Keep lifecycle, technical risk, support contract and licence entitlement as connected but distinct decisions.
Build a defensible operating record
Assign ownership for inventory and keep evidence when capacity, clusters, cloud services or disaster-recovery arrangements change. Document assumptions, unresolved questions and approvals. A point-in-time review loses value quickly if the change process does not preserve the result.
- Named licensing owner
- Approved architecture baseline
- Controlled provisioning and mobility
- Regular inventory reconciliation
- Evidence retention and exception review
Talk to a database specialist
A change to support, licensing, cloud architecture or a production database should be based on evidence from your own estate. Pro DBA can assess the current position, identify the material risks and help you plan the next step. Contact the Pro DBA team to discuss your environment.













