Oracle’s July 2026 Release Update for Oracle AI Database 26ai brought renewed attention to an upgrade process that many database teams had been putting off. For teams moving from older releases, the tooling requirements have changed. AutoUpgrade and Replay Upgrade are now the supported paths for upgrading to 26ai. The old Database Upgrade Assistant and traditional manual upgrade paths are no longer supported.

There is an important distinction here: teams already running Oracle Database 23ai can transition to 26ai through a Release Update, while teams moving from 19c face a more substantial upgrade. If your team has been putting off learning AutoUpgrade because the old manual process still worked, that option is no longer available for a 26ai upgrade.

We tested this migration path on a set of lab databases, mostly because a client asked how much runway they had before they needed to make the jump. What we found wasn’t dramatic, but it also wasn’t the plug-and-play story Oracle’s own materials suggest. Here’s the fuller picture, including a few things that caught us off guard.

The Health Check That Finds Problems Nobody Wants to Find

The first surprise was how much prep work AutoUpgrade expects before it will even start. It runs pre-upgrade health checks automatically, which sounds convenient until you realize those checks can flag things you didn’t know were wrong. We had a schema with a few deprecated data types sitting untouched for years, the kind of thing nobody notices until an upgrade assessment brings it to light. That’s actually a good thing. Catching it in a test run beats catching it during a production cutover at two in the morning.

Our review also caught an invalid database link pointing at a server decommissioned back in 2023. It never caused a problem because nothing actively called it, but it was still something worth cleaning up before an upgrade. That distinction matters more than people expect going into this.

The CDB Conversion Is Its Own Project, Not a Step

The second issue was more structural. If you’re still running a non-container database, you’ll need to move to the CDB/PDB model as part of your transition to 26ai. AutoUpgrade can handle the conversion during the upgrade in supported configurations, but that doesn’t eliminate the preparation involved. For teams that delayed this during earlier upgrade cycles, that’s not a small task anymore, and it’s not optional.

We had one setup where the conversion itself took longer than the actual version upgrade, mostly because the application connected using hardcoded service names that didn’t map cleanly to a pluggable database structure. Nobody had documented that connection logic in five years. We ended up tracing it through log files instead of any runbook.

What made this harder than it needed to be wasn’t the conversion tooling, which has genuinely improved. It was the discovery process. Every application talking to that database carries assumptions about how connections work, and those assumptions rarely show up in documentation. Before starting a CDB conversion, it’s worth building a short inventory:

• Every connection string and TNS entry currently in use, pulled from actual config files, not from what the wiki says should be there
• Any hardcoded service names buried in application code or scheduled jobs
• Database links pointing outward, and who still owns the systems on the other end
• Any third-party tools (monitoring agents, backup software, reporting jobs) that connect directly rather than through the application layer

That inventory work is where the real time goes, not the conversion command itself.

Why Waiting Isn’t Always a Safe Option

Some teams we’ve talked to are planning to sit on their current version a while longer and deal with 26ai later. That can be a reasonable decision, depending on their support requirements and existing environment, but it still needs to account for changes in Oracle’s provisioning policies.

As of June 16, 2026, Oracle changed how OCI provisioning and update workflows behave. New database builds and update workflows on affected OCI database services now use the latest available Database Software Image for the selected supported release. Earlier Release Update images are no longer offered as selectable options by default.

That doesn’t mean every team running 19c is forced onto 26ai. Both releases remain available under the policy. It does mean teams need to account for the latest available Release Update when provisioning or updating databases through the affected OCI workflows, even if they’re not ready to move to 26ai.

This gets missed in planning conversations more than it should. People treat a database upgrade as something they can schedule whenever it suits them, without considering the provisioning and patching policies around it. Those policies can affect migration plans, standby environments and new database deployments long before the actual upgrade window.

What Actually Went Smoothly

Not everything about this was painful. Once the groundwork was done, the upgrade and patching mechanics worked better than expected. In supported configurations, AutoUpgrade Patching can handle downloading and staging required software images when configured appropriately, and the utility reports its progress more clearly than earlier versions did.

Older AutoUpgrade releases left you guessing whether a long pause meant progress or a hang. This one logs enough detail that you can tell the difference, which matters when you’re running this against production at 3 a.m. with a rollback window measured in minutes.

The analyze mode also gives teams a structured way to identify upgrade-readiness problems before deployment. We reviewed invalid objects and stale statistics alongside the assessment results rather than assuming a completed analysis meant every possible issue had been resolved. Oracle clearly put effort into making failures surface earlier and louder instead of later and quieter. That’s the right direction, even if your first analyze run comes back with a longer list than you’d like.

