Migrer vers Odoo depuis SAP, Oracle ou Sage
Migrer d'un ERP legacy n'est presque jamais une question de technologie. C'est démêler des années de customisations, de données et d'habitudes accumulées. Cet article est le playbook que nos consultants utilisent quand un client nous demande de le sortir de SAP, Oracle, JD Edwards ou Sage.
Les migrations d'ERP legacy ont une réputation d'aller mal, et cette réputation est en partie méritée. La plupart des échecs que nous voyons ne sont pas techniques — ce sont des décisions prises trop tard, des scopes qui ont grossi sans gouvernance, ou des données dont personne n'était propriétaire.
Sur notre portefeuille nous avons sorti des fabricants de SAP Business One, des distributeurs de satellites SAP S/4, des cabinets services d'Oracle E-Business Suite, des retailers de JD Edwards, et une longue traîne de PME de Sage 100, Sage X3 et Dynamics NAV. Les schémas se répètent.
Ce qui suit est l'ordre dans lequel nous menons une migration. Tous les clients n'ont pas besoin de chaque étape, mais sauter les premières est ce qui tue les nuits de cutover — et les réputations.
Commencer par le pourquoi, pas le comment
La première conversation n'est jamais sur Odoo. Elle porte sur pourquoi l'ERP actuel ne convient plus et à quoi ressemble le succès dans deux ans. Cette image dirige tout le reste : scope, séquencement, formation, choix du partenaire.
Les clients qui articulent le pourquoi finissent à temps. Ceux qui ne le peuvent pas sont ceux qui descopent à mi-parcours après avoir dépensé sérieusement sur les parties qu'ils abandonnent. Nous insistons sur cette conversation.
- Documenter les trois principales raisons de migrer
- Définir le modèle opérationnel cible à deux ans
- S'accorder sur ce qui est explicitement hors scope
- Nommer un sponsor exécutif propriétaire du résultat
- Décider quels rapports legacy doivent survivre à l'identique
Cartographier ce qui est réellement utilisé
La plupart des ERP legacy sont 80% configurés, 20% utilisés. Avant de scoper Odoo nous menons une discovery pour mapper ce qui est réellement utilisé, par qui et à quelle fréquence. Les réponses sont souvent surprenantes — et elles réduisent drastiquement le scope de migration.
Sur certains projets la discovery seule a sorti trois modules du scope. Le client payait licences et maintenance pour des écrans que personne n'avait ouverts depuis deux ans. Économiser ce coût est parfois ce qui finance la migration.
- Inventorier modules, écrans, rapports et intégrations actifs
- Sonder les utilisateurs pour distinguer 'utilisé tous les jours' et 'tous les ans'
- Identifier les customisations qui existent pour des raisons historiques
- Décider quoi abandonner, quoi redessiner, quoi reconstruire
- Publier les conclusions — les décisions visibles tiennent mieux
Migration de données : le poteau le plus long
Sur les projets de migration le travail data est presque toujours l'activité la plus longue. C'est aussi d'où viennent la plupart des problèmes de qualité. Traitez-le comme un workstream à part entière avec son propre lead et ses propres quality gates.
Nous allouons typiquement 30 à 40% de l'effort projet à la data. Les clients qui sous-estiment sont ceux qui découvrent des balances déséquilibrées au troisième jour.
- Décider la date de cut-over par flux transactionnel
- Migrer les master data d'abord, le transactionnel ensuite
- Faire des chargements itératifs avec rapports qualité
- Répéter le cut-over deux fois avant le vrai
- Garder un snapshot lecture seule du legacy après extinction
Coexistence et run parallèle
Sur les programmes plus larges Odoo et l'ERP legacy doivent coexister quelques semaines ou mois. Nous concevons la coexistence avec des règles claires : quel système est source de vérité pour quoi, comment les données circulent, et quand le legacy s'éteint. Sans ces règles les deux systèmes dérivent.
Le run parallèle coûte cher — votre équipe opère deux ERP. Limitez-le au minimum nécessaire. Nous visons deux à quatre semaines de parallèle sur les processus critiques, pas trois mois.
- Par domaine de données, nommer le système de référence
- Construire des flux bidirectionnels minimaux et fiables si nécessaire
- Planifier une date d'extinction ferme pour le legacy
- Limiter le run parallèle à des semaines, pas des mois
- Snapshot des données legacy à l'extinction pour audit et historique
Personnes, formation et change
Les migrations technologiques échouent sur les personnes, pas sur le code. Les équipes qui survivent au cutover ont investi dans la formation, dans des champions internes, et dans une communication honnête sur ce qui sera différent au jour 1. Sauter l'un de ces trois est le chemin le plus court vers un mauvais mois 2.
Nous identifions toujours un champion par fonction métier avant le démarrage de la formation. Ce sont eux qui répondront aux petites questions des premières semaines, plus vite qu'un ticket helpdesk. Sans eux chaque micro-question devient une escalade.
- Identifier et nommer des champions par fonction métier
- Former sur des scénarios réels, pas sur des données démo
- Communiquer transparentement — y compris ce qui sera plus dur au début
- Prévoir un support visible les deux premières semaines
- Faire une rétrospective à un mois et à trois mois
Les erreurs qui coulent les migrations d'ERP legacy
Cinq schémas que nous avons vus assez souvent pour les signaler avant qu'ils n'arrivent.
- Laisser le scope grossir sans sponsor exécutif qui pousse en arrière.
- Traiter la migration de données comme une corvée IT au lieu d'un workstream.
- Vouloir reproduire chaque customisation legacy dans Odoo dès le jour 1.
- Faire tourner le parallèle des mois au lieu de semaines — épuise l'équipe.
- Aller en prod sans champions identifiés dans chaque fonction métier.
Comment mesurer la réussite de la migration
Indicateurs suivis pendant trois mois après le go-live.
- Tickets ouverts par utilisateur actif — devrait baisser chaque semaine.
- Temps de complétion sur les 5 processus principaux — retour au baseline au mois 2.
- Score qualité sur les master data — devrait dépasser le baseline legacy.
- Balance fiscale réconciliée au centime près versus legacy en fin de mois.
- Satisfaction utilisateur (pulse léger) en tendance positive au mois 3.
Comment Flydoo conduit les migrations legacy
Nous ne sautons jamais la discovery, même quand le client dit 'on sait ce qu'on veut'. Deux semaines de discovery structurée sur une vraie migration ERP économisent des mois. Nous mappons processus, données, intégrations, rapports ; publions ce que nous trouvons ; rendons les décisions de scope visibles.
Nous construisons ensuite Odoo de manière itérative : une petite tranche passe en prod tôt pour que l'équipe commence à apprendre, les modules plus gros suivent. Le big-bang est réservé aux cas où la coexistence est impossible — généralement pour des raisons de reporting régulé.
- Deux semaines de discovery structurée avant toute configuration
- Publier les conclusions et décisions de scope visiblement
- Go-lives itératifs quand la réalité métier le permet
- Des champions dans chaque fonction avant la formation
- Deux répétitions de cut-over minimum, avec timing mesuré
Checklist de readiness migration
Parcourez cette liste avant de fixer une date de cutover.
- Trois drivers de migration documentés et signés par le sponsor
- Modèle opérationnel cible à 2 ans convenu et communiqué
- Discovery terminée et partagée avec toutes les parties
- Plan de migration de données avec quality gates et dates de répétition
- Champions identifiés et formés par fonction métier
- Scope et durée du run parallèle convenus
- Date d'extinction du legacy planifiée et budgétée
Les migrations sont des projets, pas des événements
Une migration réussie depuis SAP, Oracle ou Sage est le résultat d'un projet structuré, pas d'un héroïsme d'une semaine. Le côté technologique d'Odoo est en bon état — les équipes qui réussissent investissent dans le scoping, la data et les personnes, dans cet ordre.
Choisissez un partenaire qui a déjà fait ce travail, qui vous freinera quand le scope dérive, et qui dira 'non' quand vous demanderez la mauvaise chose. La bonne migration est celle dont votre équipe est encore fière trois ans après.
Si vous pesez une migration depuis un ERP legacy, nous passons volontiers en revue les options de discovery et de scoping avant tout engagement plus grand.
Questions fréquentes
Combien de temps prend une migration typique de SAP ou Oracle vers Odoo ?
Pour une PME (50-200 utilisateurs) nous planifions typiquement 6 à 9 mois du kickoff au go-live, discovery, build, migration de données, formation et cutover compris. Pour des organisations plus larges ou plus régulées, 9 à 18 mois est réaliste. Moins de 6 mois sur une vraie migration legacy est soit minuscule, soit précipité.
Peut-on migrer module par module, ou faut-il un big-bang ?
Quand la réalité métier le permet, nous préférons fortement les go-lives itératifs — commencer par un module contenu (souvent CRM ou RH), puis ajouter la suite. Le big-bang est parfois inévitable pour la compta ou pour le reporting régulé, mais c'est rarement notre premier choix.
Combien de données historiques migrer ?
Moins que vous ne pensez. Les transactions ouvertes et le dernier exercice clos est un baseline typique. Les données plus anciennes vont dans un snapshot lecture seule du legacy. Migrer dix ans d'historique en vaut rarement l'effort et le risque qualité.
Odoo gérera-t-il le même niveau de customisation qu'aujourd'hui ?
Probablement oui — mais demandez-vous si ce niveau est encore nécessaire. La plupart des ERP legacy accumulent des customs qui existent pour des raisons historiques. La migration est l'occasion de revenir à une configuration plus lean. Résistez à l'envie de copier le passé.
Comment gère-t-on l'ancien système après l'extinction ?
Garder un snapshot lecture seule pour audit, requêtes historiques et demandes du fisc. Ne pas le maintenir vivant avec utilisateurs — cela recrée le problème des deux systèmes. Nous livrons typiquement le snapshot comme un environnement gelé avec rétention et décommissionnement documentés.
Envie d'en discuter pour votre propre projet Odoo ? Parlons-en.