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

Le Data Transfer Tool de SAP existe pour résoudre un problème précis : déplacer vos données de production de Sales Cloud V1 (C4C) vers Sales Cloud V2. C’est le chemin de migration officiel, supporté par SAP. Et il fonctionne. Mais la documentation semble avoir été écrite pour des personnes qui connaissent déjà l’outil.

Nous avons exécuté des migrations DTT pour plusieurs clients — des équipes commerciales de 50 utilisateurs aux déploiements de plus de 500 utilisateurs avec des objets personnalisés complexes et des intégrations profondes avec S/4HANA. Ce guide couvre ce que la documentation officielle omet : les décisions pratiques, les erreurs que vous rencontrerez, les étapes de validation qui vous évitent un go-live raté, et des calendriers réalistes basés sur des données de projets réels.

TL;DR : Le Data Transfer Tool (DTT) de SAP migre les données de référence et transactionnelles de Sales/Service Cloud V1 vers V2. Exécutez d’abord le Readiness Check Tool (RCT) — il identifie les blocages avant de commencer. DTT gère automatiquement les comptes, contacts, leads, opportunités, activités et tickets ; les objets personnalisés, intégrations et logique workflow doivent être reconstruits manuellement. Une migration typique de taille moyenne (100-200 utilisateurs, 500K-2M enregistrements) prend 8 à 14 semaines au total. Exécutez toujours au moins deux migrations de test complètes avant le basculement en production. SAP a considérablement amélioré le DTT dans les releases 2508 et 2511 (SAP Community, 2025).

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

Le Data Transfer Tool est l’utilitaire intégré de SAP pour transférer les données métier d’un tenant V1 (C4C) vers un tenant V2. Ce n’est pas un module tiers. Il est intégré à la console d’administration V2, et SAP l’a conçu pour gérer les différences structurelles entre les deux modèles de données.

SAP a introduit le DTT parallèlement à la disponibilité générale de V2, puis l’a considérablement amélioré dans la release 2508 (août 2025) et à nouveau dans la 2511 (novembre 2025). La release 2508 a ajouté la prise en charge des custom business objects et une meilleure gestion des erreurs. La release 2511 a étendu la couverture aux activités de courriel, aux notes avec pièces jointes et à une meilleure gestion des références inter-objets (SAP Community, 2025).

Ce que le DTT transfère :

• Comptes (entreprises et clients individuels)
• Contacts et leurs relations avec les comptes
• Leads et qualifications de leads
• Opportunités avec produits, phases de vente et parties prenantes
• Activités (rendez-vous, tâches, appels téléphoniques, courriels)
• Tickets de service et interactions
• Produits et listes de prix
• Territoires de vente et affectations organisationnelles
• Champs personnalisés sur les objets standard
• Pièces jointes et documents (avec limites de taille)

Ce que le DTT ne transfère pas :

• Logique de code personnalisé (scripts ABSL, actions personnalisées)
• Règles workflow et configurations d’escalade
• Configurations d’intégration (communication arrangements, API)
• Personnalisations d’interface (mashups, contenus embarqués, UI personnalisées)
• Rapports et configurations analytics
• Paramètres utilisateur et personnalisation
• Modèles de courriel et champs de fusion

La distinction est fondamentale. DTT transfère les données. Tout le reste — la logique métier, les intégrations, l’interface utilisateur — doit être reconstruit dans l’architecture V2. Pour une vue d’ensemble du projet global, consultez notre stratégie de migration C4C vers V2.

Prérequis : ce qui doit être en place avant de commencer

Avant de toucher au DTT, plusieurs éléments doivent être en ordre. En sauter un seul crée des problèmes en aval qui coûtent plus de temps que la préparation.

Exigences système

