Oracle 19c and 26ai: the countdown has begun. Which path to choose?
- Jean-Michel Alluguette – OP&S
- Dec 17, 2025
- 4 min read
For years, many companies have standardized on Oracle 19c . This makes sense: it is a long-term version, widely deployed, and still supported for several years.
But the context is changing: Oracle has announced the arrival of Oracle AI Database 26ai on-premises on Linux x86-64 from January 2026.
The question is therefore no longer “19c or nothing”, but rather:
How to secure 19c in the short term, while properly preparing for the next big step (26ai)?
This article offers a pragmatic, production-oriented approach: reduce risks , control costs , and avoid migrating problems along with the version .
Why is this topic now "IT Director", not just "DBA"?
An Oracle version trajectory affects more than just the technical aspects:
Production / IT Department : maintenance windows, service continuity, reversibility
Security : patching posture, technical debt, compliance
Infrastructure / Cloud / FinOps : sizing, costs, rationalization
ERP (JDE, EBS) : compatibility, batch processing, critical processing
Purchases / Licenses : activated options, audit risk, contractual trajectory
Therefore, we need to move beyond the “technical upgrade” debate and start thinking about “management”.
19c: a solid foundation, but not a complete strategy
19c remains an important step: First Support until December 31, 2029 , and Extended Support until December 31, 2032 (according to Oracle documentation).
But even if 19c holds up for several more years, you need to anticipate two things:
Technical debt accumulates if you indefinitely postpone the next trajectory.
The arrival of 26ai provides a new point of convergence (and therefore a new decision-making timetable).
26ai in January 2026 (Linux): what this changes in concrete terms
Oracle has announced on-premises availability of 26ai for Linux x86-64 in January 2026 (RU 23.26.1).
Without getting into "AI" marketing, the real impact for you is primarily:
a major new “turning point” for post-19c trajectories,
a roadmap topic (when to migrate? which batch? what scope?),
and the need to prepare (compatibility, application testing, runbooks, etc.).
The 3 classic mistakes when talking about “19c / 26ai”
Mistake 1 — Thinking “version” instead of thinking “risk”
A successful migration is not simply “it starts”.
It's "it starts up and it's stable , performance is controlled , and costs/licenses are under control."
Error 2 — Migrating without a “before” photograph
Without a property condition report (beforehand), you cannot prove:
if you have improved,
or if you have regressed,
nor explain to the professions what has changed.
Error 3 — Migrating while carrying unresolved issues
If your environment is already experiencing issues (I/O, contention, parameters, volume), the migration may:
amplify the noise,
complicate the diagnosis,
wasting your time (and credibility).
The right approach: a two-step trajectory (short term + next step)
Phase 1 — Securing and streamlining existing systems (often on 19c)
Objective: to stabilize, reduce risks, control costs without waiting for migration .
identify the risk bases (perfusion / restraint / I/O / configuration),
identify the drift (trends over several months),
clean up the cost/license issues (activated options, oversizing).
Stage 2 — Prepare the next stage (26ai) in an industrialized manner
Objective: not to “endure” 26ai, but to be ready to migrate in batches, cleanly.
choose a pilot area,
define the success criteria (performance, stability, batches, SLA),
industrialize (runbook, tests, before/after validation).
How OP&S helps to pilot the 19c → 26ai trajectory (without manual benchmarking)
This is exactly where OP&S has value: you don't need to run a benchmark over several weeks , because the metrics already exist in the history.
OP&S:
collects metrics regularly and keeps a history,
makes deviations visible (before/after, trends, comparable periods),
highlights the “signature” of the problem (I/O, concurrency, configuration…),
and helps to objectify discussions between IT / DBA / Infrastructure / ERP / Purchasing.
In migration, the key capability is: “before vs after” comparison over equivalent periods (same time slots, same batches, same loads).
“Ready for 19c / 26ai?” checklist
Do I have a complete inventory of my databases (PROD + non-PROD)?
Have I identified the critical databases (ERP, batch processes, business workflows)?
Do I know which bases are trending in performance?
Do I know if the pain is coming more from I/O, restraint, or configuration?
Do I have a clear view of the oversizing (infrastructure/FinOps gains)?
Have I identified the Oracle options that are enabled and the actual usage (license risk)?
Do I have a usable “before picture” to validate the migration?
Do I have a pilot scope and a validation runbook?
Conclusion
With the announced availability of 26ai on-prem Linux in January 2026 , it becomes relevant to adopt a discourse (and a strategy) “19c + trajectory towards the next major version” .
19c remains a solid foundation that has been supported for several years, but the real success lies in:
stabilize and streamline now,
and prepare 26ai without incurring technical debt.
A pre-migration audit to avoid unpleasant surprises
We offer a one-month pre-migration Oracle audit , with a report included.
You will see what is really happening in your bases:
– where are the performance risks?
– which options are activated without justification,
– what gains you can achieve by streamlining before the migration.
A preventative audit now can save you months of stress later.
About the author
Jean-Michel Alluguette is the founder of OP&S, a software dedicated to Oracle and ERP (JD Edwards / E-Business Suite) environments to manage performance, costs (FinOps) and security/licenses.
Do you want a factual analysis of your Oracle databases? → Request a free 1-month PoC.
Comments