SAP Sales Cloud V2 Data Transfer Tool : le guide de migration pas à pas

Le Data Transfer Tool (DTT) de SAP transfère les données métier et la configuration de SAP Cloud for Customer (C4C, « V1 ») vers SAP Sales Cloud et Service Cloud Version 2. C’est un outil de SAP, pris en charge par SAP, et il s’améliore presque à chaque version trimestrielle. Ce que la documentation ne peut pas vous donner, c’est le projet qui l’entoure : l’ordre des travaux, la préparation, les cycles de test et les décisions que personne ne prendra à votre place.

Ce guide décrit ce projet. Il suit la séquence que nous utilisons dans les projets V1 vers V2 : Readiness Check, nettoyage, préparation de V2, transferts de test, bascule en production et validation. Lorsqu’une affirmation décrit l’outil de SAP, elle renvoie à la documentation SAP. Lorsqu’elle décrit notre planification, elle le précise.

En bref : le DTT s’exécute dans votre tenant V1 (centre de travail Transition) et SAP l’active sur demande. Lancez d’abord le Readiness Check, nettoyez V1 (le DTT ne filtre pas les enregistrements) et préparez un tenant V2 vide avec la configuration requise par chaque objet. Ensuite, au moins deux transferts de test complets, la bascule dans une fenêtre de gel planifiée et le mode delta pour combler l’écart. Le DTT prend en charge les données ; la logique spécifique, les intégrations, les extensions d’interface et les rapports sont reconstruits dans V2. Dans notre planification, le volet données d’un tenant de taille moyenne prend généralement de 8 à 14 semaines.

Qu’est-ce que le Data Transfer Tool (DTT) ?

Le DTT est la partie transfert des outils que SAP fournit pour passer de V1 à V2. L’autre partie est le Readiness Check Tool (RCT), qui analyse votre tenant V1 avant tout transfert. Les deux se trouvent dans le centre de travail Transition du système V1 (SAP Help : Data Transfer Tool ; SAP Help : Readiness Check Tool).

Le DTT transfère les données objet par objet. Pour chaque objet pris en charge, SAP fournit un modèle avec le mappage des champs, la logique de transformation et la validation du chargement. L’outil gère aussi l’ordre entre objets dépendants et produit des journaux et des messages d’erreur exploitables.

Le périmètre n’a cessé de s’élargir. Quelques nouveautés annoncées par SAP dans ses présentations de version :

• 2508 (août 2025) : transfert de test avec « Data Only » par défaut, un historique des transferts (Transfer History) pour le suivi, de nouveaux objets comme Territories et Competitor Products, et la prise en charge des notes, des identifiants externes de groupes de produits et d’autres champs d’extension.
• 2511 (novembre 2025) : le chargement de la configuration métier peut être séparé du transfert des données, de nouveaux contrôles de prérequis (par exemple les services inclus dans le périmètre de V2) et des messages d’erreur plus détaillés (SAP Community : présentation de la version 2511).
• 2602 (février 2026) : visites, planification des tournées et hiérarchie des comptes comme objets transférables ; le transfert des données des champs PDI passe de la bêta à la disponibilité générale (SAP Community : présentation préalable de la version 2602).
• 2605 (mai 2026) : un récapitulatif des volumes pour les structures organisationnelles, le transfert des champs d’extension key user sur les relations entre partenaires commerciaux et les mappages de listes de codes dans « Transfer All BC » (SAP Community : présentation préalable de la version 2605).

Comme la liste évolue chaque trimestre, vérifiez la liste des objets sur la page d’aide SAP au début de votre projet, et non dans un article de blog (celui-ci compris).

Ce que le DTT couvre en général : comptes, contacts, clients particuliers, leads, opportunités, activités (rendez-vous, tâches, appels), tickets, produits et données de base associées, territoires, structures organisationnelles, notes et pièces jointes, ainsi que les champs d’extension lorsque le mappage est complet.

Ce que le DTT ne couvre pas :

• La logique spécifique développée avec le SDK de V1 (scripts PDI/ABSL, objets métier spécifiques dotés de leur propre comportement)
• Les règles de workflow et les notifications
• Les scénarios d’intégration avec l’ERP et les systèmes tiers
• Les adaptations d’interface et les mashups
• Les rapports et tableaux de bord
• Les paramètres personnels et les modèles de courriel

