Comment fonctionne ce calculateur
Ce calculateur estime deux postes de budget en parallèle, puis les additionne. Le premier poste est la migration des données, le travail consistant à extraire vos enregistrements de votre système actuel, à les transformer dans le modèle d'Odoo, à les charger, puis à rapprocher chaque solde contre la source. Le second poste est l'implémentation, le travail consistant à configurer Odoo lui-même : modules, permissions, formations et mise en production. Les deux postes sont presque toujours menés en même temps, mais ils ont des inducteurs de coûts distincts, donc on les présente séparément avant de les fusionner.
Côté migration, quatre leviers multiplicatifs (système source, profondeur d'historique, volume d'enregistrements, qualité des données) s'appliquent à un nombre d'heures de base déterminé par le système source. Deux leviers additifs s'ajoutent : les intégrations à reconstruire et les modules personnalisés à porter. Le résultat en heures est converti en USD à un taux mixte de 175 $/h, qui reflète la composition réelle d'une équipe de migration : architecte de données senior, ingénieur ETL, QA et rapprochement comptable.
Côté implémentation, on réutilise exactement les multiplicateurs du calculateur de coût d'implémentation, parce qu'à périmètre égal les coûts d'implémentation sont les mêmes que vous migriez ou que vous partiez de zéro. Base de 350 $/utilisateur, multiplicateur de modules qui mord à partir du quatrième, complexité métier 1,0x à 2,1x, personnalisation 1,0x à 1,9x. Pour chaque poste, on génère une bande basse à 80 % du point médian et haute à 130 %, parce que la majorité des projets atterrissent sur la borne haute, pas au milieu.
Les vrais inducteurs de coûts de migration
Après plus de 60 migrations vers Odoo, on a vu le même schéma se répéter : le système source décide de l'ordre de grandeur du projet, et tout le reste joue à la marge. Voici comment chaque levier se déploie sur le terrain.
Système source : l'écart de modèle de données
C'est le levier le plus brutal. Migrer depuis QuickBooks prend typiquement 40 à 70 heures parce que le modèle QuickBooks est plat : clients, fournisseurs, items, factures, paiements. Migrer depuis SAP Business One prend 250 à 400 heures parce que le modèle SAP empile UDF (User-Defined Fields), UDT (User-Defined Tables), versions de nomenclature avec dates d'effet, multi-warehouse avec règles de valorisation distinctes par site, et add-ons partenaires (Beas, Boyum, Coresuite) qu'il faut auditer un par un avant de pouvoir mapper quoi que ce soit.
NetSuite tombe au milieu (150 à 250 heures) parce que le modèle est cohérent mais profond : SuiteScripts personnalisés, workflows SuiteFlow, saved searches qui ont fini par devenir des rapports critiques. Les bases de données sur mesure (Access, SQL maison) sont les plus variables : 100 à 400 heures selon le nettoyage que la source nécessite avant d'être importable.
Profondeur d'historique : la taxe de rapprochement
Charger uniquement les soldes d'ouverture est la voie la moins chère et la plus rapide : on prend la balance générale du dernier exercice clos, on l'importe comme journal d'ouverture, et on commence à transacter dans Odoo le jour 1. La plupart des CFO regrettent ce choix six mois plus tard, parce qu'ils ne peuvent plus produire de comparatif inter-annuel dans Odoo. Charger 1 à 3 ans d'historique transactionnel ajoute environ 40 % d'effort. Charger 7 ans ou plus le double, parce que chaque exercice migré doit être rapproché contre la source : trois exercices, trois jeux de tests UAT, trois rondes de rapprochement.
Volume d'enregistrements : l'effort change de classe
Moins de 10 000 enregistrements, on charge en batch unique via les imports natifs Odoo (xlsx, csv) et on valide visuellement. Entre 10 000 et 100 000, on construit des scripts de transformation paramétrés et on rapproche par lots. Au-delà d'1 million, on bascule en pipeline ETL via une staging DB intermédiaire, parce que la fenêtre de cutover doit rester sous 48 heures et qu'un import xlsx de 1 M de lignes ne finit pas dans ce délai. À 1M+, on parallélise aussi les imports sur plusieurs workers Odoo pour respecter la fenêtre.
Qualité des données : le multiplicateur silencieux
Les données « propres » sont rares. Sur 60+ migrations, on a vu une seule base parfaitement propre, et c'était un système jamais utilisé en production. La norme est « typique » : 5 à 10 % de doublons clients, des codes-produits réutilisés au fil des ans, deux ou trois plans comptables qui se sont superposés. Les données « en vrac » sont plus fréquentes qu'on l'admet : doublons à 20+ %, champs libres utilisés comme étiquettes pseudo-structurées, conventions de nommage qui ont changé trois fois, lignes orphelines qui pointent vers des enregistrements supprimés. Chaque palier de qualité ajoute environ 30 % d'effort, parce que le nettoyage doit être documenté, automatisé et appliqué de manière reproductible à chaque dry-run.
Intégrations à reconstruire : pas dans les heures de base
Si votre système actuel pousse ou tire de la donnée vers Shopify, Stripe, ADP, EDI, un connecteur banque ou un système de planning d'atelier, chacun de ces flux doit être recâblé contre Odoo. On budgétise environ 60 heures par intégration en moyenne : authentification, mapping de payload, gestion d'erreurs avec repli exponentiel, supervision et logs centralisés, plus trois rondes d'UAT pour attraper les cas limites. Six intégrations ou plus, on additionne 600 heures additives, parce que le coût grimpe non-linéairement quand plusieurs intégrations doivent coexister sans se battre pour les mêmes enregistrements.
Modules sur mesure à porter : la dette de personnalisation héritée
Tout ce qui n'est pas standard dans votre système actuel doit être rejoué dans Odoo. SuiteScript NetSuite, formules personnalisées Sage, add-ons SAP, rapports Crystal Reports, vues Access bricolées : chaque pièce demande une décision. On reconstruit, on remplace par une fonctionnalité native Odoo, ou on retire purement et simplement. La plupart des clients découvrent à ce stade que 30 à 50 % de leur personnalisation héritée n'est plus utilisée. On enlève ce dead code lors de la phase de discovery, puis on chiffre uniquement ce qui reste. La fourchette additive (0 à 500 heures) reflète ce qui survit au tri.
Scénarios de migration typiques
Quatre scénarios anonymisés tirés de notre archive Octura 2024 à 2026, avec les fourchettes réelles et les durées vécues. Les noms sont changés, les chiffres ne le sont pas.
Scénario 1 : QuickBooks Online vers Odoo, 5 utilisateurs, 18 à 28 k$
Un cabinet de services professionnels au Texas, 5 utilisateurs, QuickBooks Online depuis 4 ans, propre. On a chargé les soldes d'ouverture au 1er janvier et 18 mois d'historique transactionnel pour permettre les comparatifs trimestriels. Pas d'intégrations à reconstruire, un seul rapport sur mesure à porter (une facture personnalisée). Migration : 60 heures. Implémentation : CRM + Ventes + Comptabilité, complexité simple, personnalisation légère. Total facturé : 22 800 $, sur 7 semaines.
Scénario 2 : NetSuite vers Odoo, 25 utilisateurs, 75 à 115 k$
Un distributeur multi-entrepôts au Québec, 25 utilisateurs, NetSuite depuis 6 ans. Le client quittait NetSuite pour échapper à la hausse de licence annuelle. Six SuiteScripts critiques à reconstruire en Python Odoo, intégration EDI 850/856 vers leur principal client de la grande distribution, connecteur paie vers Nethris. On a chargé 3 ans d'historique transactionnel et tous les enregistrements ouverts. Volume : 350 000 enregistrements (M-L). Données typiques avec quelques années de doublons clients à nettoyer. Migration : 480 heures. Implémentation : Ventes, Stock, Achats, Comptabilité, RH (5 modules), complexité modérée. Total facturé : 94 200 $, sur 18 semaines. ROI sur licence : remboursement de la migration en 14 mois.
Scénario 3 : SAP Business One vers Odoo, manufacturier mono-site, 130 à 200 k$
Un manufacturier agroalimentaire en Ontario, 35 utilisateurs, SAP B1 depuis 9 ans avec trois add-ons partenaires (Beas pour la planification d'atelier, Boyum pour l'UX, Coresuite pour le service). On a inventorié les add-ons en discovery et planifié leur remplacement par les capacités natives d'Odoo 19 (Work Centers tablette pour Beas, UI native pour Boyum, helpdesk pour Coresuite). 5 ans d'historique transactionnel, volume L (480 000 enregistrements), qualité typique. Trois intégrations : EDI vers grossistes, connecteur balance peseuse, paie Nethris. Sept rapports Crystal Reports portés en QWeb. Migration : 920 heures. Implémentation : Ventes, Achats, Stock, MRP, Qualité, Comptabilité, RH (7 modules), complexité modérée. Total facturé : 162 500 $, sur 22 semaines.
Scénario 4 : SAP S/4HANA vers Odoo, multi-sociétés, 450 k$ à 1,2 M$
Un groupe industriel américain, 110 utilisateurs sur trois entités juridiques (mère + deux filiales), SAP S/4HANA Cloud depuis 4 ans. Volume XL (1,8 M d'enregistrements), 6 ans d'historique demandé pour le rapport consolidé. Qualité en vrac : trois plans comptables qui se sont superposés au fil des acquisitions. Cinq intégrations à reconstruire (EDI, banque, ADP, deux portails clients), douze modules sur mesure à porter. Migration : 2 100 heures. Implémentation : pile complète multi-sociétés, 100+ utilisateurs, complexité complexe, personnalisation lourde. Total facturé : 825 000 $, sur 38 semaines. Équipe : 9 personnes en pointe, dont 2 ingénieurs migration dédiés à temps plein. Ce sont les projets où le calculateur pousse vers la borne haute en raison de la composition complexité × personnalisation × volume.
Ce que ce calculateur ne couvre pas
Si vous quittez une version Odoo plus ancienne plutôt qu\'un système tiers, utilisez le calculateur de coût de mise à niveau Odoo. Le profil de coûts d\'une migration inter-versions Odoo (8 vers 17, par exemple) est fondamentalement différent d\'une migration depuis NetSuite ou SAP : pas d\'écart de modèle de données, mais un coût qui s\'empile avec chaque saut de version.
Abonnement licence Odoo. Vous payez Odoo S.A. directement, par utilisateur et par mois, pour Standard (~31 $) ou Custom (~47 $). Un projet à 25 utilisateurs sur Custom, c\'est environ 14 160 $/an, qu\'on garde hors du calculateur parce que ce n\'est pas un poste qui transite par nous.
Hébergement. Odoo.sh de 25 à 400 $/mois selon le niveau, ou auto-hébergé sur AWS/GCP/Azure de 150 à 2 000 $/mois selon la taille d'instance et les environnements.
Conduite du changement. Si votre équipe doit redéfinir un processus plutôt que le porter tel quel, c'est du conseil en amont qu'on devise séparément, parce que le livrable est un processus, pas du logiciel.
Support post-production. Forfait mensuel à partir de 2 500 $/mois pour les petits clients, ou support ad-hoc à notre taux horaire standard. Voir la <NuxtLink :to="localePath('/technical-support-policy')">politique de support technique</NuxtLink>.
Les étapes après votre estimation
Le calculateur vous donne un ordre de grandeur réaliste. L'étape suivante, c'est un appel de cadrage de 30 minutes avec un architecte Odoo senior, pas un commercial. On passe en revue votre système source, on challenge votre liste d'intégrations, on signale les modules personnalisés qui peuvent disparaître, et on vous envoie un SOW à prix fixe sous 48 heures.
Réserver un appel de cadrage gratuit de 30 min →