Que vérifier dans un export CRM avant de changer d'outil

Listez les fiches et le contexte de travail nécessaires à l'équipe après le changement. Les contacts et entreprises sont évidents, mais les opportunités, tâches, appels, notes, pièces jointes, champs personnalisés et relations peuvent aussi compter. Demandez aux utilisateurs de chaque fiche ce qu'il leur faut pour continuer et consignez le module source et le responsable de chaque élément.

Fixez une date pour l'export et notez les filtres ou vues utilisés. Un fichier créé depuis une vue filtrée ne contient que la partie sélectionnée du système. Gardez l'export original intact et créez une copie de travail distincte pour l'examen.

Ouvrez chaque fichier et vérifiez les en-têtes, le nombre de fiches, l'encodage, les valeurs vides et les identifiants. Comparez quelques lignes au système source pour confirmer que les champs attendus se trouvent dans les bonnes colonnes. Consignez les filtres et propriétés sélectionnés afin qu'une autre personne puisse répéter l'export.

La documentation d'export HubSpot indique que les exports de fiches contiennent les valeurs actuelles des propriétés et les associations. Elle décrit les choix de propriétés et de relations et renvoie à des méthodes distinctes pour les activités de contact comme les appels ou les notes. Les options dépendent de l'objet et du parcours d'export : vérifiez celles du compte que vous quittez.

Un fichier de contacts peut montrer noms et adresses de courriel ; vérifiez que les liens vers les entreprises et opportunités apparaissent aussi. Examinez les identifiants de relation et confirmez que la destination peut les reconstruire. Vérifiez ensuite l'historique des activités, les fichiers et tout autre contexte à rechercher au-delà de l'export principal. La présence d'une note ou d'une pièce jointe nécessite sa propre confirmation dans les fichiers exportés.

Le guide d'import Notion illustre pourquoi il faut vérifier séparément le comportement de la destination : un import CSV crée des lignes et propriétés de base de données, tandis qu'un nouvel import CSV ne peut pas créer de nouvelles relations ni formules. L'importation ou la fusion ajoute des lignes au lieu de mettre à jour les lignes existantes. Ces limites sont propres à Notion, mais montrent qu'une destination peut ne pas reconstruire toutes les relations sources.

Pour chaque champ source important, nommez le champ de destination ou indiquez qu'il n'est pas pris en charge, qu'il sera transformé ou que la décision reste ouverte. Testez si les clés de relation ont des correspondances stables et si le système destinataire peut conserver les mêmes distinctions. Faites examiner cette correspondance par chaque responsable de processus au lieu de compter uniquement sur la personne ayant exporté les fichiers.

Si un champ n'a pas de destination claire, décidez s'il doit être conservé dans une archive, déplacé autrement ou exclu avec une raison consignée. Gardez cette décision visible. Documentez comment la destination interprétera chaque valeur associée afin que l'équipe puisse utiliser les nouvelles fiches.

Dans cet examen fictif, Willow CRM produit un export de 24 contacts et un export de 8 entreprises. Les lignes de contacts contiennent des noms et des courriels actuels et plusieurs incluent une référence d'entreprise. L'équipe ne trouve pas les notes d'appel dans ces deux fichiers. Le registre indique que l'historique des activités nécessite une vérification séparée avant l'approbation de la destination.

L'équipe suit aussi trois identifiants reliant des contacts aux entreprises dans les fichiers et constate qu'un identifiant d'entreprise référencé manque dans l'export des entreprises. Elle consigne ce manque et attribue son examen avant tout essai d'importation. L'exemple fictif présente un constat sans attribuer à un fournisseur une perte de données ni une migration réussie.

L'examen de l'export répond à la question des données et du contexte présents. Une revue des doublons décide si deux fiches désignent la même entité. Un test de migration sur échantillon vérifie le comportement des données importées. Un plan de retour arrière définit comment rétablir le service et recueillir les changements effectués après le basculement. Ces étapes sont liées, mais nécessitent des preuves et décisions différentes.

Utilisez l'inventaire pour décider si un test sur échantillon est prêt. Gardez l'accès à l'ancien système jusqu'à ce que les responsables aient vérifié les exports, relations et comportement de la destination.

Demandez à l'assistant Areinum d'organiser les fichiers et descriptions de champs fournis en un inventaire d'export et une liste des manques à vérifier avec le système destinataire. Gardez l'export original intact pendant l'examen d'une copie de travail.