Cette répartition définit le projet. Le DTT transfère les données. Tout le reste est reconstruit dans l’architecture de V2. Pour l’aspect stratégique de cette décision, lisez notre article sur la stratégie de migration de C4C vers V2 et notre évaluation des limites actuelles de V2. Pour une première étape à prix fixe, notre évaluation de préparation à la migration de V1 vers V2 examine votre paysage en 3 jours pour CHF 7’500, déduits de la mise en œuvre V2.

Prérequis avant de commencer

Accès et tenants

• Demandez le DTT à SAP. SAP active l’outil client par client. Ouvrez un incident sur le composant LOD-LE-MIG-CNS en indiquant l’URL de votre tenant V2.
• Attribuez le centre de travail Transition. Dans V1, ajoutez le centre de travail Transition au rôle métier des administrateurs qui exécuteront le Readiness Check et le transfert.
• Provisionnez le tenant V2 tôt. Selon SAP, le tenant V2 cible doit être vide, sans données métier. Ne laissez personne « faire des essais » dans le tenant que vous allez charger. Pour les prototypes, utilisez un tenant distinct.
• Vérifiez les prérequis de chaque objet. Certaines configurations doivent exister dans V2 avant le transfert, par exemple les types de cas pour les tickets. SAP les documente objet par objet : lisez ces pages pendant la planification, pas au premier test.

Lancez d’abord le Readiness Check

Le Readiness Check Tool analyse votre tenant V1. Il montre les objets standard que vous utilisez, les volumes de données par objet, les champs spécifiques, les solutions PDI, les mashups et composants intégrés, ainsi que les éléments que SAP classe comme bloquants pour la transition. Les versions récentes ont ajouté le volume des pièces jointes par objet et la liste des add-ons installés.

Chez nous, tout projet V1 vers V2 commence par le Readiness Check. C’est la première réponse factuelle à la question : quelle part de notre système sera transférée automatiquement, et quelle part devons-nous reconstruire ?

Nettoyez V1 avant le transfert

Le DTT ne permet pas de sélectionner un sous-ensemble d’enregistrements par objet. Ce qui se trouve dans V1 est transféré. Le nettoyage doit donc se faire dans V1 :

• Doublons. Fusionnez les comptes et contacts en double dans V1. V2 dispose d’un contrôle des doublons configurable, mais il est conçu pour les nouveaux enregistrements, pas pour trier des milliers d’enregistrements migrés.
• Enregistrements orphelins. Contacts sans compte, activités sans enregistrement parent, opportunités liées à des produits abandonnés. Corrigez-les ou archivez-les.
• Champs spécifiques obsolètes. Un champ que personne ne remplit depuis deux ans n’a pas besoin d’un champ d’extension dans V2. Chaque champ du périmètre exige un mappage et un test.
• Utilisateurs partis. Réattribuez les enregistrements des collaborateurs qui ont quitté l’entreprise avant le transfert, pas après.

C’est aussi le moment de définir ce que signifient des « données de qualité » pour votre système V2. Notre article sur la qualité des données CRM comme socle de l’IA présente les règles que nous appliquons.

Étape 1 : lire correctement le Readiness Check

Ouvrez le Readiness Check dans le centre de travail Transition de V1 et exécutez-le sur votre tenant de production. Parcourez ensuite les résultats par catégorie :

Objets standard et volumes. Quels objets sont utilisés et combien d’enregistrements chacun contient-il ? Le volume détermine la durée des exécutions de test et de production.

Extensions propres au client. Champs spécifiques, solutions PDI, mashups et composants intégrés. Cette liste constitue le backlog de vos volets de reconstruction : certains éléments deviennent des champs d’extension dans V2, d’autres des extensions side-by-side sur SAP Business AI Platform (BAIP, anciennement BTP), d’autres sont abandonnés.

Bloquants pour la transition. Les éléments qui empêchent un transfert automatique. Chacun a besoin d’un responsable et d’une décision.

Transformez le résultat en plan de migration : chaque objet du périmètre, ses prérequis dans V2, l’état de son mappage et la personne qui valide le résultat. Ce document est votre plan pour les semaines suivantes.

