The moment you upgrade from 19c to 23ai, several newly-default behaviors can quietly switch on licensable options and record usage Oracle reads in an audit. This is the pre-migration checklist that stops you inheriting exposure you never agreed to buy.
The moment you upgrade from 19c to 23ai, several newly-default behaviors can quietly switch on licensable options and record usage Oracle reads in an audit. This is the pre-migration checklist that stops you inheriting exposure you never agreed to buy.
After 25 years negotiating Oracle contracts, I treat every version upgrade as a compliance event first and a technical project second. The 19c to 23ai migration is worse than most because it combines three things at once: a mandatory architecture change (CDB/PDB), a batch of features that ship enabled by default, and Oracle's own usage-recording machinery running in the background. None of that changes your entitlements. All of it changes what Oracle can point to when it audits you.
First, the naming. The product you knew as 23ai has been rebranded to 26ai (announced at Oracle AI World in October 2025, on-premises Enterprise Edition GA for Linux x86-64 in January 2026). Do not let the new label confuse your license position. The database banner reads 23.26.1 and it is a Release Update on the same 23.x code line, with (in Oracle's own words) no changes with respect to licensing. Whether your DBAs call it 23ai or 26ai, the license rules in this article apply identically. Our broader entitlement framework is in the Oracle Database 23ai licensing guide.
Second, list price. Nothing moved. Enterprise Edition remains $47,500 per Processor and $950 per Named User Plus (25 NUP minimum per processor), carried forward unchanged from 23c. EE runs roughly 2.7x the cost of SE2 on both metrics. So every option or pack that auto-enables during the upgrade lands against the most expensive line items Oracle sells. That is precisely why the pre-migration review pays for itself.
An upgrade does not add entitlements. It adds evidence. Your job before cutover is to make sure the evidence matches what you actually bought.
Here is the mechanism most buyers miss. Oracle EE installs most options in a ready-to-use state. A hidden internal job updates a feature-usage view roughly once per week, and that view is the same one Oracle references in a formal audit. You do not have to install anything separately, and you do not have to intend to license anything. If a DBA touches a feature during migration, the view records it, and Oracle later reads that record as consumption.
The two most common silent findings are the Diagnostics Pack and the Tuning Pack. They price per Processor, they cover features DBAs use every single day (AWR, ADDM, SQL advisors), and they switch on without a separate install. In our audit-defense casework, in 4 out of 5 estates the packs had been used by accident through default DBA workflows, and the control parameter that gates access sat at its permissive default in roughly 80 to 90 percent of databases we swept. When we settled against narrow, evidenced scope rather than Oracle's opening position, we cut the proposed pack bill by a median of 18 to 28 percent. The related self-enabling pack risk is documented in our note on the Oracle Cloud Management Pack.
The scale of the trap is geometric, not linear. One AWR report on a sixteen-Processor cluster can imply sixteen Processor licenses for each pack. At EE-class option pricing, a single careless report during a migration weekend can generate a six-figure claim. And drift compounds silently between manual script runs: a DBA enables Advanced Compression for a one-time migration task, the quarterly audit script does not catch it until next quarter, and by then Oracle considers it in use.
This is the sequence we run for clients before any 19c to 23ai cutover. Do it while you still control the environment and before Oracle's usage view has anything new to record.
That last point matters more than most teams appreciate. Standard queries tell you whether a feature has been used but not whether it requires a license. The feature-usage table includes entries for non-licensable features and spurious uses that can legitimately be removed from audit findings. Running the raw script and handing the output to Oracle is a rookie error. Interpret first.
These are the specific default behaviors that changed or that become easy to trip in a 23ai environment. Each one maps to a licensable option or a paid pack.
| Default behavior in 23ai/26ai | What it can auto-enable | List price exposure | Pre-migration action |
|---|---|---|---|
| Diagnostics and Tuning Pack access left at permissive default | Diagnostics Pack, Tuning Pack (per Processor) | $47,500 EE per Processor plus per-pack Processor fees, multiplied by every core | Set control_management_pack_access to NONE; restrict EM |
| Advanced Compression set as a tablespace or table default (ROW STORE COMPRESS ADVANCED) | Advanced Compression option | Per-Processor option fee on every server where new compressed objects are created | Audit tablespace defaults; disable default compression before conversion |
| Fourth PDB created during CDB/PDB conversion | Multitenant option | Per-Processor Multitenant fee across the CDB host | Cap at three PDBs per CDB unless Multitenant is licensed |
| TDE default algorithm now AES256, column mode GCM, tablespace mode XTS (changed in 26ai) | Advanced Security (TDE beyond TDE-only rights) | Per-Processor Advanced Security fee | Baseline TDE config; confirm whether TDE-only rights cover your usage |
| Standby or replication features enabled during migration | Active Data Guard and related options | $11,500 per Processor for Active Data Guard, plus standby server licensing | Verify standby servers are fully licensed before enabling |
The standby line deserves emphasis because migrations routinely spin up temporary standby or replication topologies. Standby servers need full licensing, and Active Data Guard is a paid EE option. We cover the mechanics and the buyer moves in our note on Oracle Active Data Guard licensing. Treat any migration-window replication as a licensed activity, not a free convenience.
The fourth PDB, the default-compressed tablespace, and the stray AWR report are not exotic. They are Tuesday. That is exactly why they end up in audit findings.
The review cuts both ways. Some 23ai features that sound premium are genuinely included in EE and SE2 at no extra option cost, and you should not let a nervous project team buy options they do not need. AI Vector Search is included as standard, along with Select AI and Wide Tables (up to 4,096 columns per table). We break down where the AI billing line actually sits in the pillar on 23ai Vector Search and AI feature licensing, and specifically whether vector search is bundled in our piece on whether 23ai AI Vector Search is included in Enterprise Edition or an extra.
Where the line gets murkier is in-database machine learning, which touches the Advanced Analytics conversation. Before you scope any ML workload into the migration, read our analysis of the 23ai in-database machine learning license question. Two more features that generate confusion in migration planning are True Cache and JSON Relational Duality; we address whether True Cache is a free feature or effectively a second licensed database in 23ai True Cache licensing, and whether the new duality views change your footprint in JSON Relational Duality and license scope.
One caveat for teams evaluating the free edition as a staging or dev target: AI Database Free does not include Advanced Compression, Storage Snapshot Optimization, Optimization for Flashback Time Travel History Tables, or Automatic Data Optimization, and several options are now marked as available only in OCI. Do not use the free edition as a proxy for what your paid production entitlements cover. The feature line is different.
Timing is leverage. Run the license review at least twelve months before your support renewal, not the week before cutover. That gives you time to remediate defaults, retire genuine shelfware, and rebalance editions before Oracle has any migration usage to point at. The same footprint discipline we recommend for renewals applies here; see optimizing your Oracle license footprint before renewal. If your organization is also moving workloads to public cloud during the upgrade, the BYOL and vCPU mechanics in Oracle Database licensing on AWS will change the per-Processor math again, so model both moves together rather than sequentially.
The buyer-side discipline is simple to state and hard to execute: never let Oracle's usage view become the first version of your compliance truth. Build your own baseline, disable the options you have not bought, cap the PDB count, and interpret the raw usage data before it leaves your environment. Do that, and the 23ai upgrade is what it should be, a technical project. Skip it, and the upgrade becomes the opening exhibit in an audit you did not schedule.
No. The upgrade does not add or remove any entitlement, and Oracle confirms the 23ai to 26ai transition carries no licensing change. What the upgrade changes is what Oracle can observe. Newly-default features and the mandatory CDB/PDB architecture make it easy to trigger usage of licensable options that Oracle records in the same view it reads during an audit.
Setting control_management_pack_access to NONE across every database that lacks Diagnostics Pack or Tuning Pack entitlement. These two packs are the most common silent audit findings, they switch on without a separate install, and one AWR report on a sixteen-Processor cluster can imply sixteen Processor licenses per pack. Set the parameter and restrict Enterprise Manager before you migrate.
Yes. Oracle 19c and later allow up to three PDBs per CDB without a Multitenant license; a fourth PDB triggers the paid Multitenant option. Because 23ai forces the CDB/PDB architecture, it is very easy to create a fourth container during conversion and trip the option unintentionally. Cap each CDB at three PDBs unless you hold Multitenant.
AI Vector Search, Select AI, and Wide Tables are included in Enterprise Edition and SE2 at no extra option cost. In-database machine learning, True Cache, and JSON Relational Duality require closer scrutiny because they can touch other licensed options or components. Confirm each feature against your entitlements before scoping it into the migration, and do not over-buy on the assumption that everything AI-branded is chargeable.
Yes. The default algorithm for both TDE column and tablespace encryption is now AES256, column mode moved to GCM, and tablespace encryption defaults to the new XTS mode. TDE is part of Advanced Security, a licensable option except where TDE-only rights apply. Baseline your TDE configuration before migrating and confirm whether your rights cover the new defaults.
At least twelve months before your next support renewal, and well before the migration weekend. Running it early lets you disable default-on options, cap PDB counts, retire shelfware, and interpret raw usage data before Oracle has any post-upgrade consumption to point at. Reviewing after cutover means negotiating from a position where Oracle already holds the evidence.
Oracle Cloud at Customer enterprise licensing framework. Buyer side framework across OCI Dedicated Region, Exadata Cloud at Customer, autonomous database.
Gated with a work email on the download page. No sales follow up you did not ask for.
Get the White Paper →
500+ enterprise clients. 11 vendor practices. Industry recognized. One conversation can change what you pay for the next three years.
One buyer side briefing a week. Renewal signals, audit moves, and the levers that work. No vendor spin.
