TL;DR : La plupart des migrations d'Oracle vers PostgreSQL qui échouent ne le font pas parce que PostgreSQL n'était pas prêt.
Ils échouent parce que le projet n'était pas prêt.
Les cinq schémas ci-dessous se répètent dans les organisations et les secteurs d'activité parce que les équipes font les mêmes suppositions : que les outils gèrent plus qu'ils ne le font, que le volume de PL/SQL est plus petit qu'il ne l'est, et qu'un plan de retour arrière peut être improvisé à 2 heures du matin.
J'ai vu des projets de migration échouer dans tous les sens.
Dépassements budgétaires où l'estimation initiale était erronée d'un facteur de huit.
Des nuits de mise en production qui se sont terminées par une opération de récupération de trois jours.
Systèmes de production où six mois d'horodatages sont devenus silencieusement minuit.
Aucun de ceux-ci n'a été causé par PostgreSQL.
Aucun d'entre eux n'a été causé par les outils de migration.
Chacun d'entre eux a été causé par une hypothèse de planification qui s'est avérée erronée.
Voici cinq des modèles d'échec les plus courants - anonymes, mais représentatifs de ce qui se passe lorsque la préparation n'est pas à la hauteur de la complexité du travail.
Table des matières
Pourquoi les migrations d'Oracle vers PostgreSQL échouent-elles ?
La plupart des échecs de migration sont dus à trois causes profondes : un volume PL/SQL sous-estimé, des dépendances spécifiques à Oracle dans le code applicatif que personne n'a audité avant le début du projet, et des plans de basculement qui ont supposé que le pire scénario n'arriverait pas.
La technologie fonctionne.
C'est au niveau de la planification que les choses se gâtent.
Échec 1 : L'équipe qui a sauté l'évaluation
Sauter l'évaluation préalable à la migration ne fait pas gagner de temps – cela reporte le temps à une partie plus coûteuse du projet.
Une équipe qui découvre à mi-migration qu'elle a 200 procédures stockées au lieu de 20 n'a pas évité l'effort d'évaluation ; elle l'a payé au prix d'un changement rapide alors que le délai est déjà dépassé.
Une entreprise de télécommunications a exécuté ora2pg directement sur leur schéma sans générer d'abord le rapport d'évaluation.
L'outil de migration lui-même fournit une note de complexité et un décompte des objets — ils l'ont ignoré car ils étaient confiants dans la simplicité du schéma.
Trois semaines plus tard, l'équipe a trouvé plus de 200 procédures stockées dans des paquets Oracle.
Le rapport d'évaluation l'aurait montré en une heure.
Le calendrier initial du projet était de quatre semaines.
La chronologie finale était quatorze.
Le rapport d'évaluation (ora2pg -t SHOW_REPORTprend moins d'une journée pour s'exécuter et être examiné.
C'est le document qui fixe le budget, le calendrier et la taille de l'équipe.
Mener une migration sans cela équivaut à établir un devis pour un projet de construction sans étude.
Échec 2 : Le PL/SQL que personne n'a compté
La note de complexité d'ora2pg est un point de départ utile, mais ce n'est pas une estimation de la charge de travail.
Un schéma classé “peu complexe” peut encore contenir des milliers de lignes de PL/SQL si la structure des paquets est profonde - parce qu'ora2pg compte les paquets comme des objets uniques indépendamment du nombre de procédures et de fonctions qu'ils contiennent.
Une société de services financiers a utilisé la classification de complexité ora2pg pour estimer l'effort de migration et l'a présentée au conseil d'administration comme base du budget.
La note indiquait une faible complexité.
Personne n'a développé le rapport en détail au niveau de l'objet.
Personne n'a compté les procédures individuelles à l'intérieur de chaque paquet.
Le schéma comportait douze paquets.
Les douze paquets contenaient 140 procédures stockées et fonctions individuelles.
L'effort réel de portage vers PL/pgSQL a été huit fois supérieur à l'estimation initiale.
La solution est simple : toujours analyser le rapport ora2pg au niveau de l'objet.
Comptes les procédures individuelles dans les packages, pas seulement les packages eux-mêmes.
Ajoutez ensuite 30% pour tester chaque unité portée.
Échec 3 : Les colonnes de date qui ont perdu du temps en silence
C'est le modèle de perte de données silencieuses le plus courant dans les migrations d'Oracle vers PostgreSQL.
Oracle DATE stocke la date et l'heure. PostgreSQL DATE stocke uniquement la date.
Lorsque la date Oracle est mappée à la date PostgreSQL — ce qui est la valeur par défaut dans certaines configurations — la composante temporelle de chaque valeur est silencieusement supprimée. Aucune erreur. Aucun avertissement. Les données se chargent proprement et l'heure a disparu.
Une entreprise de vente au détail a migré son système de réservation.
L'application a été testée parfaitement.
Les tests unitaires ont réussi.
L'équipe UAT a donné son approbation.
Les données de test avaient été générées sans composantes temporelles – toutes les dates étaient minuit par coïncidence.
Le système de production possédait deux années d'enregistrements de réservations avec des horodatages réels.
Ils ont été mis en ligne un samedi.
Lundi, chaque réservation historique affichait minuit comme heure.
Les données de nomination remontant à deux ans ont dû être restaurées à partir de la sauvegarde Oracle et revalidées.
La solution est une ligne dans la configuration d'ora2pg : MODIFY_TYPE date TIMESTAMP.
Appliquez-le sans exception à toutes les colonnes de date dans le schéma.
Ça ne coûte rien et évite complètement cette défaillance.
Sur le point de commencer une évaluation de migration et vous ne savez pas dans quoi vous vous embarquez ?
J'offre une évaluation à tarif fixe qui analyse la complexité de votre schéma, le volume de PL/SQL et les dépendances SQL de votre application — et fournit un registre des risques écrit avant le début de tout travail de migration.
Voir ce que couvre l'évaluation
Échec 4 : Le code de l'application que personne n'a lu
La migration de base de données est la partie visible du projet.
Les changements d'application sont ce qui fait dérailler le projet.
Dialecte Oracle SQL — ROWNUM, DE DUEL, NVL(), (+) jointures externes, CONNECT BY, SYSDATE — ne s'exécute pas sur PostgreSQL.
Si la base de code de l'application n'a pas été analysée à la recherche de ces modèles avant le début de la migration, la portée des travaux de modification de l'application est inconnue.
Une portée inconnue est le moyen le plus rapide de manquer une échéance.
Une société de logistique a migré une base de données d'opérations essentielles.
La migration elle-même s'est déroulée proprement.
Les décomptes de lignes correspondent.
Les valeurs de séquence ont été réinitialisées correctement.
La fenêtre de transition a été clôturée à temps.
L'application a refusé de démarrer.
La base de code contenait 140 occurrences de SQL de dialecte Oracle réparties sur onze services différents.
Rien de tout cela n'avait été identifié avant la date de basculement.
L'équipe avait supposé que la couche application utilisait le SQL ANSI standard.
Ça n'est pas arrivé.
La remédiation a nécessité trois semaines de travail de développement d'applications qui n'avaient pas été budgétées.
La solution : avant d'écrire une seule ligne de script de migration, recherchez dans la base de code de l'application des modèles SQL spécifiques à Oracle.
La recherche prend des heures.
Obtenir les résultats en production prend des semaines.
Échec 5 : Le basculement sans plan de retour arrière
“La formule ”Nous reviendrons en arrière si nécessaire" n'est pas un plan de retour en arrière.
Un plan de retour en arrière est un document écrit qui spécifie exactement ce qu'il faut faire pour revenir à Oracle, combien de temps cela prend, qui exécute chaque étape et quel sera l'état des données au moment du retour en arrière.
Si ce document n'est pas disponible avant l'ouverture de la fenêtre de basculement, il n'y a pas de retour arrière — il n'y a qu'une récupération improvisée sous pression.
Une organisation de santé a mis en service un dimanche soir.
Des problèmes de performance sont apparus à 2h du matin.
L'équipe a pris la décision de faire marche arrière.
L'environnement Oracle avait été partiellement mis hors service trois jours plus tôt afin de récupérer les coûts d'infrastructure.
Le DBA qui avait effectué la désaffectation ne faisait pas partie de l'équipe de basculement.
Personne n'avait documenté ce qui avait été retiré.
La convalescence a duré trois jours.
L'organisation a fonctionné selon des procédures de secours manuelles pendant toute la durée.
La leçon n'est pas que le basculement aurait dû être retardé.
La leçon est que le plan de retour arrière doit être écrit, testé en staging, et l'environnement Oracle doit rester entièrement intact — pas partiellement, pas majoritairement — jusqu'à ce que le nouveau système soit validé en production.
Déclasser Oracle après la signature, pas avant la mise en service.
Foire aux questions
La raison la plus courante des échecs de migration d'Oracle vers PostgreSQL est la complexité des différences entre les langages de requêtes et les fonctionnalités spécifiques à Oracle.
Le volume sous-estimé de PL/SQL est la cause la plus fréquente de dépassement du budget et des délais.
Les équipes évaluent le nombre d'objets de base de données mais ne comptent pas les procédures individuelles à l'intérieur des packages.
La deuxième cause la plus fréquente est la dialecte SQL Oracle non découverte dans le code applicatif qui ne se manifeste qu'au moment du basculement.
Pouvez-vous récupérer d'une migration Oracle vers PostgreSQL qui a échoué ?
Oui — si l'environnement Oracle est toujours intact.
La condition préalable essentielle est de maintenir le système Oracle source pleinement opérationnel jusqu'à ce que la migration ait été approuvée en production.
Si Oracle a été partiellement mis hors service avant la signature, la récupération devient un exercice de restauration plutôt qu'un retour en arrière, ce qui est nettement plus coûteux et plus lent.
Comment éviter de dépasser le budget lors d'une immigration ?
Exécutez le rapport complet d'évaluation ora2pg avant de définir un budget.
Développez-la pour obtenir des détails au niveau des objets et comptez les procédures individuelles à l'intérieur des packages.
Recherchez dans la base de code de l'application le dialecte SQL Oracle avant d'évaluer le travail de modification de l'application.
Prévoyez au moins 30% de l'effort du projet pour les tests.
Toute migration ayant largement dépassé le budget a sauté au moins une de ces étapes.
La chose la plus importante à faire avant de commencer une migration est la planification.
Exécuter l'évaluation de pré-migration.
Le rapport d'évaluation ora2pg (ora2pg -t SHOW_REPORT) vous donne le nombre d'objets, un indice de complexité et une estimation de l'effort de migration.
Cela prend moins d'une journée et constitue la seule base fiable pour un budget et un calendrier de projet.
Chaque autre décision de planification découle de celle-ci.
En résumé
Ces cinq échecs ne sont pas inhabituels.
Elles sont le résultat par défaut lorsque la préparation ne correspond pas à la complexité du travail.
La technologie de base de données n'est pas le risque.
PostgreSQL est mature, prêt pour la production et utilisé à grande échelle dans les secteurs bancaire, des télécommunications et de la santé dans l'UE.
Le risque réside dans la planification : évaluations omises, évaluations de complexité mal interprétées, types de données non mappés, code d'application non audité et plans de retour en arrière qui n'existent qu'à l'état d'intentions.
Chacun de ces échecs aurait pu être évité avec une semaine de préparation adéquate au début du projet.
Si vous planifiez une migration et souhaitez un avis indépendant sur la répartition des risques avant de vous engager sur un calendrier ou un budget, prendre contact →