Étape 2 : préparer le tenant V2

Le DTT transfère des enregistrements. Il ne conçoit pas votre système V2.

Organisation et utilisateurs

• Structure organisationnelle. Organisations commerciales et de service, unités et territoires. V2 possède son propre modèle : traitez cette étape comme une conception, pas comme une copie.
• Utilisateurs et rôles. Créez les utilisateurs et les rôles métier dans V2 afin que la responsabilité des enregistrements puisse être attribuée lors du transfert.
• Configuration métier. Cycles et phases de vente, codes de statut et de motif, catégories de produits et les autres paramètres auxquels les données transférées font référence. Depuis la version 2511, configuration et données peuvent être chargées séparément, ce qui permet de finaliser d’abord la configuration.

Champs d’extension et listes de codes

Les champs spécifiques de V1 ont besoin d’une cible dans V2, où ils sont créés comme champs d’extension via l’extensibilité key user. Pour chaque champ du périmètre :

1. Créez le champ d’extension dans V2 avec un type de données correspondant
2. Pour les champs à liste de codes, assurez-vous que chaque valeur utilisée dans V1 existe dans V2 ou est mappée
3. Consignez le champ V1 et la cible V2 dans le document de mappage
4. Testez-le lors du premier transfert

Les mappages incomplets sont la cause la plus fréquente d’enregistrements rejetés lors des tests. Les champs d’extension, les notes et les pièces jointes ne sont transférés que si le mappage de l’objet métier est complet.

Pour un aperçu de ce que V2 offre en standard, consultez notre page consacrée à SAP Sales Cloud V2.

Étape 3 : configurer le transfert

Dans le centre de travail Transition, le DTT liste les objets transférables. Commencez par les données de base, puis passez aux données transactionnelles. Le DTT gère lui-même l’ordre entre objets dépendants, mais il faut connaître les dépendances pour lire les journaux :

1. Structure organisationnelle, territoires, produits
2. Comptes et clients particuliers
3. Contacts et relations
4. Leads
5. Opportunités
6. Activités (rendez-vous, tâches, appels, visites)
7. Tickets

Si les opportunités échouent, la cause se situe souvent un niveau plus haut : un compte non transféré, un produit absent de V2 ou une valeur manquante dans une liste de codes.

Passez en revue les modèles de mappage fournis, objet par objet. SAP a mappé les champs standard. Votre travail porte sur la partie spécifique : champs d’extension, valeurs des listes de codes et champs dont le sens a évolué au fil des années d’utilisation de V1. Un champ « Catégorie » peut signifier trois choses différentes dans trois unités commerciales.

Étape 4 : effectuer les transferts de test

N’exécutez jamais le transfert de production sans au moins un, idéalement deux, tests complets.

Comment tester

1. Utilisez un tenant V2 de test vide et préparé exactement comme la production. Ne testez jamais dans le tenant avec lequel vous passerez en production.
2. Transférez tout le périmètre. Tous les objets, tous les champs d’extension. Un test partiel ne révèle pas les problèmes de références entre objets.
3. Utilisez les volumes de production. Un petit échantillon masque les problèmes qui n’apparaissent qu’à grande échelle : durées d’exécution longues, pièces jointes volumineuses, valeurs rares dans les listes de codes.
4. Mesurez la durée par objet. Ces chiffres définissent votre fenêtre de bascule.

Que vérifier après chaque exécution

Volumes. Comparez le nombre d’enregistrements par objet dans V1 et dans V2. L’historique des transferts et les récapitulatifs de volumes aident ; pour les objets importants, comptez aussi de manière indépendante.

Objet	V1	V2	Écart	Action
Comptes	12’450	12’450	0	OK
Contacts	34’200	34’187	-13	Vérifier le journal
Opportunités	8’930	8’930	0	OK
Activités	156’000	155’842	-158	Vérifier le journal

Exemple illustratif, pas de données client.

Relations. Contrôlez par sondage 50 à 100 enregistrements répartis sur les objets : les contacts sont-ils liés aux bons comptes, les opportunités affichent-elles les bons produits et les bonnes phases, les activités sont-elles rattachées au bon enregistrement parent, les valeurs des champs d’extension sont-elles arrivées ?