• Tenant V2 provisionné et activé. Votre environnement V2 doit être en ligne et accessible. Cela semble évident, mais le provisionnement du tenant peut prendre 2 à 4 semaines via le processus SAP. Commencez tôt.
• Tenant V1 sur une release supportée. DTT exige que votre système V1 soit sur un niveau de patch minimum. Vérifiez la SAP Note 3350732 pour le minimum actuel. Si vous êtes en retard, appliquez le patch d’abord.
• Accès administrateur aux deux tenants. L’utilisateur qui exécute DTT a besoin de droits d’administration complets dans le système source (V1) et cible (V2). Un accès partiel provoque des échecs silencieux.
• Connectivité réseau. Les deux systèmes doivent pouvoir communiquer. Si votre tenant V1 utilise un filtrage d’IP ou des configurations proxy personnalisées, assurez-vous que les plages IP du tenant V2 sont autorisées.

Exécuter d’abord le Readiness Check Tool

Le Readiness Check Tool (RCT) est distinct du DTT mais indissociable du processus. Le RCT analyse votre système V1 et produit un rapport de compatibilité : quels objets sont prêts pour le transfert, lesquels nécessitent une attention particulière et lesquels sont incompatibles.

Pour nous, le RCT est non négociable. Chaque migration DTT que nous avons réalisée commence par le readiness check. Il détecte les problèmes qui, autrement, n’apparaîtraient qu’en pleine migration.

Nettoyage des données dans V1

Vos données V1 ont accumulé des années d’incohérences. DTT transférera fidèlement ces incohérences dans V2, sauf si vous faites le ménage d’abord.

• Comptes et contacts en double. Fusionnez ou marquez les doublons avant la migration. Les capacités de déduplication de V2 sont meilleures, mais migrer 3’000 enregistrements en double pour les dédupliquer ensuite est du gaspillage.
• Enregistrements orphelins. Contacts sans comptes, activités sans enregistrement parent, opportunités liées à des produits supprimés. Trouvez-les. Corrigez-les ou supprimez-les.
• Objets personnalisés sans données. Si un objet personnalisé est vide depuis deux ans, il n’a pas besoin d’être migré. Chaque objet dans le périmètre de migration ajoute de la complexité.
• Utilisateurs inactifs. Passez en revue votre base utilisateurs. Ne migrez que les utilisateurs actifs. Réattribuez les enregistrements des collaborateurs partis avant la migration, pas après.

Gartner estime que la mauvaise qualité des données coûte en moyenne 12,9 millions de dollars par an aux organisations (Gartner, 2021). Nettoyer vos données avant la migration est un investissement, pas un coût.

Étape 1 : Exécuter le Readiness Check

Accédez au Readiness Check Tool depuis le panneau d’administration V1 sous Administrator > Data Transfer > Readiness Check. Sur certaines versions V1, il se trouve sous Migration Tools.

Ce que le rapport RCT vous indique

Le rapport évalue votre système selon trois dimensions :

Compatibilité des objets. Chaque business object reçoit un statut : Prêt (vert), Attention requise (jaune) ou Incompatible (rouge). Les objets prêts peuvent être transférés directement. Les objets « Attention requise » présentent des problèmes mineurs — généralement des lacunes de mapping de champs ou des différences de format. Les objets incompatibles nécessitent un traitement manuel.

Score de qualité des données. Le rapport signale les problèmes de qualité : champs obligatoires manquants, références cassées, enregistrements orphelins et enregistrements dépassant les limites de longueur des champs V2. Un score inférieur à 70 % signifie qu’un nettoyage est nécessaire avant de poursuivre.

Évaluation des objets personnalisés. Les custom business objects sont évalués pour leur compatibilité V2. Les extensions simples (champs personnalisés sur objets standard) se transfèrent généralement sans problème. Les objets personnalisés complexes avec logique ABSL sont signalés pour reconstruction manuelle.

Comment interpréter les résultats

Un score parfait est rare et non nécessaire. Ce qui compte : zéro élément rouge et un plan d’action pour chaque élément jaune. D’après notre expérience, un système V1 typique présente :

• 60-70 % des objets en vert (prêts)
• 25-35 % en jaune (ajustements mineurs nécessaires)
• 5-10 % en rouge (reconstruction manuelle nécessaire)

Les éléments rouges concernent presque toujours la logique de code personnalisé et les intégrations complexes — des choses pour lesquelles DTT n’a jamais été conçu. C’est attendu, pas alarmant.

