Migration Odoo avec modules sur mesure : la méthode en six étapes

Une migration Odoo sans aucun développement spécifique est surtout une affaire de tests. Dès que votre base contient des modules sur mesure, le projet change de nature : il faut porter du code, migrer des données techniques et organiser une recette sérieuse.

Cet article décrit la méthode que nous suivons pour une montée de version, par exemple d’Odoo 16 vers une version plus récente. Elle s’appuie sur la documentation officielle de mise à niveau d’Odoo et sur son guide dédié aux bases personnalisées.

Pourquoi ne pas repousser la migration indéfiniment

Odoo indique que chaque version majeure est maintenue pendant trois ans. Au-delà, votre base ne reçoit plus de correctifs, y compris de sécurité. Sur Odoo Online, la mise à niveau finit même par devenir obligatoire.

La documentation le dit clairement : plus l’écart entre deux versions est faible, plus la mise à niveau devrait être simple. Attendre d’avoir trois versions de retard, c’est cumuler les changements de modèles, de vues et de syntaxe à absorber d’un coup.

Il faut aussi savoir ce que le service de mise à niveau d’Odoo ne couvre pas : vos modules spécifiques. Tant qu’ils ne sont pas compatibles avec la version cible, la base ne peut pas être migrée. Le portage est à la charge de celui qui maintient ce code.

Étape 1 : geler les développements et les remettre en question

Développer de nouvelles fonctionnalités pendant une migration oblige à les porter et à les tester plusieurs fois. Odoo recommande donc de geler le code dès le début du projet, en ne gardant que les corrections de bugs.

Ce gel est le bon moment pour faire l’inventaire de vos modules. Pour chacun, posez une question simple : la version cible ne fait-elle pas déjà nativement ce que ce module ajoute ? Les notes de version d’Odoo aident à le vérifier.

Chaque module supprimé parce que le standard le remplace, c’est du code en moins à porter aujourd’hui et à maintenir demain. C’est souvent l’étape qui rapporte le plus.

Étape 2 : demander une base de test migrée

Avant de toucher au code, demandez une copie migrée de votre base de production. Selon l’hébergement, la demande passe par la plateforme de mise à niveau d’Odoo, par le gestionnaire de bases d’Odoo Online, par votre projet Odoo.sh ou par une ligne de commande sur votre serveur.

Le but de cette étape n’est pas encore de tester vos modules. Il s’agit de vérifier que la migration standard de vos données se déroule sans erreur. Si elle échoue, c’est au support d’Odoo d’intervenir.

Deux points pratiques. Sur un serveur dédié, la base migrée est livrée sans votre filestore : il faut le fusionner avec celui de la production pour tester dans des conditions réalistes. Et vous pouvez demander plusieurs bases de test si une seule ne suffit pas.

Étape 3 : rendre les modules installables sur une base vierge

Avant de travailler sur vos données, installez vos modules un par un sur une base vide de la version cible. Cela isole les problèmes de code de ceux qui viennent de la configuration de votre production (personnalisations Studio, modèles d’e-mail, traductions).

Les erreurs typiques que la documentation cite à ce stade :

• dépendances de modules invalides ;
• changements de syntaxe (déclaration des assets, composants OWL, attribut attrs) ;
• champs, modèles ou vues standard renommés ou supprimés ;
• XPath qui ne trouvent plus leur cible dans les vues héritées ;
• méthodes renommées ou supprimées.

Une fois l’installation propre, testez réellement le fonctionnement : vues, modèles d’e-mail, rapports, actions serveur et automatisées, champs calculés. C’est aussi le moment de faire passer les tests standard des modules dont vous dépendez, et d’écrire des tests automatisés pour les itérations suivantes.

Étape 4 : faire tourner les modules sur la base migrée

Le code fonctionne sur une base vide ; il doit maintenant fonctionner avec vos vraies données. C’est là qu’interviennent les scripts de migration de vos modules.

Si vous avez renommé un champ, un modèle ou un identifiant externe pendant le portage, un script doit le refléter dans les données. Sinon, les valeurs existantes sont perdues. La bibliothèque d’utilitaires de mise à niveau d’Odoo fournit des fonctions prévues pour cela.

Certains changements de modèle standard demandent aussi du travail. La documentation cite un exemple : lors du passage d’Odoo 15 à 16, les champs personnalisés de sale.subscription ne sont pas migrés automatiquement vers sale.order, et il faut les reprendre par une requête SQL dans un script.

Sur Odoo.sh, une boucle de test pratique

Odoo.sh est intégré à la plateforme de mise à niveau. La dernière sauvegarde de production est migrée puis déposée sur une branche de préproduction, placée dans un mode particulier.

À chaque commit poussé sur cette branche, la base migrée est restaurée et tous les modules sur mesure sont mis à jour. Vous testez donc toujours votre code sur une copie propre de la base migrée. Le journal de migration se trouve dans ~/logs/upgrade.log du build.

Étape 5 : tester en profondeur et répéter la bascule

Les bases de test sont neutralisées : actions planifiées désactivées, serveurs de messagerie sortants remplacés, fournisseurs de paiement et transporteurs repassés en mode test, synchronisation bancaire coupée. Vous pouvez donc tester sans risque pour la production.

Faites tester vos utilisateurs clés sur leurs vrais parcours, pas seulement l’équipe projet. La documentation propose un exemple de test de bout en bout : acheter un produit, le réceptionner, le vendre, l’expédier, le facturer, émettre un avoir et comparer chaque étape avec la production.

N’oubliez pas ce qui sort d’Odoo : intégrations avec d’autres logiciels (EDI, API), exports de données, actions automatisées. Si vous avez connecté des agents d’intelligence artificielle à votre base, ils font partie de ce périmètre, car ils dépendent des noms de modèles et de champs. Nous en parlons sur notre page intelligence artificielle.

Avant la bascule, faites une répétition complète sur une base de test fraîche. Vous mesurez ainsi la durée réelle de l’opération et vérifiez que rien n’a été oublié.

Étape 6 : migrer la production

La migration de la production rend la base indisponible pendant toute l’opération. Planifiez-la sur un créneau que vos équipes peuvent supporter, avec la durée mesurée lors de la répétition.

Sur un serveur dédié, préparez un plan de retour arrière. Sur Odoo.sh, chaque étape passe par une branche de recette. Dans tous les cas, fixez la date de bascule une fois la recette validée, et pas avant.

Après la migration, Odoo joint un rapport de mise à niveau à l’e-mail de confirmation. Il est aussi disponible dans Discuss pour les administrateurs. Lisez-le : il résume les changements introduits par la nouvelle version.

En résumé

Une migration Odoo avec modules sur mesure se réussit avant tout par la préparation :

1. geler le code et supprimer ce que le standard couvre désormais ;
2. vérifier que la migration standard de vos données passe ;
3. porter les modules sur une base vierge ;
4. les faire fonctionner sur la base migrée, avec des scripts de migration ;
5. tester avec les utilisateurs et répéter la bascule ;
6. migrer la production à une date fixée après la recette.

Nous accompagnons les migrations d’Odoo 16 à 20, sur Odoo.sh comme sur serveur dédié. Découvrez notre expertise Odoo ou contactez-nous pour faire le point sur votre base et vos modules spécifiques.