Journal des erreurs. Classez chaque erreur : bloquante, perte de données ou cosmétique. Les erreurs bloquantes et les pertes de données sont corrigées avant l’exécution suivante.

Catégories d’erreurs typiques

Catégorie	Cause typique	Que faire
Référence manquante	Un enregistrement parent (compte, produit) n’a pas été transféré ou n’existe pas dans V2	Corriger d’abord l’objet parent, puis retransférer l’objet dépendant
Valeur de liste inconnue	Une valeur V1 n’a pas d’équivalent dans V2	Ajouter la valeur dans V2 ou la mapper sur une valeur existante
Champ obligatoire vide	V2 exige une valeur qui n’a jamais existé dans V1	Définir une valeur par défaut dans le mappage ou renseigner le champ dans V1 avant le transfert
Champ d’extension non transféré	Mappage de l’objet métier incomplet	Compléter le mappage et retransférer l’objet
Configuration V2 manquante	Prérequis non créé (par exemple les types de cas)	Créer la configuration dans V2 ; les contrôles de prérequis introduits avec la version 2511 en signalent beaucoup
Doublons	V1 contient plusieurs fois le même client	Fusionner dans V1 avant l’exécution suivante
Pièces jointes volumineuses	Les fichiers dépassent les limites de taille ou ralentissent l’exécution	Vérifier les volumes de pièces jointes dans le Readiness Check ; archiver ou transférer séparément les très gros fichiers

Les messages exacts figurent dans le journal du DTT ; depuis la version 2511, SAP indique le type d’erreur de manière plus détaillée. Prévoyez deux à trois cycles de test. Chaque cycle devrait produire moins d’erreurs. Si les chiffres ne baissent pas, un problème de fond existe : le plus souvent dans le mappage ou dans la qualité des données de V1.

Étape 5 : exécuter le transfert de production

À ce stade, le processus ne devrait plus réserver de surprises. L’exécution en production reproduit ce que les tests ont démontré.

Calendrier

Choisissez une fenêtre calme. Le transfert sollicite les deux systèmes. Pour les entreprises en Suisse et en Allemagne, le week-end est le choix habituel.

Gelez V1. Annoncez au moins une semaine à l’avance un gel des modifications dans V1. Ce qui est modifié dans V1 après l’instantané doit être repris par le mode delta, sinon il est perdu.

Planifiez la durée avec une marge. Reprenez la durée du dernier test et ajoutez 20 à 30 %. Les volumes de production sont plus élevés et les systèmes subissent une charge différente.

Suivre l’exécution

Désignez une personne qui suit le transfert en continu, à l’aide de l’historique des transferts et des journaux. Si un objet présente un nombre inhabituel d’erreurs, arrêtez et analysez. Un problème détecté en cours d’exécution coûte moins cher qu’un transfert terminé mais défectueux.

Points de contrôle pour les grands tenants

Pour les tenants de plus d’un million d’enregistrements, découpez l’exécution en phases et validez après chacune :

1. Données de base : structure organisationnelle, produits, comptes, contacts
2. Documents de vente : leads et opportunités
3. Activités et tickets : les plus gros volumes
4. Pièces jointes : la partie la plus lente

Prévoir le repli

Le DTT lit dans V1 et ne modifie pas la source. Si le transfert de production échoue, V1 reste intact et les utilisateurs continuent d’y travailler. Comme V2 doit être vide avant le transfert, un redémarrage implique de nettoyer le tenant V2. Convenez à l’avance avec SAP du déroulement d’une réinitialisation et intégrez ce délai dans votre plan. Gardez V1 disponible jusqu’à ce que V2 soit validé et réceptionné.

Étape 6 : valider après la bascule

Volumes et delta

Répétez la comparaison des volumes sur les données de production. Tout nouvel écart signale des enregistrements créés ou modifiés entre le dernier test et le gel. Lancez le transfert delta pour ces objets.

Relations métier

• Les hiérarchies de comptes sont complètes
• Les contacts sont rattachés aux bons comptes
• Pipeline : phases, montants attendus, dates de clôture et produits sont corrects
• L’historique des activités apparaît dans le bon ordre sur le bon enregistrement
• Les champs d’extension contiennent les bonnes valeurs (contrôlez par sondage au moins 100 enregistrements par champ important)

