Checklist migration Odoo
24 contrôles avant de mettre la nouvelle version en production
Une migration Odoo ne consiste pas seulement à convertir une base de données. Elle touche aussi les modules standard, les développements spécifiques, les droits d’accès, les intégrations, les documents et les habitudes de travail.
Le risque principal n’est pas toujours l’échec technique. Une migration peut sembler réussie tout en laissant apparaître des données incohérentes, des automatisations silencieusement arrêtées ou des scénarios métiers impossibles à exécuter.
Cette checklist rassemble 24 contrôles à valider avant le passage en production. Elle s’applique à une montée de version Odoo Online, Odoo.sh ou On-Premise. Pour un cadrage adapté à votre environnement, consultez aussi notre accompagnement de migration Odoo.
1. Cadrer la migration avant de toucher à la base
Le cadrage transforme une demande générale de mise à niveau en projet vérifiable. Avant toute opération sur la base, validez les six premiers contrôles.
- Confirmer la version actuelle, la version cible et l’hébergement. Les procédures et responsabilités diffèrent entre Odoo Online, Odoo.sh et une installation On-Premise.
- Inventorier les applications installées. Distinguez les modules réellement utilisés de ceux installés historiquement mais devenus inutiles.
- Recenser toutes les personnalisations. Incluez Studio, les modules développés sur mesure, les vues modifiées, les actions automatisées et les rapports personnalisés.
- Cartographier les interfaces externes. Listez les API, connecteurs bancaires, outils e-commerce, transporteurs, solutions de paiement, BI et échanges de fichiers.
- Choisir une fenêtre de bascule réaliste. Évitez les clôtures, inventaires, campagnes commerciales et périodes de forte facturation.
- Nommer les responsables de validation. Chaque processus critique doit avoir un propriétaire capable d’accepter ou de refuser le go-live.
2. Préparer les modules, les données et les intégrations
La migration technique ne corrige pas automatiquement les configurations obsolètes ni les données de mauvaise qualité. Ces contrôles évitent de transporter les problèmes dans la nouvelle version.
- Vérifier la compatibilité des modules spécifiques. Une version compatible du code doit être disponible pour la version cible avant la migration de production.
- Analyser les dépendances entre modules. Identifiez les bibliothèques, applications tierces et modules communautaires nécessaires au fonctionnement de chaque personnalisation.
- Nettoyer les données de référence. Traitez les doublons clients, produits inactifs, taxes incohérentes, unités de mesure et comptes devenus inutiles.
- Définir les règles de rapprochement. Préparez les contrôles de volumes et de montants pour les clients, fournisseurs, stocks, écritures et documents ouverts.
- Documenter les transformations de données. Toute conversion de champ, de statut ou de référentiel doit être traçable et reproductible.
- Préparer les intégrations pour la version cible. Vérifiez les URL, méthodes d’authentification, formats d’échange, tâches planifiées et mécanismes de reprise après erreur.
Point de vigilance : la documentation Odoo précise que le nettoyage des données et configurations existantes, ainsi que la mise à niveau de certains modules tiers non couverts par une maintenance, ne font pas partie de la simple conversion standard. Ces travaux doivent donc être identifiés, chiffrés et planifiés séparément.
Si votre environnement a beaucoup évolué sans documentation, un audit Odoo préalable réduit fortement les inconnues avant la migration.
3. Tester la version cible dans des conditions réalistes
Une base de test n’a de valeur que si elle reproduit les conditions réelles et si les utilisateurs métiers exécutent leurs scénarios habituels. Validez ensuite les contrôles 13 à 18.
- Obtenir une base test réellement mise à niveau. N’utilisez jamais la production comme premier environnement de validation.
- Restaurer les pièces jointes et le filestore nécessaires. Les documents, images, PDF et fichiers métier doivent être accessibles pendant la recette.
- Installer et mettre à jour les modules spécifiques. Testez leur installation, leurs données, leurs vues et leur interaction avec les fonctions standard de la version cible.
- Exécuter des scénarios métiers de bout en bout. Par exemple : devis, commande, livraison, facture, paiement et comptabilisation, sans se limiter à l’ouverture des écrans.
- Contrôler les droits, notifications et automatisations. Vérifiez les profils, règles d’enregistrement, e-mails, tâches planifiées et actions automatisées avec des comptes représentatifs.
- Mesurer la performance et examiner les journaux. Surveillez les erreurs, traitements longs, files d’attente, requêtes problématiques et échecs silencieux.
4. Préparer le go-live et le plan de retour arrière
Le passage en production doit être un scénario préparé, minuté et réversible. Les six derniers contrôles permettent de décider si la bascule est réellement maîtrisée.
- Définir le gel des changements. Fixez la date après laquelle aucun nouveau développement, paramétrage ou import non essentiel ne sera accepté.
- Créer une sauvegarde finale et tester sa restauration. Une sauvegarde non restaurée au moins une fois reste une hypothèse, pas une garantie.
- Préparer la reprise du delta. Identifiez les données créées ou modifiées entre la dernière répétition et la bascule finale.
- Formaliser le plan de retour arrière. Définissez les critères d’abandon, le responsable de la décision, le délai maximal et la procédure de retour.
- Informer et accompagner les utilisateurs. Prévoyez les changements d’interface, consignes, supports, canaux d’assistance et responsables disponibles le jour J.
- Organiser la surveillance post-production. Suivez les flux critiques, les erreurs, les temps de réponse, les intégrations et les écarts de données pendant les premiers jours.
Feu vert : tous les scénarios critiques sont validés, les données sont rapprochées, les modules spécifiques fonctionnent et le retour arrière a été testé.
Feu orange : seules des anomalies non bloquantes restent ouvertes, avec un responsable, une échéance et une solution de contournement acceptée.
Feu rouge : un flux critique échoue, la restauration n’est pas maîtrisée, les données ne se rapprochent pas ou un module essentiel reste incompatible. Dans ce cas, reportez la bascule.
Conclusion : une migration se décide sur des preuves
Une migration réussie ne se juge pas uniquement au fait que la base démarre. Elle se mesure à la continuité des opérations, à la fiabilité des données et à la capacité des utilisateurs à travailler normalement dès la reprise.
Utilisez ces 24 contrôles comme support de pilotage : attribuez un responsable, une preuve attendue et un statut à chaque point. Les éléments non validés deviennent alors visibles avant qu’ils ne se transforment en incidents de production.
Vous préparez une montée de version ou une reprise de données complexe ? Mon Expert Odoo peut auditer l’existant, sécuriser la recette et construire un plan de bascule adapté à vos flux métiers.