A Rollback Plan That Actually Holds Up

Every upgrade guide tells you to have a rollback plan. Fewer of them tell you what that plan needs to include to actually work under pressure. Based on what broke in our testing and what we’ve seen go wrong in real cutovers before, a rollback plan needs at minimum:

• A verified recovery mechanism appropriate to the operation, including a guaranteed restore point where supported and applicable, rather than relying only on a backup from the night before
• A tested restore path, meaning someone has actually run the restore once in a non-production copy, not just confirmed a backup job completed successfully
• A written, time-boxed decision point: if the upgrade hasn’t reached a specific stage by a specific time, abort and restore rather than pushing forward and hoping
• A named person with authority to make that abort call without needing a meeting first

The recovery mechanism matters. For AutoUpgrade Patching, Oracle supports rollback through a guaranteed restore point in eligible Enterprise Edition configurations or through Datapatch rollback. A major-version upgrade or non-CDB conversion may require a different recovery approach, so the plan must match the actual operation.

That last point about decision-making authority sounds obvious until you’re two hours into a maintenance window and nobody wants to be the one who says stop.

Watching the Upgrade While It Runs

During our test cutovers, a handful of signals told us more about how the upgrade was actually going than the AutoUpgrade log summary did on its own. Redo generation rate is worth watching, since an unexpected spike can indicate that a step is doing far more work than expected.

Session and connection counts matter too, particularly if your application has connection pooling that reconnects aggressively when it loses a session, which can make a brief pause look like a bigger outage than it is.

Keep an eye on the alert log for anything unexpected showing up outside the steps AutoUpgrade itself reports, and watch tablespace growth if your conversion involves moving data into a new pluggable database structure, since that step can consume more space than people budget for.

The AI Agent Memory Piece Nobody’s Talking About Enough

Oracle AI Agent Memory 26.6 also deserves more attention than it’s getting in most database discussions. The release adds support for updating existing threads, messages and memories, along with broader metadata capabilities and time-to-live controls for stored messages and memories. It also provides mechanisms for deleting related records together, including thread-scoped memories and messages.

For teams building AI applications backed by Oracle Database, this changes a real design decision. Some retention controls that used to require more application-level management can now be configured through the agent-memory layer instead.

That’s a meaningful shift for regulated industries like telecom and banking, where requirements around what customer data an AI system retains, and for how long, tend to get complicated fast. These capabilities don’t automatically provide a complete audit trail or guarantee compliance, but they give teams additional tools for managing stored agent context and retention policies.

It also means database teams and AI teams need to actually talk to each other now, which historically hasn’t always happened at the same company. If your AI initiatives and your database operations team are still on separate tracks, this release is a reasonable excuse to get them in a room together.

Don’t Trust Your Old Automation Scripts Blindly

If you’re planning an upgrade to 26ai, run AutoUpgrade’s analyze mode first and actually read the output instead of skimming it. We’ve seen teams treat the analyze step as a formality and then get blindsided by a CDB conversion requirement they didn’t know existed.

Don’t assume your automation scripts from the 19c upgrade will just work here either. We’ve worked on an Ansible-based switchover automation project for a telecom client, where reliable automation and validation were essential to maintaining database availability. Older playbooks can carry assumptions about software homes, connection configurations and operational steps that no longer hold in a new environment.

Test those scripts against a throwaway instance first, and budget more time than you think you need for the CDB conversion if you haven’t done it yet. Oracle’s documentation describes the supported conversion procedures, but in practice, especially with older applications carrying years of undocumented connection logic, the work can behave more like its own migration project.

Where This Leaves Most Teams

None of this makes the upgrade a bad idea. Oracle AI Database 26ai brings real improvements to how AI workloads run against production data, and keeping up with supported security updates remains important. But treating a major-version upgrade like a routine patch cycle is how teams end up with surprise downtime.

Treat it like a real migration, with a tested environment, a rollback plan that’s actually been rehearsed, and someone who reads the AutoUpgrade logs instead of glancing at them, and the process becomes far more manageable.

The operational pressure is real, even if every database team isn’t facing the same deadline. Support requirements, patch availability and OCI provisioning policies all need to be considered when planning a transition. For teams still running non-CDB environments, the architectural work deserves particular attention.

Better to find your CDB conversion problems in a lab than during a production update window.