Migrer un CRM on-premise vers Dynamics 365 sans perdre vos données

Une migration CRM se juge sur un seul chiffre : combien de données avez-vous perdu ? Sur un projet de migration d’un Microsoft CRM 2015 on-premise vers Dynamics 365 dans le secteur bancaire, ce chiffre était de 0,28 % — et chacun de ces enregistrements a été identifié, documenté et validé avec le métier avant le go-live.

Voici la méthode qui a permis d’y arriver.

Commencez par la cartographie, pas par l’outil

L’erreur la plus fréquente : ouvrir Azure Data Factory le premier jour. Un pipeline mal ciblé migre très efficacement des données fausses.

Avant d’écrire la moindre ligne, il faut répondre à trois questions avec le métier :

Quelles entités sont réellement utilisées ? Sur un CRM de dix ans, il est courant de découvrir que 30 % des entités personnalisées ne contiennent plus rien de vivant. Ne migrez pas votre dette technique.
Quelles sont les dépendances ? Les comptes avant les contacts, les contacts avant les opportunités. Un graphe de dépendances explicite détermine l’ordre des pipelines.
Qu’est-ce qui est autoritaire ? Si un champ existe dans le CRM et dans un système tiers, décidez maintenant lequel gagne. Pas pendant le week-end de bascule.

Cette phase produit un document de mapping : entité source, entité cible, champ par champ, règle de transformation, propriétaire métier. C’est fastidieux. C’est aussi ce qui fait la différence entre 0,28 % et 8 %.

Azure Data Factory pour l’extraction et le chargement

Une fois le mapping figé, ADF fait le gros du travail. La structure qui fonctionne bien :

Extract : un pipeline par entité source, qui copie vers une zone de staging SQL. Pas de transformation ici — on veut une copie fidèle du source, horodatée, rejouable.
Transform : la logique de nettoyage en SQL, dans le staging. Déduplication, normalisation des formats, résolution des lookups vers les nouveaux GUID.
Load : écriture vers Dataverse.

Le découpage en trois étapes distinctes n’est pas cosmétique. Quand une règle de transformation change à trois jours du go-live — et ça arrivera — vous rejouez le Transform et le Load sans retaper la source pendant six heures.

Gardez le staging en ligne après le go-live. Pendant les semaines qui suivent, chaque question du type « et cette donnée-là, elle vient d’où ? » se répond en une requête SQL.

PowerShell pour ce qu’ADF fait mal

ADF est excellent pour les volumes. Il est pénible pour les opérations fines : recréer une poignée d’enregistrements, corriger un lookup, rejouer un lot précis.

Pour ça, PowerShell avec PsDataverse est bien plus rapide à écrire. Les scripts qui ont le plus servi :

Réconciliation de comptes source/cible avec export des écarts en CSV
Réassignation en masse du propriétaire après import
Suppression ciblée d’un lot raté, par batch id

Un point important : taguez chaque enregistrement migré avec un identifiant de lot et sa clé source. Un champ texte personnalisé suffit. Sans ça, un rollback partiel est impossible et vous rejouez tout.

La réconciliation n’est pas optionnelle

C’est l’étape que les plannings compressent en premier, et c’est une erreur.

Trois niveaux de contrôle, du moins cher au plus cher :

Niveau	Contrôle	Détecte
1	Comptage par entité, source vs cible	Les lots manquants
2	Somme de contrôle sur les champs numériques et dates	Les transformations cassées
3	Échantillon aléatoire validé manuellement par le métier	Les erreurs de mapping

Le niveau 1 est automatisable et se rejoue à chaque itération. Le niveau 3 ne trouve pas grand-chose — mais ce qu’il trouve est en général une erreur de compréhension du métier, le genre d’erreur qui n’apparaît dans aucun log.

Les pièges qui coûtent cher

Les GUID ne survivent pas. Dataverse génère de nouveaux identifiants. Toute logique qui référence un GUID en dur — intégration, rapport, document Word — casse. Inventoriez-les avant, pas après.

Les dates n’ont pas de fuseau. CRM 2015 on-premise stocke souvent en heure locale serveur ; Dataverse travaille en UTC. Une conversion oubliée décale toute une base d’une ou deux heures. C’est silencieux, et personne ne le voit avant le premier rapport mensuel.

Les champs calculés se recalculent. Si votre source contient une valeur historique figée dans un champ qui, à la cible, est calculé, Dataverse l’écrasera. Migrez vers un champ simple ou acceptez de perdre l’historique.

Les plugins se déclenchent à l’import. Sauf désactivation explicite, chaque création déclenche vos plugins, workflows et flux Power Automate. Sur 400 000 enregistrements, ça veut dire 400 000 e-mails de notification. Désactivez, importez, réactivez, et testez que la réactivation a bien fonctionné.

Ce qu’il faut retenir

Une migration réussie est ennuyeuse. Pas de héroïsme le week-end du go-live, pas de correctifs improvisés à 3 h du matin. Elle est ennuyeuse parce que le travail difficile — la cartographie, les règles de transformation, la réconciliation — a été fait des semaines avant, dans un tableur que personne n’a envie de lire.

C’est là que se gagnent les 0,28 %.