Étapes d'une migration Odoo : le processus e3k

Phase 1 | L'analyse de l'existant 

Tout commence par un budget d'analyse : un développeur ouvre votre instance et fait le tour de ce que vous avez. 

Inventaire des modules et du code sur mesure 

On dresse la liste complète de vos modules : ceux développés par e3k, vos développements sur mesure, et les modules communautaires achetés sur le Odoo Marketplace. On analyse le code pour estimer le temps nécessaire à la migration de chacun. 

Pour chaque module : natif, communautaire ou à migrer? 

C'est le cœur de l'analyse. Pour chaque module, on se pose trois questions : cette fonctionnalité est-elle désormais native dans Odoo? Existe-t-il un module communautaire équivalent? Ou faut-il migrer le développement sur mesure? Cette analyse permet de repérer les vieilles choses qu'on traîne inutilement et de proposer, au passage, un peu de ménage dans le code. 

Le calculateur de devis intégré à Odoo 

Depuis la version 18, Odoo offre un outil que nous utilisons pour cadrer la migration : un gabarit dans lequel le développeur inscrit chaque module, indique s'il doit être amélioré, remplacé ou migré, ajoute un temps estimé et des commentaires. L'outil calcule automatiquement un total, en tenant compte d'éléments comme les PDF, les courriels et les sites web. 

Résultat : une estimation structurée et transparente, bâtie sur la réalité de votre instance. 

Phase 2 | La rencontre client et l'offre de service 

Une fois l'analyse terminée, on se rencontre. On passe le tableau en revue ensemble et on décide, module par module, de ce qu'on garde, de ce qu'on remplace par du natif, et de ce qu'on abandonne. 

C'est un moment clé : c'est là qu'on aligne les objectifs et qu'on s'assure de ne migrer que ce qui a encore du sens pour votre entreprise. L'offre de service qui en découle est ainsi la plus proche possible de vos besoins réels. Certains modules dont vous décidez de vous passer pourront toujours être ajoutés plus tard si le besoin revient. 

Phase 3 | La migration technique et les tests 

Première base de données de test 

Notre développeur migre les modules personnalisés, puis nous ouvrons une première base de données de test. C'est ici que vous entrez en jeu : vous (ou vos utilisateurs principaux, module par module) reproduisez vos opérations habituelles pour vérifier que tout fonctionne comme prévu. Les messages d'erreur, nous les captons de notre côté; vous, vous validez surtout que les comportements attendus sont bien là. 

Deuxième base et formations d'appoint 

On corrige ce qui doit l'être, puis on ouvre une deuxième base de données. Entre cette étape et le go-live, on organise des formations d'appoint : voici ce qui est nouveau, voici les changements de procédure. On concentre l'effort là où ça compte le plus — souvent la comptabilité — et on peut former un super-utilisateur chez vous qui montrera ensuite à son équipe. 

Phase 4 | Le go-live  

Vient enfin la mise en ligne. C'est nous qui la réalisons, à une date fixée ensemble. Comme tout a été testé en amont, il n'y a normalement pas de mauvaise surprise le jour J. 

La checklist du jour J 

On suit une checklist rigoureuse le jour de la migration : vérification des soldes comptables, du numéro des dernières factures, du grand livre. On compare les soldes de fin entre l'ancienne version archivée et la nouvelle pour s'assurer que tout a suivi. Votre ancienne instance reste sauvegardée et accessible : en cas d'imprévu, on peut toujours s'y référer avant de considérer la migration comme définitive. 

Bonne nouvelle pour la comptabilité : il n'y a pas de « fin d'année » à faire avant une migration. Le lendemain, vous êtes simplement dans la nouvelle version. On s'assure seulement que la balance et les soldes du grand livre ont bien été reportés. 

Après le go-live, on poursuit avec les ajustements et les quelques éléments qui n'auraient pas été vus. 

Combien de temps ça prend? 

La durée dépend de la complexité de votre instance, mais le calendrier suit le rythme d'Odoo. La nouvelle version majeure sort à l'automne. Il faut ensuite compter un à deux mois pour que le script de migration se stabilise : on laisse volontairement passer un peu de temps, en novembre et décembre, pour que les principaux enjeux techniques soient identifiés et corrigés. 

Résultat : les migrations clients démarrent généralement à partir de décembre et s'échelonnent jusqu'au printemps. 

Pour les entreprises qui doivent éviter la surcharge de 25 % sur leurs licences Odoo, on bâtit un calendrier précis autour de leur échéance. Les migrations moins urgentes — par exemple passer de la 18 à la 19 juste pour les nouveautés — s'étalent ensuite sur le reste de l'année. 

À titre indicatif, une migration d'une seule version d'écart (ex. Odoo 18 → 19) demande généralement moins d'effort technique qu'une migration qui saute plusieurs versions : plus l'écart est grand, plus le code des modules personnalisés doit être adapté en profondeur aux changements d'API et de structure de base de données.