Réception par les métiers

Avant de déclarer le succès, faites vérifier leurs propres données par les utilisateurs :

• Direction commerciale : vue du pipeline, nombre et valeur des opportunités
• Responsables de comptes : leurs dix comptes les plus importants
• Agents de service : tickets récents et historique client
• Administrateurs : territoires, rôles et affectations
• Reporting : indicateurs comparés à V1

Prévoyez trois à cinq jours ouvrés. Un utilisateur qui découvre des données manquantes trois mois plus tard coûte bien plus cher qu’une semaine de vérification supplémentaire maintenant.

Ce que le projet doit reconstruire

Les données sont la partie prise en charge par le DTT. Le reste doit figurer dans le plan de projet et le budget :

Logique spécifique. Les extensions V1 développées avec SAP Cloud Applications Studio (PDI, ABSL) ne fonctionnent pas dans V2. La logique est reconstruite avec les outils key user de V2 (règles, validations, déterminations) ou comme extension side-by-side sur SAP BAIP. C’est généralement le poste le plus important.

Workflows et notifications. Ils sont reconstruits dans V2. De nombreux scripts V1 deviennent de la configuration.

Intégrations. Accords de communication, intégration ERP, connexions marketing et tierces sont reconfigurés pour V2. Pour l’intégration avec S/4HANA, SAP fournit des contenus d’intégration standard sur le SAP Business Accelerator Hub. Notre article sur l’architecture d’intégration entre Sales Cloud V2 et S/4HANA Public Cloud montre comment nous la mettons en place. La téléphonie est un sujet à part, traité dans notre guide d’intégration CTI.

Adaptations d’interface et mashups. Ils sont reconstruits avec les outils d’adaptation et les mashups de V2.

Rapports et tableaux de bord. Ils sont reconstruits dans l’analytique de V2 ou dans SAP Analytics Cloud. C’est le bon moment pour supprimer les rapports que personne n’ouvre.

Modèles de courriel. Ils sont recréés dans V2 ; la syntaxe des variables est différente.

Dans nos projets, le transfert des données représente la plus petite part de l’effort. L’essentiel du travail se trouve dans les points ci-dessus. Pour le cadre budgétaire, consultez notre guide des prix et coûts de SAP Sales Cloud V2.

Combien de temps dure le volet DTT ?

Voici les fourchettes avec lesquelles nous planifions le seul volet données. Ce ne sont pas des chiffres de SAP, et elles dépendent fortement de la qualité des données et du nombre de champs d’extension.

Phase	Petit (25 à 50 utilisateurs)	Moyen (100 à 200 utilisateurs)	Grand (plus de 500 utilisateurs)
Readiness Check et nettoyage de V1	1 à 2 semaines	2 à 4 semaines	4 à 6 semaines
Préparation de V2 et mappage	2 à 3 semaines	3 à 5 semaines	5 à 8 semaines
Configuration du transfert	1 semaine	1 à 2 semaines	2 à 3 semaines
Transferts de test	1 à 2 semaines	2 à 3 semaines	3 à 4 semaines
Bascule en production	1 week-end	1 week-end	1 à 2 week-ends
Validation	1 semaine	1 à 2 semaines	2 à 3 semaines
Durée totale	6 à 9 semaines	8 à 14 semaines	14 à 24 semaines

Les phases se chevauchent, c’est pourquoi la durée totale est inférieure à la somme. Le projet V1 vers V2 dans son ensemble (reconstruction de la logique et des intégrations, formation, mise en production) avance en parallèle et dure généralement plus longtemps. Pour une vue d’ensemble, consultez notre comparatif de la migration de V1 vers V2 ou essayez l’assistant V1 vers V2.

Tableau de planification pour un tenant de taille moyenne

Semaine	Activité	Dépend de	Résultat
1 à 2	Demander le DTT, lancer le Readiness Check	Accès administrateur V1	Rapport et liste d’actions
2 à 4	Nettoyer V1	Liste d’actions	Données V1 nettoyées
3 à 6	Préparer le tenant V2	V2 provisionné	V2 configuré et vide
4 à 6	Champs d’extension et mappage	Configuration V2	Document de mappage
5 à 7	Configurer le transfert	Document de mappage	Transfert prêt
6 à 8	Transfert de test 1	Transfert prêt	Liste d’erreurs et corrections
8 à 9	Transfert de test 2	Corrections appliquées	Rapport de validation
10	Bascule en production	Tests réussis	Données dans V2
10 à 12	Validation et delta	Bascule terminée	Réception par les métiers

