Comparer les versions d'Odoo

Non, et nous le déconseillons.
Odoo publie une version majeure par an. Suivre chaque millésime revient à passer son temps en chantiers techniques sans valeur pour l'entreprise. La bonne cadence est de rester dans les trois versions supportées, ce qui autorise à sauter un cran. Ce qui doit déclencher la décision, c'est un besoin métier précis ou l'approche de la fin de support, pas le calendrier d'Odoo.

Non, elle est sortie du support standard.
Odoo assure le support et la correction de bugs sur les trois dernières versions majeures. Depuis la sortie d'Odoo 19, le trio supporté est 17, 18 et 19. Le support standard dure trois ans, puis un support étendu payant prend le relais, où les corrections sont fournies selon faisabilité. Rester en 16 signifie que les anomalies découvertes ne seront plus corrigées.

De quelques jours à plusieurs semaines, selon vos développements spécifiques.
Une base proche du standard se migre en quelques jours. Ce qui allonge le chantier, ce sont les développements spécifiques accumulés, les modules tiers et le volume de données à contrôler. C'est pour cela que nous commençons toujours par un audit de l'existant avant de donner un délai.

Ils sont repris un par un, et certains disparaissent.
À chaque version, Odoo intègre au standard des fonctions qui étaient auparavant du développement spécifique. Une bonne migration est l'occasion de supprimer du code devenu inutile plutôt que de le transporter. Nous arbitrons chaque adaptation : à reprendre, à remplacer par le standard, ou à abandonner parce que plus personne ne s'en sert.

Oui, c'est même souvent le bon choix.
Odoo enchaîne les scripts de migration successifs, la bascule reste une seule opération pour vous. Sauter deux versions coûte moins cher que deux migrations séparées. En revanche le volume de changements pour les utilisateurs est plus important, donc la formation compte davantage.

Non, si la recette est faite sérieusement.
La migration se fait sur une copie, jamais sur la production. Nous comparons ensuite l'ancienne et la nouvelle base, modèle par modèle et écran par écran. Sur une migration récente, ce contrôle a porté sur des milliers de contacts et d'écritures comptables, sans un seul écart. La production ne bascule qu'après validation.

Non, il faut laisser passer les premières corrections.
Une version majeure se stabilise dans les semaines qui suivent sa sortie. Migrer le premier jour, c'est essuyer les plâtres sur votre production. Nous conseillons d'attendre les premières mises à jour de stabilité, sauf si une fonction précise de la nouvelle version justifie le risque.

Le prix dépend de l'écart entre votre base et le standard.
Une base standard représente un budget modeste. Une base très adaptée demande de reprendre chaque développement, et c'est là que se situe l'essentiel du coût. L'audit préalable donne un chiffrage ferme, et il est déductible du projet si vous nous confiez la migration.

Oui, et c'est le poste le plus souvent sous-estimé.
Le passage en version 17 a changé toute l'interface, et la 20 refond l'application mobile. Une migration réussie techniquement mais mal accompagnée produit des utilisateurs perdus et un rejet de l'outil. Nous chiffrons toujours le temps de formation en même temps que le temps technique.

Oui, et c'est une étape obligatoire chez nous.
Nous montons une copie de votre base dans la version cible, sur laquelle vos équipes déroulent leurs propres scénarios métier. Chaque scénario validé par vous rapproche du feu vert. La bascule n'est jamais décidée par nous seuls.

La démarche est la même, les possibilités techniques diffèrent.
Sur Odoo Online, la migration est déclenchée depuis votre compte et les adaptations possibles sont limitées au paramétrage et à Studio. Sur Odoo.sh, vous disposez d'une branche de test et d'un dépôt de code, ce qui permet de reprendre proprement les développements spécifiques. Le choix d'hébergement conditionne donc le coût de vos migrations futures.

Vous, sur la base d'un calendrier que nous préparons ensemble.
Nous proposons une fenêtre en tenant compte de vos périodes de forte activité, de vos échéances comptables et de la disponibilité de vos équipes pour la recette. Basculer la veille d'une clôture ou en pleine saison n'a jamais de bonne raison.