Montée de version Oracle 11g et 12c vers 19c et 26ai. Quelle méthode choisir ?

Sur les audits que nous menons, le constat revient régulièrement, de nombreuses bases Oracle 11g ou Oracle 12c sont encore en production, souvent sur des applicatifs métier critiques. Elles fonctionnent, elles sont sauvegardées, et la montée de version Oracle est reportée d'un exercice budgétaire à l'autre depuis plusieurs années.

Le problème n'est pas la stabilité de ces versions. Il est ailleurs, chaque année de report réduit le nombre d'options disponibles et augmente le coût du chantier quand il finit par devenir obligatoire. La cible suivante, Oracle 26ai, impose en plus de passer d'abord par Oracle 19c.

Voici où en sont ces versions en 2026, les trois méthodes de montée de version possibles, et comment choisir la vôtre selon votre situation.

Fin de support Oracle 11g et 12c : où en sont ces versions en 2026 ?

Les échéances sont derrière nous depuis plusieurs années. Le support étendu d'Oracle 11g s'est arrêté en décembre 2020, celui d'Oracle 12c en juillet 2022.

Ces bases fonctionnent donc sans couverture standard depuis près de six ans pour la 11g et environ quatre ans pour la 12c.

Les dispositifs payants de type Upgrade Support, anciennement Market Driven Support, ont prolongé la couverture de certaines de ces versions. Ces prolongations sont toutefois limitées dans le temps et se referment. Il faut les considérer comme un sas vers la montée de version, pas comme un régime de croisière.

Concrètement, en 2026, une base Oracle 11g ou 12c ne reçoit plus de Critical Patch Update. Son OS sous-jacent est généralement lui aussi en fin de vie, et le couple version majeure et plateforme n'est plus certifié par la plupart des éditeurs applicatifs.

Ce que coûte le maintien d'une base Oracle 11g ou 12c non supportée

Le risque le plus visible est celui des correctifs de sécurité. Les vulnérabilités Oracle publiées chaque trimestre concernent aussi les versions non supportées, à ceci près qu'aucun correctif ne sera produit pour elles. Les scripts d'exploitation, eux, ne font pas de distinction de version.

Au-delà de la sécurité, trois problèmes se posent également.

La certification applicative bloque vos projets. Quand l'éditeur de votre ERP ou de votre logiciel métier publie une nouvelle version, il la certifie sur Oracle 19c, pas sur Oracle 11g. Vous restez donc sur une version applicative ancienne à cause de la base, jusqu'au jour où la contrainte devient impérative et déclenche une montée de version Oracle dans l'urgence.

Le matériel impose son calendrier. Une base 11g tourne rarement sur un OS récent. Le renouvellement du serveur devient impossible sans toucher à la base, et c'est alors l'infrastructure qui fixe la date du projet. De plus, les dernières versions des outils de virtualisation, ne supportent plus non-plus ces versions d'OS obsolètes.

Les compétences se raréfient. Trouver un intervenant à l'aise sur un environnement 11g avec Data Guard et ASM reste possible en 2026. Le vivier se réduit cependant et les délais d'intervention s'allongent.

Pourquoi Oracle 19c reste le passage obligé avant la 26ai ?

Depuis début 2026, la version Long Term Support d'Oracle disponible sur matériel standard est la 26ai. Elle reprend le contenu de la 23ai sous une nouvelle numérotation, et c'est la cible logique pour un environnement Oracle moderne. Mais Oracle 26ai n'accepte en source qu'une base 19c ou 21c. Autrement dit, une base Oracle 11g ne va pas directement en 26ai : la montée de version commence obligatoirement par Oracle 19c.

Ce point change la façon de présenter le projet en interne. Monter en 19c n'est pas une étape défensive destinée à gagner deux ans. C'est la première marche d'une trajectoire dont la cible est 26ai. Oracle 19c reste une cible confortable : le support Premier court jusqu'à fin 2029 et le support étendu jusqu'à fin 2032, ce qui laisse une vraie latitude pour planifier la suite sans se remettre immédiatement sous pression.

Deux nuances sont à connaître. Le support étendu de 19c comporte des exclusions, notamment sur les composants liés à Java 8. Et le passage ultérieur en 26ai impose l'architecture multitenant, la configuration non-CDB étant abandonnée. Autant en tenir compte dès la conception de la montée de version vers 19c plutôt que de refaire le travail deux fois.

Les trois méthodes de montée de version vers Oracle 19c

Upgrade Oracle sur place avec AutoUpgrade

C'est la méthode la plus directe quand le serveur et le système restent en place et que la version source permet une montée directe (11.2.0.4, 12.1.0.2, 12.2.0.1 ou 18c).

AutoUpgrade enchaîne l'analyse préalable, la correction des prérequis, l'upgrade et le post-traitement, sans interaction et sur plusieurs bases en parallèle. Il fait gagner un temps précieux sur les parcs homogènes et rend l'opération reproductible entre préproduction et production.

L'outil ne résout ni la certification applicative, ni le changement de plateforme, ni le jeu de caractères. Il suppose aussi un retour arrière préparé en amont, par sauvegarde ou Flashback Database, car annuler un upgrade n'est jamais anodin.

