• 31 July 2026

Understanding the Challenges of Migrating from Oracle 19c to 23c

Most teams discover the hard blockers in this migration too late, after they've already started. Oracle's non-CDB architecture disappears entirely in this release, and that single fact can derail a project timeline if it's not planned for upfront. Here's what actually changed, what to check first, and the tool Oracle recommends for the move.

Key Takeaways

• Non-CDB is gone. 19c was the last release where a non-container database was even an option. Moving forward requires converting to a pluggable database (PDB) first if you haven't already.
• It was renamed 23ai to reflect built-in AI capabilities (AI Vector Search among 300+ new features). Both names describe the same target.
• AutoUpgrade is Oracle's primary migration tool, not a generic utility. It runs in -mode analyze first, then -mode upgrade.
• Character set matters. Source databases should be on AL32UTF8 before starting, especially for multitenant setups.
• Full Transportable Export/Import is a documented, named alternative path for moving an entire database via transportable tablespaces.
• Native BOOLEAN type is a genuinely new, verified SQL feature here, previously emulated with NUMBER(1) or CHAR(1).

What Actually Changed

The successor to 19c introduces over 300 new features focused on JSON, graph, microservices, developer productivity, and built-in AI, the basis for its 23ai rebrand. Long-term support runs into 2028, with extended support projected into 2031.

The most consequential architectural change: non-CDB database architecture is no longer supported starting with this release. It was deprecated years earlier but remained usable straight through 19c. If your databases haven't converted to pluggable databases yet, that conversion is a mandatory prerequisite, not an optional step.

Common Challenges in This Migration

1. Non-CDB to Pluggable Database Conversion

Any database still running non-CDB must convert to a pluggable database (PDB) inside a container database (CDB) before the upgrade. Oracle's AutoUpgrade tool handles this conversion automatically, but it needs to be planned for, not discovered mid-project.

2. Compatibility and Schema Adjustments

Changes in SQL behavior, deprecated features, and updated system parameters can affect existing applications. A pre-upgrade assessment and schema validation early identify required adjustments before they become production issues.

3. Character Set Prerequisites

Source databases should be on the AL32UTF8 character set before starting; this matters even more for multitenant architectures, where a mismatch between source and container can cause conversion failures.

4. Downtime and Business Continuity

Extended outages disrupt operations, especially for large databases. Zero-downtime methods like Oracle GoldenGate real-time replication or Edition-Based Redefinition (EBR) for online application-level changes reduce interruption during cutover.

5. Performance Optimization

Query plans, indexing, or configuration mismatches can cause regressions afterward. Comparing execution plans before and after, using SQL Plan Management and the Query Store, catches issues before they reach end users.

6. Automation and Upgrade Complexity

Manual upgrades introduce errors and extend timelines. Oracle's recommended path is AutoUpgrade, which automates analysis, fixups, the upgrade itself, non-CDB conversion where needed, and post-upgrade validation:

java -jar autoupgrade.jar -config config.properties -mode analyze
java -jar autoupgrade.jar -config config.properties -mode upgrade

For container databases with multiple PDBs, upgrade the entire container at once, or use an unplug-plug method: unplug PDBs from the source CDB and plug them into a new target CDB individually. Teams whose ETL pipelines sit on top of the database being upgraded should treat this as a two-layer project: our ETL Migration Solutions apply the same validation discipline to that pipeline layer so logic isn't silently broken by the same upgrade.

7. Security and Compliance

Access controls, encryption standards, and privilege settings must align with frameworks like GDPR and HIPAA. A security review beforehand confirms the new environment meets policy expectations before go-live.

8. Rollback and Contingency Planning

Full backups, Flashback technology, and tested contingency procedures let teams revert safely without data loss if something goes wrong mid-project. If reports or dashboards depend on the database being touched, our Reports Conversion team can validate that report output still matches before anyone sees the new environment.

9. High Availability and Cloud Readiness

Many teams use this moment to move toward cloud or hybrid architectures. For organizations also modernizing legacy scripts as part of that same push, our Legacy Scripts practice handles that transition alongside the database work rather than as a separate project. Worth checking OS certification timing too; Oracle Linux version support has historically lagged slightly between releases.

What's New Here

• Native BOOLEAN data type, previously emulated with NUMBER(1) or CHAR(1), now a proper SQL type.
• AI Vector Search and other AI-native capabilities, the basis for the 23ai rebrand.
• SELECT without FROM, simplifying simple expression queries.
• JSON, graph, and microservices enhancements, part of the broader developer-productivity focus.

Key Tools That Support the Migration

Is This the Same as 23ai?

Yes. The release was rebranded 23ai to reflect its built-in AI capabilities; it's the same long-term support target, not two different versions. If you see either name in documentation or tooling, they describe the same thing.

How DataTerrain Helps

A successful upgrade requires expertise, planning, and structured execution, particularly around the non-CDB conversion requirement most teams underestimate. DataTerrain supports this migration process with tailored strategies, AutoUpgrade-based automation, and performance tuning, backed by a track record serving 400+ clients in the U.S. For environments feeding large analytical workloads, our Data Lake team ensures the underlying storage layer is ready before, not after, the database moves.

Planning This Migration?

Non-CDB conversion, character set checks, and rollback planning all need to happen before the upgrade starts, not during it. DataTerrain can assess your current environment and build a plan around AutoUpgrade before you touch production.

Talk to a DataTerrain Oracle Migration Specialist →

Frequently Asked Questions

Related Reading:

Pre-Migration Checklist for Oracle Database Migration from 11g to 23c   |   Key Considerations for Oracle Database Migration   |   Oracle Data Migration Guide: Tools, Steps, and Best Practices   |   Mastering Oracle Fusion Data Migration