Documentez les résultats RCT. Ils deviennent les fondations de votre plan de migration. Chaque élément jaune et rouge a besoin d’un responsable et d’une date de résolution.

Étape 2 : Préparer l’environnement V2

Votre tenant V2 doit être configuré avant de recevoir des données. DTT transfère des enregistrements, mais ne crée pas la configuration métier pour les accueillir.

Configuration du tenant

• Structure organisationnelle. Recréez votre structure dans V2 : organisations de vente, territoires, divisions. V2 utilise un modèle d’affectation différent, c’est donc une reconception, pas une copie.
• Provisionnement des utilisateurs. Créez les comptes utilisateurs dans V2 avec les rôles appropriés. Mappez les identifiants V1 sur les identifiants V2 — DTT utilise ce mapping pour réattribuer la propriété des enregistrements.
• Configuration métier. Configurez les statuts de cycle de vie, les codes motif, les phases de vente, les catégories de produits et les autres données de configuration. Ceux-ci doivent exister dans V2 avant l’arrivée des données.

Mapping des champs personnalisés

Les champs personnalisés V1 nécessitent un mapping explicite vers les champs d’extension V2. C’est là que se concentre la majeure partie du temps de configuration.

Dans V2, les champs personnalisés sont créés via le framework Key User Extensibility. Les types de champs, longueurs et listes de valeurs peuvent différer de V1. Pour chaque champ personnalisé dans le périmètre de migration :

1. Créez le champ d’extension correspondant dans V2
2. Vérifiez que le type de donnée correspond (texte, nombre, date, liste de codes)
3. Pour les champs de type liste, assurez-vous que toutes les valeurs V1 existent dans la liste de valeurs V2
4. Documentez le mapping entre l’identifiant de champ V1 et l’identifiant de champ V2

Ce document de mapping est indispensable. DTT l’utilise pendant le transfert de données pour acheminer correctement les valeurs des champs. Les erreurs ici sont la cause la plus fréquente d’échecs de migration.

Pour des détails sur les fonctionnalités de SAP Sales Cloud V2 et l’extensibilité de V2, consultez notre aperçu des solutions.

Étape 3 : Configurer le DTT

Avec votre environnement V2 préparé, ouvrez le Data Transfer Tool depuis la console d’administration V2 : Paramètres > Migration > Data Transfer Tool.

Sélection des objets

DTT présente une liste d’objets transférables. Sélectionnez ceux à inclure dans la migration. Notre recommandation : commencez par les données de référence, puis les données transactionnelles.

L’ordre de migration est important. Les objets avec des dépendances doivent être transférés en séquence :

1. Produits et listes de prix — référencés par les opportunités et devis
2. Comptes (comptes entreprises d’abord, puis clients individuels)
3. Contacts — liés aux comptes
4. Leads — référencent contacts et comptes
5. Opportunités — référencent comptes, contacts, produits
6. Activités — référencent tous les précédents
7. Tickets de service — référencent comptes, contacts, produits

DTT gère cette séquence automatiquement si vous sélectionnez tous les objets simultanément. Mais comprendre l’ordre aide pour le débogage : si les opportunités échouent, c’est souvent parce qu’une référence compte n’a pas été transférée dans un lot précédent.

Mapping des champs

DTT mappe automatiquement les champs standard entre V1 et V2. Pour les champs personnalisés, vous configurez le mapping manuellement à l’aide du document de l’Étape 2.

L’interface de mapping affiche :

• Champ source (V1) : nom du champ, type de donnée, valeurs exemples
• Champ cible (V2) : champ correspondant ou « Non mappé »
• Règles de transformation : conversion optionnelle des valeurs (par ex. code V1 « A001 » devient code V2 « ACTIVE »)

Vérifiez chaque mapping. Les champs auto-mappés sont généralement corrects, mais nous avons vu des cas où des champs aux noms similaires dans V1 et V2 avaient des sémantiques différentes. Un champ appelé « Catégorie » dans V1 pourrait correspondre à « Classification » dans V2 — même concept, champ différent.

