Guide de migration des donnees ERP
La migration des donnees est le chantier le plus systematiquement sous-estime des projets ERP. Si la fiche du glossaire consacree a la migration des donnees en pose les fondements conceptuels, ce guide se concentre sur l'execution concrete : decisions de perimetre, choix methodologiques, outillage, pieges frequents et la discipline qui distingue les migrations reussies des migrations chaotiques. Pour les projets de PME et d'ETI, les schemas decrits ici refletent l'experience accumulee sur des dizaines d'implementations du mid-market.
Decisions de perimetre
Trois decisions de perimetre fondamentales structurent la migration. (1) Quelles donnees de base migrer : clients, fournisseurs, articles, BOM, immobilisations, salaries. En general, toutes sont migrees ; la question est la profondeur du nettoyage. Le nettoyage des donnees de base lors de la migration est l'investissement qualite a plus fort effet de levier de tout le cycle de vie de l'ERP. (2) Quel historique de transactions migrer : transactions ouvertes (toujours migrees) ; transactions cloturees (parfois, partiellement, sujet a debat). Le schema pragmatique : transactions ouvertes plus 12 a 24 mois d'historique cloture ; l'historique plus ancien est conserve dans le systeme legacy pour les besoins d'audit. Migrer plus de 5 ans d'historique detaille coute presque toujours plus cher que la valeur qu'il apporte. (3) Quelle configuration migrer : regles tarifaires, workflows de validation, definitions de rapports, formats de sortie. Le plus souvent reconstruite plutot que migree ; l'intention d'une conception greenfield prevaut. Les migrations brownfield preservent davantage de configuration de maniere automatique.
La methodologie ETL en pratique
Le schema Extract-Transform-Load (ETL) structure le travail de migration. Phase d'extraction : extraire les donnees de l'ERP legacy, des tableurs et des systemes operationnels vers une zone de staging. Outils : SAP Data Services, Microsoft SQL Server Integration Services (SSIS), Talend, Pentaho, simples exports Python ou SQL. Les projets modernes utilisent des entrepots de donnees cloud-native (Snowflake, BigQuery, Azure Synapse) comme environnement de staging. Phase de transformation : nettoyage, deduplication, conversion de formats, mappage des codes legacy vers les codes du nouvel ERP. L'effort le plus important a lui seul. Les approches modernes recourent a dbt (data build tool) pour une transformation en SQL avec gestion de versions. Phase de chargement : utiliser les outils d'import de l'ERP cible : SAP Migration Cockpit, Microsoft Configuration Package, Oracle FBDI, NetSuite CSV Import. Validation : controles structurels (nombre de lignes, totaux) plus validation metier (transactions echantillons completes de bout en bout).
Outils de migration specialises
Pour les migrations complexes, des outils specialises accelerent le travail. Migration SAP : SNP CrystalBridge (desormais SNP Glue), Cbs Enterprise Transformer, SAP Data Services, Datavail. Migration Microsoft Dynamics 365 : To-Increase Data Migration, Microsoft Configuration Package, scripts Power Query sur mesure. Migration ERP Oracle Cloud : Oracle Cloud Migration Tools, accelerateurs de migration de donnees developpes par les partenaires. Multi-plateformes : Informatica Intelligent Cloud Services (IICS), Talend Cloud, Apache Airflow (orchestration open source). Transition selective des donnees : SNP CrystalBridge et Cbs Enterprise Transformer prennent en charge le schema bluefield, en migrant des sous-ensembles de donnees selectionnes plutot qu'un historique complet. Le choix de l'outil depend des plateformes source et cible et de l'envergure du projet ; les outils specialises sont rentables a l'echelle du haut du mid-market et de l'entreprise.
Les migrations a blanc comme facteur de reussite
Plusieurs migrations a blanc sont non negociables pour les projets serieux. Essai 1 (pipeline technique) : verifier que la chaine technique extract-transform-load fonctionne de bout en bout sur un sous-ensemble de donnees. Identifier les problemes techniques. Essai 2 (donnees completes, validation du nettoyage) : jeu de donnees complet avec un premier passage de nettoyage. Identifier les problemes de qualite des donnees necessitant des regles de nettoyage. Essai 3 (finalisation du nettoyage) : application de regles de nettoyage affinees ; qualite des donnees a un niveau acceptable. Essai 4 (validation des performances) : chronometrage complet dans des conditions proches de la production. Identifier les problemes de timing affectant le week-end de bascule. Essai 5 (repetition generale) : simulation complete de la bascule avec un chronometrage heure par heure. Verification finale avant la mise en production. Chaque essai revele des problemes qui, sinon, surgiraient lors de la bascule reelle. Les entreprises qui tentent une bascule en production avec 0 ou 1 migration a blanc subissent systematiquement des arrets prolonges ou des scenarios de rollback.
Le week-end de bascule
Le week-end de bascule (ou une fenetre de bascule plus longue pour les migrations complexes) concentre des activites a haut risque. Activites standard du runbook : (1) Gel des donnees legacy le vendredi en fin de journee. Plus aucune saisie de donnees jusqu'a la mise en service du nouvel ERP. (2) Extractions finales du systeme legacy. (3) Execution de la transformation. (4) Chargement dans l'ERP cible. (5) Validation par controles structurels plus validation metier. (6) Decision go/no-go : criteres de decision definis ; plan de rollback clair si la decision est non. (7) Ouverture en production avec des utilisateurs cles selectionnes pour les operations du premier jour. (8) Ouverture complete le lundi matin avec un support hyper-care. Duree typique : 24 a 72 heures pour le mid-market ; jusqu'a 5 jours pour l'entreprise. Operations en war-room dediee avec toutes les parties prenantes disponibles tout au long.
Estimations d'effort realistes
Pour les projets de PME et d'ETI. Petit (20-50 utilisateurs) : 30 a 100 jours-homme, cout de migration des donnees de 60 000 a 250 000 EUR. Mid-market (50-200 utilisateurs) : 100 a 300 jours-homme, cout de migration des donnees de 250 000 a 800 000 EUR. Haut du mid-market (200-500 utilisateurs) : 300 a 800 jours-homme, cout de migration des donnees de 800 000 a 2 500 000 EUR. Entreprise : plus de 1 000 jours-homme, cout de plusieurs millions d'EUR. La migration des donnees represente generalement 10 a 25 % du cout total d'implementation ; les migrations multi-sources complexes peuvent atteindre 30 a 40 %. Les entreprises qui sous-budgetent la migration des donnees depassent systematiquement le budget total du projet ERP.