01 Une migration de données ERP, c'est quoi exactement ?
Une migration de données ERP consiste à transférer les données d'un système de gestion vers un autre : d'un ERP historique vers S/4HANA, d'un legacy maison vers IFS, ou de plusieurs instances fusionnées vers une seule. Mais la définition honnête est plus exigeante. Il s'agit de reconstruire un patrimoine de données dans un modèle qui ne l'attend pas.
Il faut distinguer deux chantiers que les plannings confondent souvent. La migration de système (installer, paramétrer, former) est portée par l'intégrateur. La migration de données (extraire, transformer, qualifier, charger) est un métier à part entière. C'est presque toujours elle qui fait dérailler le projet, et presque jamais elle qui reçoit l'attention en premier.
La raison est structurelle : le système cible est neuf et documenté, alors que vos données ont vingt ans d'histoire et ne le sont pas. Les migrations échouent à cause des données sources, pas de l'outil d'arrivée.
Vous migrez un référentiel technique (Windchill, 3DEXPERIENCE, Teamcenter) plutôt qu'un système de gestion ? Les structures produit obéissent à d'autres règles : voir le guide de la migration de données PLM.
02 Le maillon qui décide du succès du projet
Les chiffres sont connus et se répètent : Gifi et ses quelque 117 millions d'euros de manque à gagner, Revlon incapable d'honorer 64 millions de dollars de commandes, Hershey's qui manque Halloween, Haribo qui perd 25 % des ventes de ses oursons. Le vrai prix d'une migration ratée se compte en dizaines de millions. Et aucune de ces entreprises ne manquait de moyens.
Ce qui leur manquait : la maîtrise de leurs données et de leur exécution. Une donnée fausse dans l'ancien système est un désagrément. La même donnée fausse, chargée dans un ERP neuf qui pilote la production, les stocks et la facturation, devient un incident d'exploitation. La migration est le moment où la dette de données devient exigible.
03 Quelles données migrer, et lesquelles laisser derrière
Tout migrer est une erreur aussi coûteuse que de migrer trop peu. Le périmètre se décide par catégorie :
- Les données de référence (articles, nomenclatures, clients, fournisseurs, plan comptable) : le cœur du chantier. Elles doivent être qualifiées, dédoublonnées et conformées au modèle cible. C'est là que se joue la qualité du futur système ;
- Les données transactionnelles ouvertes (commandes en cours, stocks, encours de production, écritures non soldées) : indispensables à la continuité d'activité, et les plus sensibles au timing de la bascule ;
- L'historique : la tentation est de tout embarquer « au cas où ». Dans la plupart des cas, un archivage consultable coûte dix fois moins cher que la migration. Et un historique non qualifié pollue le système neuf dès le premier jour.
04 Tout commence par l'audit des données réelles
Avant d'arbitrer quoi que ce soit, il faut savoir ce qui existe vraiment : volumétries effectives, doublons, objets orphelins, référentiels divergents, exceptions accumulées. L'audit de données est la phase qu'on néglige toujours, et c'est pourtant celle qui conditionne toutes les autres.
Un audit sérieux extrait et profile l'intégralité des données sources, pas un échantillon de confort. Son livrable est une cartographie chiffrée du risque : ce qui passe tel quel, ce qui demande une règle, ce qui exige un arbitrage métier. Sans lui, le planning du projet repose sur des hypothèses. Or les hypothèses sont exactement ce qui fait échouer les migrations.
05 Big bang, phasé, fil de l'eau : choisir son approche
La bascule big bang, où tout est migré en un week-end, est la plus simple à planifier et la plus dangereuse à exécuter : aucune marge de correction une fois le système source éteint. Elle n'est raisonnable que si la migration a été éprouvée à volumétrie réelle, plusieurs fois, avant le jour J.
La bascule phasée, par site, par domaine ou par famille de données, réduit le risque unitaire. En contrepartie, il faut faire vivre deux systèmes en parallèle, avec des synchronisations temporaires qui ont leur propre coût.
Le choix de l'approche est moins déterminant que la nature de l'outillage. Des scripts ponctuels écrits pour « le jour J » ne survivent ni aux itérations ni aux exceptions. Une chaîne de migration asynchrone, où chaque enregistrement avance, échoue et se rejoue individuellement, transforme la migration en système répétable, quelle que soit la stratégie de bascule retenue.
06 Les cinq phases d'une migration maîtrisée
Notre méthodologie complète détaille chaque phase ; en résumé :
- 01 · Audit : mesurer le périmètre réel, les volumétries, les anomalies. La réalité avant les hypothèses ;
- 02 · Build : construire une chaîne configurable, traçable et répétable. Un système industriel, pas des scripts ;
- 03 · Run / Fix : exécuter sur des périmètres réels, corriger chaque écart, boucler jusqu'à stabilisation ;
- 04 · Dry Run : la répétition générale, à volumétrie réelle, sur la chaîne complète ;
- 05 · Go-Live : la bascule intervient quand tout a déjà été prouvé. Une étape contrôlée, pas un pari.
07 Les pièges qui coûtent le plus cher
Cinq erreurs reviennent dans la quasi-totalité des post-mortems :
- Valider sur des échantillons. Cinq cents enregistrements propres passent la recette ; les deux millions réels, jamais testés, la font exploser en production ;
- Confondre donnée valide et donnée qualifiée. Une donnée correcte dans l'ancien système peut violer le modèle cible. S/4HANA en est l'exemple type : MATDOC, ACDOCA et le journal universel ne pardonnent pas les reprises non conformées ;
- Faire confiance aux outils natifs. Les passerelles standard déplacent des enregistrements, pas des structures. Le cas Windchill vers 3DEXPERIENCE le montre : liens, nomenclatures et cycles de vie doivent être reconstruits, pas copiés ;
- Découvrir les volumétries au chargement. Les estimations de début de projet sont systématiquement sous-évaluées ; seule la mesure protège ;
- Geler le code trop tôt, les données trop tard. Les données vivent jusqu'au jour de la bascule : la chaîne doit absorber les deltas, pas les subir.
08 Combien ça coûte, et combien ça évite
Une expertise migration dédiée se situe entre 200 000 € et 1 million d'euros selon le périmètre. Un fiasco documenté se chiffre en dizaines de millions : l'expertise représente moins de 1 % du coût d'un échec. C'est le ratio d'une prime d'assurance, à la différence près qu'ici l'assurance empêche le sinistre au lieu de le rembourser.
La durée suit la même logique : de quelques mois à plus d'un an selon la volumétrie et la qualité des sources. C'est l'audit qui rend l'estimation fiable. Les réponses aux questions les plus fréquentes sont sur la page méthodologie.