AutoUpgrade est à écarter si la version source est antérieure à 11.2.0.4. Il faut alors soit passer par un palier intermédiaire, soit changer de méthode.

Montée de version Oracle avec changement de serveur

C'est le scénario le plus fréquent chez nos clients, parce que la montée de version accompagne presque toujours un renouvellement d'infrastructure ou un changement d'OS.

On installe Oracle 19c sur le nouveau serveur, puis on transfère les données. Selon la volumétrie et la fenêtre d'indisponibilité acceptable, on s'appuie sur Data Pump, sur une restauration RMAN suivie d'un upgrade, ou sur une duplication avec bascule courte. Sur les environnements les plus contraints en disponibilité, une réplication logique (goldenGate) permet de réduire l'arrêt à quelques minutes.

Avantage majeur : l'environnement source reste intact. Le retour arrière consiste à rallumer l'ancien serveur, ce qui change radicalement le niveau de stress de la bascule.

Coût : il faut disposer du matériel cible pendant toute la phase de recouvrement, et le transfert de plusieurs téraoctets se prépare sérieusement.

Reconstruction de la base en Oracle 19c

Cette méthode consiste à repartir d'une base neuve et à ne remonter que ce qui doit l'être, avec un modèle de stockage et un paramétrage revus.

Elle se justifie quand la dette accumulée est réelle : schémas obsolètes conservés depuis des années, tablespaces mal dimensionnés, paramétrage hérité de versions successives, objets dépréciés, jeu de caractères à convertir vers AL32UTF8. Dans ces cas, transporter le passé coûte plus cher que le reprendre.

C'est la méthode la plus longue et celle qui mobilise le plus les équipes applicatives. Elle ne se décide pas sur la seule base d'un audit technique.

Elle produit en revanche l'environnement le plus sain, en particulier si la cible Oracle 26ai est prévue à court terme.

Comment choisir son chemin de montée de version Oracle

Quelques critères suffisent à orienter la décision.

Dans tous les cas, la volumétrie, la criticité applicative et la présence d'un éditeur tiers pour certifier la migration pèsent davantage sur le calendrier que la difficulté technique de l'upgrade lui-même. C'est le travail de cadrage que mènent nos consultants Oracle avant d'arrêter une méthode.

Les prérequis d'une montée de version Oracle 11g ou 12c vers 19c

La réussite d'une montée de version se joue sur cinq points.

1. La certification applicative : Elle se vérifie auprès de l'éditeur avant de fixer une date, pas après. Une réponse négative peut compromettre tout le projet.

   
   

2. Les plans d'exécution : Le passage de 11g à 19c change en profondeur le comportement de l'optimiseur. Depuis une 12c, l'écart est plus faible, mais les valeurs par défaut des fonctionnalités adaptatives ont changé en 19c, ce qui suffit à déplacer des plans. Sans capture des plans existants et sans campagne de comparaison avant bascule, les régressions se découvrent en production, sur les traitements de nuit. SQL Plan Management et SQL Performance Analyzer sont là pour ça.

   
   

3. Le jeu de caractères et niveau de sécurité : Une base en WE8ISO8859P15 qui doit passer en AL32UTF8 relève d'un chantier distinct, avec analyse des données tronquables. Il en va de même pour les mots de passe, depuis la 12.2, Oracle refuse par défaut les anciennes empreintes (format 10G). Les comptes concernés se retrouvent bloqués après la bascule. Ces sujets se traitent en amont, jamais pendant la fenêtre de migration.

   
   

4. Les objets dépréciés et les fonctionnalités supprimées : Ancienne syntaxe, options retirées, paramètres obsolètes, fichier de fuseaux horaires à mettre à niveau : l'utilitaire de pré-analyse les remonte, encore faut-il traiter la liste avant et non pendant la bascule.

   
   

5. La restauration : Une sauvegarde qui se termine en succès ne prouve rien. Avant toute montée de version, la seule vérification qui compte est une restauration réelle sur un environnement séparé. C'est aussi l'occasion de valider le plan de retour arrière.

Questions fréquentes sur la montée de version Oracle

Peut-on passer directement d'Oracle 11g à Oracle 26ai ?

Non. Oracle 26ai n'accepte en source qu'une base 19c ou 21c. Une base Oracle 11g ou 12c doit d'abord faire l'objet d'une montée de version vers Oracle 19c.

Quelle est la date de fin de support d'Oracle 19c ?

Le support Premier court jusqu'à fin 2029 et le support étendu jusqu'à fin 2032, avec certaines exclusions.

Combien de temps dure une montée de version Oracle 11g vers 19c ?

L'opération technique tient dans une fenêtre de bascule. C'est la préparation qui fixe la durée réelle du projet : certification applicative, tests de performance et restauration de validation.

Faut-il passer en multitenant lors de la montée de version vers Oracle 19c ?

Ce n'est pas obligatoire en 19c, mais Oracle 26ai abandonne l'architecture non-CDB. Si la cible 26ai est prévue à court terme, mieux vaut traiter le passage en multitenant dès la montée de version vers 19c.