Règles de transformation

Pour les champs où V1 et V2 utilisent des ensembles de valeurs différents, définissez des règles de transformation :

• Mappings de listes de codes. Le statut V1 « En traitement » devient le statut V2 « En cours ». Définissez chaque paire de valeurs.
• Concaténation de champs. V1 pourrait séparer l’adresse en Rue1 + Rue2. V2 pourrait les combiner différemment.
• Valeurs par défaut. V2 peut avoir de nouveaux champs obligatoires inexistants dans V1. Définissez des valeurs par défaut pour éviter les erreurs null.
• Gestion du format de date. Rarement un problème pour les transferts SAP-à-SAP, mais vérifiez la gestion des fuseaux horaires si vos tenants V1 et V2 sont dans des régions différentes.

Étape 4 : Exécuter une migration de test

N’exécutez jamais DTT contre des données de production sans au moins une — de préférence deux — migrations de test complètes. C’est non négociable.

Approche du test

1. Créez un tenant V2 de test ou utilisez l’environnement de qualité/staging. Ne testez jamais contre l’instance V2 de production.
2. Exécutez DTT avec le périmètre complet. Incluez tous les objets, tous les champs personnalisés, toutes les règles de transformation. Un test partiel ne valide pas les références inter-objets.
3. Utilisez des données à l’échelle de production. Si la production contient 1 million d’enregistrements, ne testez pas avec 10’000. Le volume de données crée des modes de défaillance différents : erreurs de timeout, limites de mémoire et goulots d’étranglement de performance qui n’apparaissent qu’à pleine échelle.
4. Mesurez le temps d’exécution. Enregistrez la durée de chaque type d’objet. Ces données déterminent votre fenêtre de basculement en production.

Contrôles de validation après le test

Après la fin du test :

Comparaison du nombre d’enregistrements. Comparez les comptages source et cible pour chaque type d’objet. Les écarts indiquent des enregistrements échoués.

Intégrité des relations. Vérifiez par échantillonnage 50 à 100 enregistrements sur les différents types d’objets. Vérifiez que :

• Les contacts sont liés aux bons comptes
• Les opportunités affichent les produits et phases de vente corrects
• Les activités sont associées aux bons enregistrements parents
• Les valeurs des champs personnalisés ont été transférées correctement

Examen du journal d’erreurs. DTT génère un journal d’erreurs détaillé. Chaque erreur doit être classifiée : critique (bloque la migration), majeure (perte de données) ou mineure (cosmétique). Les erreurs critiques et majeures doivent être résolues avant l’exécution en production.

Erreurs courantes de migration de test et solutions

Dépassement de longueur de champ. Un champ texte V1 autorise 255 caractères ; l’équivalent V2 n’en autorise que 100. Les enregistrements dont les valeurs dépassent la limite V2 échouent. Solution : augmenter la longueur du champ V2 ou ajouter une règle de transformation pour tronquer.

Échecs de recherche. Une opportunité V1 référence un identifiant de compte qui n’existe pas dans V2. Cela se produit quand des enregistrements de comptes échouent silencieusement dans un lot précédent. Solution : résoudre la cause racine (généralement un problème de qualité de données dans V1) et relancer.

Violations de clé unique. V2 impose des contraintes d’unicité plus strictes que V1. Si V1 autorisait des identifiants externes en double, V2 rejettera le second enregistrement. Solution : nettoyer les doublons dans V1 avant la migration.

Champs obligatoires null. V2 introduit de nouveaux champs obligatoires qui n’existent pas dans V1. Les enregistrements sans valeurs échouent. Solution : ajouter des valeurs par défaut dans les règles de transformation.

Exécutez la migration de test, corrigez toutes les erreurs et relancez-la. Nous effectuons typiquement 2 à 3 cycles de test avant l’exécution en production. Chaque cycle devrait produire moins d’erreurs. Si le nombre d’erreurs ne diminue pas, il y a un problème systémique.

Étape 5 : Exécuter la migration de production

La migration de production est l’aboutissement. À ce stade, vous avez déjà prouvé que le processus fonctionne grâce aux tests. L’exécution en production devrait être prévisible.

