Ce que recouvre vraiment la migration ERP
La migration ERP est le processus structuré qui consiste à faire passer une entreprise d'un système de planification des ressources (ERP) à un autre. Elle couvre quatre flux de travail parallèles : l'extraction et le nettoyage des données de l'ancien système, la configuration et la personnalisation du nouveau, l'accompagnement du changement pour les utilisateurs, et une bascule définie de l'ancien vers le nouveau. L'expression est parfois utilisée comme synonyme d'« implantation ERP », mais le cadre « migration » insiste sur le fait qu'il existe des données, des processus et des utilisateurs en place — il ne s'agit pas d'un déploiement greenfield.
Les migrations ERP les plus courantes que nous voyons en 2026 : QuickBooks → Odoo, NetSuite → Odoo, SAP Business One → Odoo, Sage 300 → Odoo, et OpenERP / Odoo 7–14 legacy → Odoo 19 moderne. Chacune a sa propre forme, mais le cadre en six phases ci-dessous reste globalement le même.
Cinq raisons qui poussent à migrer un ERP
Sur 100+ migrations, le déclencheur du changement se concentre autour de cinq schémas :
- Le coût. Les frais d'abonnement, de support et d'heures partenaires s'accumulent. Un renouvellement NetSuite de 5 ans qui arrive à 400 000 $ est un déclencheur fréquent.
- Le plafond fonctionnel. Le système actuel ne peut pas faire ce dont l'entreprise a besoin maintenant — multi-entrepôts, multidevise, MRP de fabrication, e-commerce natif.
- La dette de personnalisation. Des années de personnalisations ABAP, SuiteScript ou VBA au cas par cas rendent chaque mise à jour douloureuse et chaque modification risquée.
- L'enfermement fournisseur. Concentration de l'hébergement, formats de fichiers propriétaires et exclusivités partenaires finissent par ressembler à une prise d'otages.
- La fin de vie. Le système actuel atteint sa fin de vie — Microsoft Dynamics GP, Sage 50 perpétuel, Quickbooks Desktop, SAP B1 sur d'anciennes versions HANA, et OpenERP legacy forcent tous une migration tôt ou tard.
La combinaison la plus fréquente est « coût + plafond fonctionnel en même temps » — le budget est le déclencheur, mais ce sont les nouveaux besoins fonctionnels qui justifient la migration.
Le cadre de migration ERP en six phases
Toutes les migrations ERP que nous avons livrées avec succès suivent ces six phases. Sauter l'une d'elles — et nous en avons vu chacune sautée à un moment ou un autre — est ce qui sépare une bascule propre d'un retour en arrière en urgence.
Phase 1 : Découverte et audit (1–3 semaines)
Cataloguer le système actuel : quels modules sont réellement utilisés, quel code sur mesure est encore actif, quelles intégrations existent, où vivent les données. Identifier les données « à reprendre » par rapport à celles « à archiver en stockage froid ». Livrable : un document fit-gap et un périmètre à prix fixe.
Phase 2 : Configuration du nouveau système (3–8 semaines)
Construire le nouvel ERP from scratch en utilisant les meilleures pratiques actuelles. Résister à la tentation de recopier exactement le plan comptable ou les workflows hérités — la majeure partie de la structure legacy est de la dette technique, pas une exigence métier. Configurer d'abord les modules standards ; reporter toute personnalisation à la phase 3.
Phase 3 : Personnalisation et intégrations (3–10 semaines, en parallèle)
Seules les personnalisations qui passent le test du « avons-nous encore besoin de ça ? » sont reconstruites. Les personnalisations legacy sont en moyenne obsolètes à 40–60 % au moment de la migration. Les intégrations (Shopify, Stripe, Avalara, partenaires EDI) doivent généralement être réimplémentées plutôt que copiées.
Phase 4 : Migration des données (2–6 semaines)
Trois passes minimum : une migration complète pour identifier les problèmes de mappage de champs, une passe de nettoyage après corrections côté métier, et une migration de répétition générale la semaine précédant la bascule. Les transactions ouvertes (factures impayées, commandes ouvertes, OF en cours) demandent un traitement soigné. L'historique clôturé est généralement archivé plutôt que migré.
Phase 5 : Tests utilisateurs et formation (2–4 semaines)
De vrais workflows sur de vraies données, exécutés par les utilisateurs réels qui utiliseront le nouveau système. La validation des testeurs devient une porte ferme avant la bascule. Des supports de formation spécifiques à votre configuration — pas des vidéos Odoo génériques — réduisent de 60–80 % le nombre de tickets post-go-live.
Phase 6 : Bascule et hyper-care (1 week-end + 30 jours)
Un week-end de bascule planifié, généralement à proximité d'une fin de mois pour des raisons comptables. L'ancien système passe en lecture seule le vendredi soir ; la migration finale des données tourne dans la nuit ; les utilisateurs basculent sur le nouveau système le lundi matin. Un ingénieur d'astreinte nommé est dédié pendant 30 jours après. L'ancien système reste en lecture seule pendant 90 jours en filet de sécurité.
Cinq pièges qui font échouer les migrations ERP
- Migrer des données sales. Plan comptable poubelle en entrée, plan comptable poubelle en sortie. Investissez 2 à 4 semaines dans le nettoyage des données maîtres avant la phase 4 — cela rapporte 10× en erreurs post-go-live évitées.
- Vouloir copier le système legacy à l'identique. L'ancien workflow existe à cause des limitations de l'ancien système. Forcer le nouveau système à recréer ces limitations annule l'intérêt de la migration.
- Bascule big-bang sur toutes les entités. Les vagues phasées fonctionnent ; le big-bang sur une société à 5 entités est un schéma d'échec connu. Migrez d'abord la plus petite entité comme pilote, puis passez à l'échelle.
- Sous-estimer la reconstruction des intégrations. Shopify, EDI, paie, moteurs fiscaux ne se transfèrent que rarement proprement. Budgétez 30–50 % de l'effort total d'implantation pour la reprise des intégrations.
- Pas de référent interne. Une migration sans sponsor métier dédié s'enlise en moins de trois mois. Le référent doit être suffisamment senior pour trancher les conflits de processus entre départements — un middle management ne suffit que rarement.
Pour une vue plus approfondie des schémas d'échec spécifiques à Odoo, voir pourquoi les implémentations Odoo échouent — 7 signaux d'alarme.
Coût et délais d'une migration ERP
Fourchettes réalistes par profil d'entreprise, basées sur 100+ migrations Octura :
- PME mono-entité (5–25 utilisateurs) : 20 000 $ – 60 000 $, 8 à 12 semaines. Typique : migration QuickBooks → Odoo.
- Mid-market mono-entité (25–100 utilisateurs) : 50 000 $ – 150 000 $, 12 à 20 semaines. Typique : NetSuite → Odoo ou SAP B1 → Odoo.
- Multi-entités (3–10 entités) : 100 000 $ – 300 000 $, 16 à 24 semaines. Vagues phasées, jamais big-bang.
- Entreprise (10+ entités, multipays) : 300 000 $ – 800 000 $+, 9 à 18 mois. Déploiement par usine ou par entité.
Ressources dédiées à la migration que nous publions :