Passer d’Odoo 18 à Odoo 19 ne consiste pas seulement à convertir une base de données. Une migration touche aussi les modules, les personnalisations, les interfaces, les référentiels, les droits et les habitudes des utilisateurs.
La bonne question n’est donc pas uniquement « la base démarre-t-elle ? », mais « les opérations critiques fonctionnent-elles correctement, avec des données fiables et un retour arrière maîtrisé ? »
Ce guide décrit une méthode de préparation et de recette. Les modalités techniques dépendent de l’édition, de l’hébergement et des modules utilisés.
- Inventorier avant de migrer évite de transporter des modules et processus devenus inutiles.
- Une copie représentative, des scénarios de recette et un plan de retour arrière sont indispensables.
- La bascule n’est terminée qu’après la stabilisation, la documentation et l’accompagnement des utilisateurs.
Ce qui peut changer entre Odoo 18 et Odoo 19
La base et le standard
Les modèles de données, comportements, vues et fonctions standards peuvent évoluer. Une base convertie doit être contrôlée fonctionnellement.
Les modules spécifiques
Le code personnalisé et ses dépendances doivent être analysés, adaptés, testés ou supprimés lorsqu’une fonction standard le remplace.
Les modules OCA
Pour Community notamment, il faut vérifier la disponibilité, la branche, la maintenabilité et la compatibilité de chaque module réellement nécessaire.
Les intégrations
API, connecteurs, imports, exports, paiements, messagerie et automatisations doivent être rejoués avec leurs cas d’erreur.
La checklist de préparation avant migration
| Chantier | Questions à vérifier | Preuve attendue |
|---|---|---|
| Périmètre | Quelles sociétés, applications, langues, devises et volumes sont concernés ? | Inventaire validé et responsables identifiés |
| Hébergement | Qui contrôle la base, le filestore, le code, les sauvegardes et les accès ? | Sauvegarde restaurable et accès testés |
| Modules | Quels modules sont standards, Enterprise, OCA ou spécifiques ? | Matrice conserver, remplacer, porter ou supprimer |
| Données | Quels doublons, champs incomplets et référentiels incohérents faut-il traiter ? | Rapport de qualité et règles de correction |
| Interfaces | Quels flux entrent ou sortent d’Odoo et comment les erreurs sont-elles gérées ? | Cartographie des flux et tests d’intégration |
| Recette | Quels scénarios prouvent que l’activité peut continuer ? | Cahier de recette, anomalies et validation |
| Bascule | Qui décide, quand arrêter les écritures et comment revenir en arrière ? | Plan de bascule et critères de renoncement |
Une méthode de migration Odoo en 7 étapes
1. Cadrer le périmètre
Définir les sociétés, applications, processus critiques, responsabilités, contraintes de disponibilité et critères de réussite.
2. Inventorier l’existant
Recenser version, édition, hébergement, base, filestore, modules, code, interfaces, automatisations, volumes, accès et sauvegardes.
3. Arbitrer avant de porter
Pour chaque adaptation, décider de conserver, remplacer par le standard, corriger, porter ou supprimer. Cette étape limite la dette reconduite.
4. Préparer une copie représentative
Travailler sur un environnement séparé, avec une copie cohérente et des données sensibles protégées selon le contexte.
5. Convertir et corriger
Exécuter la migration, adapter les modules nécessaires, analyser les journaux et corriger les erreurs reproductibles sans intervenir directement sur la production.
6. Recetter les opérations critiques
Tester droits, CRM, ventes, achats, stock, facturation, comptabilité, documents, automatisations, interfaces et rapports selon le périmètre réel.
7. Basculer puis stabiliser
Geler les changements, sauvegarder, exécuter le plan, contrôler les critères de succès, accompagner les utilisateurs et suivre les anomalies après démarrage.
Community et Enterprise : les responsabilités à clarifier
Les deux éditions nécessitent une gouvernance, des sauvegardes, une recette et un pilotage des risques. La différence tient notamment aux modules utilisés, aux services disponibles et à la chaîne de responsabilité technique. En Community, la compatibilité des modules OCA ou spécifiques et l’organisation de la maintenance doivent être particulièrement explicites. En Enterprise, il faut également tenir compte du contrat, de l’hébergement et des services de mise à niveau applicables au projet.
Consultez notre comparaison Odoo Community ou Enterprise, notre page Migration Odoo et notre méthode d’audit Odoo.
Les erreurs à éviter
- Porter tout le spécifique sans arbitrage : la migration devient une reproduction coûteuse de l’existant.
- Tester uniquement la connexion : un écran accessible ne prouve pas qu’un cycle métier complet fonctionne.
- Nettoyer les données au dernier moment : les anomalies de référentiels perturbent la recette et les contrôles.
- Oublier les interfaces silencieuses : un connecteur peut ne plus envoyer de données sans bloquer l’interface utilisateur.
- Basculer sans critères de retour arrière : la décision doit être préparée avant l’incident, pas pendant.
Sources et suivi de version
Dernière vérification : 21 août 2026. Ce contenu sera revu lors d’une modification significative de la documentation officielle ou des modalités de migration.
Questions fréquentes
Une migration Odoo 18 vers 19 est-elle une simple mise à jour ?
Non. Le passage de version peut affecter la base de données, les modules spécifiques, les dépendances, les intégrations et les usages. Il doit être préparé, testé et validé sur une copie représentative avant la production.
Faut-il migrer tous les modules spécifiques ?
Pas nécessairement. Chaque personnalisation doit être classée : encore utile, remplaçable par le standard, à corriger, à porter ou à supprimer. Migrer sans cet arbitrage reconduit la dette technique.
Comment tester une migration Odoo ?
Avec des scénarios de recette couvrant les opérations critiques, les droits, les imports, les automatisations, les interfaces, les documents et les clôtures métier. Les anomalies doivent être qualifiées avant la bascule.
La démarche est-elle identique pour Community et Enterprise ?
Les principes de gouvernance, d’inventaire et de recette sont communs. Les outils, responsabilités et modalités techniques diffèrent selon l’édition, l’hébergement, les modules OCA ou spécifiques et le contrat de service.