Considérations de timing

Week-end ou fenêtre de faible activité. DTT sollicite à la fois les systèmes V1 et V2. Exécutez hors des heures ouvrables pour minimiser l’impact sur les utilisateurs actifs. Pour les entreprises européennes, du vendredi soir au dimanche matin est la fenêtre standard.

Période de gel. Déclarez un gel des données sur le système V1 avant de commencer. Aucun nouvel enregistrement, aucune mise à jour. Les modifications effectuées dans V1 après l’instantané DTT sont perdues. Communiquez-le à tous les utilisateurs au moins une semaine à l’avance.

Planification de la durée. Utilisez les temps de votre migration de test, avec une marge de 20-30 %. Si le test a pris 8 heures, planifiez 10 à 12 heures pour la production. La variabilité réseau, les volumes d’enregistrements plus importants et la charge système concurrente ajoutent du temps.

Suivi de la progression

DTT fournit un tableau de bord de progression montrant :

• Phase en cours (quel type d’objet est en cours de transfert)
• Enregistrements traités vs. total
• Compteur d’erreurs (total cumulé)
• Temps restant estimé

Assignez quelqu’un au suivi continu. Si le taux d’erreur dépasse 2 % pour un type d’objet, mettez en pause et investiguez. Il est plus facile de résoudre un problème en cours de migration que de faire le ménage après une exécution terminée mais défectueuse.

Stratégie de points de contrôle

Pour les grandes migrations (1M+ enregistrements), envisagez une approche par phases :

1. Phase A : Données de référence — comptes, contacts, produits. Valider avant de poursuivre.
2. Phase B : Opportunités et leads — dépend de données de référence propres.
3. Phase C : Activités et tickets — volume le plus élevé, risque le plus faible si les données de référence sont solides.
4. Phase D : Pièces jointes et documents — transfert le plus lent, intensif en réseau.

Chaque phase a un point de contrôle. Validez les comptages et les relations avant de démarrer la phase suivante. Si la Phase B échoue, vous annulez la Phase B sans perdre le transfert réussi de la Phase A.

Stratégie de retour en arrière

DTT n’a pas de retour en arrière en un clic. Si la migration échoue de manière catastrophique :

• V1 reste intact. DTT lit depuis V1 ; il ne modifie pas la source. Votre système V1 reste pleinement opérationnel.
• V2 peut être réinitialisé. Pour un redémarrage propre, SAP peut réinitialiser le tenant V2 à l’état vide. Cela nécessite un ticket de support et prend 24 à 48 heures.
• Retour partiel. Si seuls des types d’objets spécifiques ont échoué, vous pouvez supprimer les enregistrements échoués dans V2 et relancer DTT uniquement pour ces objets.

L’approche la plus sûre : maintenir V1 pleinement opérationnel jusqu’à ce que V2 soit validé et que les utilisateurs aient confirmé que la migration est terminée. Nous recommandons une période minimale de 2 semaines d’exploitation en parallèle.

Étape 6 : Validation post-migration

La migration est mécaniquement terminée. Maintenant, il faut le prouver.

Comparaison du nombre d’enregistrements

Effectuez une comparaison complète des comptages sur tous les types d’objets migrés. C’est le même contrôle que lors des tests, mais sur les données de production. Ce qui a réussi en test devrait réussir en production. Les nouvelles divergences pointent vers des données créées entre le test et le gel de production.

Vérifications d’intégrité des relations

Plus profond que le simple comptage. Validez que les relations métier ont survécu au transfert :

• Hiérarchies de comptes. Les structures parent-enfant sont intactes.
• Associations contact-compte. Aucun contact orphelin.
• Pipeline d’opportunités. Phases de vente, revenu attendu, dates de clôture et lignes de produits sont corrects.
• Chronologie des activités. Les activités récentes apparaissent dans le bon ordre chronologique sur les bons enregistrements.
• Valeurs des champs personnalisés. Vérifiez par échantillonnage plus de 100 enregistrements par champ personnalisé pour confirmer que les règles de transformation ont fonctionné.