Ajoutez 20 % à chaque estimation. Le nettoyage et le mappage sont les phases qui débordent le plus souvent, car personne ne connaît l’état réel de ses données V1 avant de les examiner. Les équipes sous-estiment volontiers cette phase de moitié, et c’est elle qui donne le rythme de tout le reste.

Questions fréquentes

Où s’exécute le Data Transfer Tool et comment y accéder ?

Le DTT s’exécute dans votre tenant V1, dans le centre de travail Transition. SAP l’active sur demande : ouvrez un incident sur le composant LOD-LE-MIG-CNS avec les informations de votre tenant V2, puis attribuez le centre de travail Transition au rôle des administrateurs dans V1.

Le DTT prend-il en charge la migration delta ?

Oui. Dès qu’un objet a été transféré avec succès, le DTT le fait passer en mode delta. Les exécutions suivantes reprennent les enregistrements créés ou modifiés dans V1 depuis le chargement initial, ce qui permet de combler l’écart entre le dernier test et la bascule. Vérifiez comment votre scénario traite les enregistrements supprimés dans V1 et prévoyez un nettoyage après la bascule.

Puis-je filtrer les enregistrements que le DTT transfère ?

Pas de la manière que la plupart des équipes imaginent. Le DTT transfère les données d’un objet, pas un sous-ensemble filtré. Ce qui ne doit pas arriver dans V2 doit être nettoyé ou archivé dans V1 avant le transfert.

Le DTT fonctionne-t-il pour la migration de Service Cloud V1 vers V2 ?

Oui. Les outils de transition couvrent Sales Cloud et Service Cloud, tickets compris. Certaines configurations de service, comme les types de cas, doivent d’abord être créées manuellement dans V2. Le déroulement est le même : Readiness Check, préparation, transferts de test, bascule.

Puis-je migrer d’un CRM tiers vers V2 avec le DTT ?

Non. Le DTT sert uniquement au passage de V1 à V2. Depuis Salesforce, Dynamics 365 ou d’autres systèmes, on charge les données avec le Data Workbench de V2 (import CSV ou Excel) ou via les API de V2, pour de gros volumes généralement par SAP Integration Suite. Pour les équipes commerciales qui travaillent avec des tableurs, notre guide pour passer d’Excel à Sales Cloud V2 décrit la voie la plus simple.

Comment traiter des objets spécifiques aux relations complexes ?

Les champs spécifiques des objets standard sont transférés par le DTT dès qu’ils sont mappés, et les données des champs PDI sont prises en charge. Les objets métier spécifiques dotés de leur propre logique, de leurs relations et de leur interface sont reconstruits dans V2 ou sur SAP BAIP. Leurs données sont exportées de V1 via l’API OData et chargées dans V2 via ses API. C’est du travail de projet, pas du travail du DTT.

Que devient mon système V1 après la migration ?

Le DTT lit dans V1 et ne modifie pas les données sources. V1 continue de fonctionner jusqu’à sa mise hors service. Définissez la durée d’accès en lecture nécessaire aux utilisateurs et aux auditeurs, et planifiez la fin de l’abonnement V1 comme une étape distincte.

Existe-t-il un volume maximal de données pour le DTT ?

Nous n’avons pas connaissance d’une limite stricte publiée. Le volume détermine la durée : utilisez le Readiness Check pour connaître les enregistrements et le volume des pièces jointes par objet, testez avec les volumes de production et planifiez la fenêtre de bascule à partir des durées mesurées.

---

Une migration de V1 vers V2 est un projet doté d’un volet données, pas un transfert de données assorti de quelques tâches annexes. Le DTT rend la partie données maîtrisable. Le reste dépend de la préparation : des données propres, des mappages complets, de vrais tests et un plan qui décrit honnêtement le travail de reconstruction.

Si vous planifiez une migration avec le DTT et souhaitez un second avis sur votre rapport de Readiness Check, contactez-nous. Nous l’examinerons volontiers avec vous.