Migration CRM : méthode, outils et checklist pour changer de CRM sans perdre ses données

La plupart des guides sur la migration CRM résument la démarche en sept étapes illustrées d'un beau schéma en cascade. La réalité est moins linéaire. Une migration CRM bien conduite touche simultanément trois dimensions : les données, les processus et les intégrations. Rater l'une des trois, et la migration est techniquement réussie mais opérationnellement un désastre.

Ce qu'une migration CRM change vraiment

Changer de CRM ne revient pas à déplacer des lignes d'une base vers une autre. Les données CRM sont relationnelles : un contact appartient à un compte, une opportunité est liée à un contact et à un cycle de vente, une activité est rattachée à plusieurs objets à la fois. Briser ces relations — même partiellement — produit des données orphelines, des historiques incomplets et des tableaux de bord faux dès le premier jour.

Les trois stratégies de migration

Il n'existe pas une seule façon de migrer. Le choix de la stratégie dépend du volume de données, de la tolérance à l'interruption de service et de la complexité des intégrations en place.

• Big Bang : l'ancien CRM est arrêté, toutes les données sont migrées en une fois, le nouveau CRM est activé immédiatement. Simple à orchestrer, risqué si un problème survient en cours de bascule. Adapté aux projets de taille modeste ou lorsque la coupure est planifiable sur un week-end.
• Migration progressive : les données sont migrées par lot — par équipe, par pays, par business unit ou par type d'objet. Exemple classique : comptes et contacts en semaine 1, opportunités en cours en semaine 2, historique des activités en semaine 3. Réduit le risque mais allonge la période de transition.
• Coexistence temporaire : les deux systèmes fonctionnent en parallèle pendant quelques jours ou semaines, avec synchronisation bidirectionnelle des modifications. Stratégie la plus complexe techniquement, mais elle élimine presque toute interruption de service — indispensable pour les équipes en contact client permanent.

Les étapes réelles d'une migration

• Audit du CRM source : inventaire de tous les objets, champs personnalisés, workflows, intégrations actives et données mortes (contacts non mis à jour depuis plus de 24 mois, doublons évidents, champs vides à plus de 70 %).
• Nettoyage et déduplication : ne jamais migrer de la dette de données. Un contact dupliqué dans l'ancien CRM sera un doublon dans le nouveau. Utiliser des règles de déduplication sur l'email et le couple prénom/nom/entreprise avant tout export.
• Data mapping et data dictionary : construire la correspondance entre chaque champ source et chaque champ cible. Documenter les règles de transformation.
• Migration pilote sur un jeu de données réduit : migrer 5 à 10 % des données en production ou en sandbox. Vérifier l'intégrité des relations, la cohérence des valeurs transformées et l'absence d'erreurs d'import.
• Migration complète : exécuter la migration en suivant l'ordre de dépendance des objets (comptes avant contacts, contacts avant opportunités).
• Réconciliation : vérifier non seulement que le nombre de lignes correspond mais que les relations, les propriétaires, les statuts et les montants sont cohérents.
• Adoption : former les utilisateurs sur le nouveau CRM, communiquer la date de coupure de l'ancien système, prévoir une période de support intensive les deux premières semaines.

Le data dictionary : l'outil que la plupart des projets négligent

Le data dictionary est une feuille de correspondance qui documente, pour chaque champ source : son nom, son type, sa règle de transformation et le champ cible correspondant. Sans lui, les règles de transformation vivent dans la tête de l'intégrateur — et disparaissent avec lui si le projet s'étire dans le temps.

• company_name → aucune transformation → Company Name
• phone → normalisation au format E.164 (+33 6 XX XX XX XX) → Phone
• country → code ISO (FR) → libellé complet (France) → Country
• account_manager → correspondance email utilisateur ancien/nouveau CRM → Owner
• legacy_customer_id → aucune transformation → External ID (champ personnalisé)

Source of Truth et réconciliation

Lorsqu'une même information existe dans plusieurs systèmes — adresse dans l'ERP, téléphone dans le CRM, email dans le marketing automation — il faut décider avant la migration lequel fait foi. Cette décision s'appelle la Source of Truth. Exemple typique : l'ERP détient l'adresse de facturation officielle, le CRM détient les coordonnées commerciales opérationnelles. En cas de conflit, l'ERP prime sur l'adresse, le CRM prime sur le téléphone.

La réconciliation, elle, intervient après la migration. Elle ne consiste pas seulement à vérifier que le nombre total de lignes importées correspond au nombre de lignes exportées. Elle vérifie : le nombre de comptes source égale le nombre de comptes cibles, chaque contact est rattaché à un compte, chaque opportunité est associée à un contact et à un stage, les propriétaires sont correctement assignés, les montants et les dates sont cohérents.

Checklist migration CRM

• ☐ Inventaire complet des objets et champs (incluant les champs personnalisés)
• ☐ Identification et suppression ou archivage des données mortes
• ☐ Déduplication sur email, téléphone et couple nom/entreprise
• ☐ Data dictionary validé par les équipes métier
• ☐ Source of Truth documentée pour chaque type de donnée en conflit
• ☐ Ordre de migration défini (objets parents avant objets enfants)
• ☐ Migration pilote réalisée et réconciliation validée
• ☐ Plan de rollback défini (retour possible vers l'ancien CRM si blocage critique)
• ☐ Date de coupure communiquée aux équipes
• ☐ Formation utilisateurs planifiée avant go-live
• ☐ Support renforcé prévu les 15 premiers jours

Pour aller plus loin sur le choix de la méthode technique (CSV, ETL ou API), consultez notre guide complet : Migration de données CRM — CSV, ETL ou API, quelle méthode choisir ?

Si votre CRM cible est Salesforce, consultez également : Migration Salesforce — Data Import Wizard, Data Loader, Bulk API ou ETL ?