Liste de contrôle pour les tests d’acceptation utilisateur

Avant de déclarer le succès, faites valider aux utilisateurs métier leurs propres données :

• Directeurs commerciaux : ouvrir la vue pipeline, vérifier que les comptages et valeurs d’opportunités correspondent
• Responsables de comptes : vérifier la complétude de leurs 10 comptes principaux
• Agents de service : vérifier l’historique récent des tickets et les journaux d’interactions clients
• Administrateurs : confirmer les affectations territoriales et les mappings de rôles utilisateur
• Reporting : exécuter les rapports standard et comparer les totaux aux références V1

Les tests d’acceptation prennent typiquement 3 à 5 jours ouvrables. Ne précipitez pas. Un utilisateur qui découvre des données manquantes trois mois plus tard est bien plus perturbant qu’une semaine supplémentaire de validation maintenant.

Ce que le DTT ne transfère pas

Cette section est cruciale. Comprendre ce que DTT ne couvre pas détermine le reste du périmètre et du budget de votre projet de migration.

Logique de code personnalisé. V1 utilise ABSL (ABAP Scripting Language) pour la logique métier personnalisée. V2 ne prend pas en charge ABSL. Toute logique personnalisée doit être réimplémentée — soit comme configurations key user V2, soit comme extensions basées sur BTP. C’est typiquement l’effort manuel le plus important de la migration.

Règles workflow. Les workflows V1 ne sont pas transférés. Reconstruisez-les dans le moteur de règles V2. La bonne nouvelle : le moteur de règles V2 est plus performant. De nombreux workflows V1 qui nécessitaient du code personnalisé peuvent être construits par configuration dans V2.

Configurations d’intégration. Communication arrangements, points de terminaison API, connexions middleware et configurations SSO sont spécifiques au tenant. Chaque intégration doit être rétablie dans V2. Si votre système V1 s’intègre avec S/4HANA, des outils marketing ou des services tiers, planifiez une reconstruction complète des intégrations. Consultez notre guide d’intégration CTI pour voir à quoi ressemblent les intégrations V2 en pratique.

Personnalisations d’interface. Mashups, contenus HTML embarqués, entrées de navigation personnalisées et panneaux latéraux doivent être reconstruits dans le framework UI de V2. V2 utilise un modèle d’extension side-by-side différent via SAP Build Work Zone.

Rapports et tableaux de bord. Les rapports V1 ne sont pas transférés. Reconstruisez-les avec les analytics intégrées de V2 ou SAP Analytics Cloud. La plupart des clients constatent que le reporting natif de V2 couvre 80 % de ce qu’ils avaient construit manuellement dans V1.

Modèles de courriel. Les modèles de courriel avec champs de fusion doivent être recréés dans l’éditeur de modèles V2. La syntaxe des champs de fusion est différente.

Intégrez cela dans votre budget. Dans un projet de migration DTT typique, le transfert de données en lui-même représente 20 à 30 % de l’effort total. Les 70 à 80 % restants sont consacrés à la reconstruction des éléments ci-dessus. Pour le contexte des coûts, consultez notre guide des prix SAP Sales Cloud V2.

Erreurs DTT courantes et comment les résoudre

Selon nos projets de migration, voici les erreurs que vous rencontrerez le plus fréquemment :

Tenez un journal d’erreurs à jour. Catégorisez les erreurs par gravité et fréquence. Certaines erreurs (comme les limites de taille des pièces jointes) affectent peu d’enregistrements et peuvent être traitées individuellement après la migration. D’autres (comme « référence non trouvée ») indiquent des problèmes systémiques nécessitant une analyse des causes racines.

Calendrier : combien de temps dure une migration DTT ?

Les calendriers varient selon le volume de données, la complexité des personnalisations et le nombre d’intégrations. Voici ce que nous avons constaté dans nos projets :

Par taille d’entreprise

Ces calendriers ne couvrent que le flux de travail de migration des données. Le projet complet V1-vers-V2 — incluant la reconstruction des intégrations, la réimplémentation de la logique personnalisée, la formation et le go-live — est plus long. Pour le tableau d’ensemble, consultez notre comparaison de migration V1 vs V2.

