Stack · Migration
Migration de version Odoo
Migrer Odoo ne coûte pas cher à cause d'Odoo. Ça coûte cher à cause de ce que votre prestataire précédent y a mis — et de ce qu'il a mis dedans plutôt qu'à côté.
C’est le sujet sur lequel les devis varient le plus, et pour une raison simple : la migration ne porte presque jamais sur Odoo. Le cœur migre, c’est le travail de l’éditeur et de la communauté. Ce qui coûte, c’est ce qui a été ajouté autour — ou pire, dedans.
Ce qui coûte vraiment
| Élément | Effort de migration |
|---|---|
| Cœur d’Odoo standard | Faible — ce n’est pas votre problème |
| Modules spécifiques bien écrits | Modéré, proportionnel au volume |
| Modules tiers maintenus | Modéré — attendre la version cible |
| Modules tiers abandonnés | Élevé — reprendre, remplacer ou abandonner |
| Cœur modifié | Très élevé — c’est une réécriture |
| Données | Chantier distinct, selon l’historique |
Le tableau explique les écarts de prix. Un même « migrer de la version N à N+2 » recouvre une semaine ou six mois.
Le cœur modifié : le point de non-retour
C’est pour ça que nous refusons de toucher au cœur, même quand ça ferait gagner trois jours et que le client insiste. Le gain est immédiat, la facture est différée, et ce n’est pas nous qui la payons.
Deux chantiers distincts
Le code. Vos modules doivent être portés : API changées, méthodes disparues, vues à adapter. C’est du travail de développement, mesurable en lisant le code — donc chiffrable sérieusement, à condition d’avoir lu le code.
Les données. Les structures évoluent, vos données doivent être transformées pour entrer dans le nouveau modèle. C’est un chantier à part, avec ses propres questions : que reprend-on de l’historique ? Tout n’a pas la même valeur. Dix ans d’écritures comptables, oui. Dix ans de brouillons de devis, la question mérite d’être posée.
La méthode
- Audit de l’existant. Version, modules, code spécifique, cœur touché ou non, volumétrie, modules tiers et leur état de maintenance. Sans ça, tout chiffrage est une fiction.
- Décisions de périmètre. Ce qu’on garde, ce qu’on remplace, ce qu’on abandonne. C’est une conversation, pas une conséquence technique.
- Migration du code, sur une copie.
- Migration des données, rejouable — et rejouée, plusieurs fois.
- Recette par vos utilisateurs, sur leurs cas réels. Pas par nous sur des cas théoriques.
- Bascule, qui n’est qu’une répétition de plus, avec un retour arrière prévu.
L’étape 5 est celle qu’on sacrifie quand le planning glisse. C’est aussi celle qui fait échouer les migrations.
Les limites, dites franchement
Un audit préalable est indispensable, et il se paie. Nous ne chiffrons pas une migration sans avoir lu le code. Un prestataire qui vous annonce un prix au téléphone vous annonce un prix faux — vous découvrirez le vrai à mi-parcours.
Un module tiers abandonné est une décision, pas un problème technique. Personne ne peut le faire revivre par magie. Il faut choisir : équivalent, redéveloppement, ou abandon de la fonction.
Certaines migrations ne valent pas leur prix. Sur un Odoo très ancien, très modifié, une reconstruction propre coûte parfois moins cher qu’une migration — et donne un système qu’on pourra migrer la fois d’après. Nous le disons quand c’est le cas, même si le mot « reconstruction » fait peur.
Pour éviter d’en arriver là, voir développement de module.
Questions fréquentes
Pourquoi les devis de migration varient-ils autant ?
Parce qu’ils ne portent pas sur la même chose. Migrer un Odoo standard avec deux modules propres est court. Migrer un Odoo dont le cœur a été modifié, avec douze modules tiers dont trois abandonnés, est une réécriture. Un prestataire qui chiffre sans avoir audité l’existant chiffre au hasard — ou vous annoncera la vérité à mi-parcours.
Faut-il migrer à chaque version ?
Non. Mais rester bloqué trop longtemps transforme une migration en chantier : plus l’écart de versions est grand, plus les changements s’accumulent, et plus les modules tiers dont vous dépendez risquent de ne jamais avoir suivi. Une version de retard se gère, quatre se subissent.
Que se passe-t-il si un module tiers n'existe plus dans la version cible ?
Trois options : trouver un équivalent, redévelopper la fonction, ou l’abandonner. Toutes se décident avec vous, avant le projet. C’est précisément ce que l’audit préalable sert à révéler — pas à découvrir en cours de route.
Et les données ?
C’est le second chantier, distinct du code. Les structures évoluent d’une version à l’autre, et vos données doivent être transformées pour entrer dans le nouveau modèle. Sur des bases anciennes, la reprise de l’historique se discute : tout n’a pas la même valeur, et tout n’a pas le même coût.
Peut-on tester avant de basculer ?
C’est obligatoire, et ce n’est pas négociable pour nous. Une migration se fait sur une copie, se recette avec vos utilisateurs sur vos vrais cas, et se rejoue jusqu’à ce que le compte y soit. La bascule réelle n’est alors qu’une répétition de plus.
Un point technique à valider ?
Décrivez le contexte : version d'Odoo, systèmes en jeu, volumétrie. Réponse d'un intégrateur sous 24 h ouvrées.