Tableau de planification

Utilisez ceci comme cadre de départ pour votre plan de projet :

Ajoutez 20 % à chaque estimation. D’après notre expérience, les phases de nettoyage des données et de mapping des champs sont les plus susceptibles de dépasser. Personne ne connaît le véritable état de ses données V1 tant qu’il n’a pas regardé de près.

FAQ

Le DTT prend-il en charge la migration delta ?

Oui, avec des réserves. DTT peut s’exécuter de manière incrémentale pour transférer les enregistrements créés ou modifiés après la migration initiale. C’est utile pour la période entre la migration de test et le basculement en production. Toutefois, la migration delta ne gère pas les suppressions — les enregistrements supprimés dans V1 après le transfert initial restent dans V2. Planifiez un passage de nettoyage après le basculement.

Peut-on exécuter le DTT plusieurs fois ?

Oui. DTT est conçu pour une exécution itérative. Chaque exécution peut être limitée à des types d’objets spécifiques ou filtrée par plage de dates. Les exécutions suivantes ignorent les enregistrements déjà transférés (identifiés par clés uniques). C’est ainsi que fonctionne le cycle test-et-affinage.

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

Oui. DTT couvre les objets Sales Cloud et Service Cloud. Tickets de service, interactions, articles de la base de connaissances et configurations SLA sont dans le périmètre du DTT. Le processus est identique — d’abord le RCT, puis la configuration DTT, les tests et la migration de production.

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

Rien. V1 reste pleinement opérationnel. SAP recommande de maintenir l’accès à V1 pendant au moins 90 jours après le go-live V2, pour les besoins de référence et d’audit. Le tenant V1 est éventuellement décommissionné, mais c’est un processus séparé selon votre calendrier.

Peut-on migrer d’un CRM tiers vers V2 avec le DTT ?

Non. DTT est exclusivement réservé à la migration SAP V1 vers V2. Si vous migrez depuis Salesforce, Dynamics 365 ou un autre CRM, vous utiliserez les API d’import de données standard de SAP ou une solution middleware. Nous avons publié un guide séparé sur la migration d’Excel vers V2 pour les scénarios plus simples.

Comment gérer les objets personnalisés avec des relations complexes ?

Les objets personnalisés à structure simple (champs personnalisés sur objets standard) se transfèrent via DTT. Les objets métier personnalisés complexes avec des relations inter-objets, de la logique ABSL ou des UI personnalisées nécessitent une reconstruction manuelle. Exportez les données depuis V1 via OData, transformez-les et importez-les dans V2 via les API V2. C’est du travail de projet, pas du travail DTT.

Que faire si mon système V1 est fortement personnalisé ?

Une forte personnalisation signifie plus d’effort de reconstruction manuelle, mais ne vous disqualifie pas de l’utilisation du DTT. DTT gère les données ; votre équipe projet gère la logique. Le rapport RCT quantifie exactement quelle proportion de personnalisation se trouve hors du périmètre DTT. Utilisez ce rapport pour cadrer le périmètre et le budget des flux manuels.

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

SAP ne publie pas de limite fixe. Nous avons migré avec succès des tenants de plus de 10 millions d’enregistrements sur tous les types d’objets. La performance est la contrainte pratique : les très grands jeux de données prennent plus de temps et peuvent nécessiter un ajustement de la taille des lots. La release 2511 a significativement amélioré les performances du DTT pour les scénarios à haut volume.

La migration de V1 vers V2 n’est pas optionnelle pour les organisations investies dans l’écosystème CRM de SAP. Le Data Transfer Tool rend la partie données gérable. Ce qui distingue une migration fluide d’une migration douloureuse, c’est la préparation : des données propres, un mapping de champs complet, des tests approfondis et des calendriers réalistes.

Si vous planifiez une migration DTT et souhaitez un second avis sur votre état de préparation, contactez-nous. Nous avons fait ce parcours suffisamment de fois pour savoir où se cachent les problèmes.