De nombreux guides indiquent qu'une migration de service d'assistance prend entre 4 et 12 semaines. Cette durée correspond à un projet planifié et testé manuellement, avec un script de transfert entièrement personnalisé. Avec un outil de migration éprouvé, la plupart de ces semaines sont évitées : la configuration se fait en quelques minutes grâce à un assistant, un test est également rapide, et le transfert s'effectue en arrière-plan pendant que votre équipe continue de travailler.
Le principal facteur déterminant réside dans les plateformes. Zendesk autorise 200 requêtes API par minute avec son forfait Team et 2 500 avec Enterprise Plus (Zendesk Documentation développeur). Halo limite l'utilisation de l'API à 300 appels toutes les cinq minutes (HaloPolitique d'utilisation équitable). Depuis le 2 mars 2026, Atlassian facture Jira Cloud selon un quota horaire basé sur des points (Atlassian Developer). Vous trouverez ci-dessous les temps d'exécution typiques par type de projet, par volume de données et par plateforme, ainsi que les étapes d'un projet de migration.
Durée d'un projet de migration de centre d'assistance, du début à la fin
Le transfert de données n'est qu'une étape. La majeure partie du projet consiste en préparation et en vérification ; il est donc important de planifier l'ensemble du calendrier, et pas seulement l'exécution.
Préparation Help Desk Migration : 10 étapes avant la mise en service
Commencez par définir les objectifs du projet et auditer les enregistrements existants, puis nettoyez les données, configurez la plateforme cible et testez le mappage des champs ; chaque étape contribue à prévenir les retards et les problèmes de données. Voici un aperçu des principales étapes de la migration et de leurs délais habituels.
| Phase | Ce qu'il faut faire | Temps typique |
|---|---|---|
| 1. Définir la portée et les objectifs | Mettez-vous d'accord sur les raisons de la migration, la plateforme cible et la date de mise en service | 1 à 2 jours |
| 2. Alignez l'équipe | Désignez un responsable de projet, briefez les agents et les gestionnaires, et convenez d'une période de transition | 1 à 3 jours |
| 3. Auditez vos données | Listez vos éléments : tickets, contacts, entreprises, pièces jointes, champs personnalisés, macros | 2 à 5 jours |
| 4. Décider quoi migrer | Marquez les données comme devant être déplacées, à déplacer ultérieurement ou à archiver. Les tickets clos plus anciens peuvent généralement être omis sans risque | 1 à 2 jours |
| 5. Nettoyer les données | Fusionner les doublons, fermer les tickets obsolètes, supprimer les éléments indésirables | 2 à 7 jours |
| 6. Préparer la cible | Configurez des champs personnalisés, des agents et des automatisations pour que les enregistrements importés aient un emplacement où atterrir | 3 à 10 jours |
| 7. Exécutez une migration de démonstration | Effectuez des tests sur un échantillon, vérifiez le mappage des champs et les pièces jointes, et corrigez les problèmes | 1 à 3 jours |
| 8. Migration complète | Transférer tous les enregistrements (de quelques heures à plusieurs jours, selon le volume et les limites de l'API) | 1 à 5 jours |
| 9. Basculement | Déplacez les enregistrements créés depuis l'exécution complète et basculez les agents | 1 jour |
| 10. Vérifier et soutenir | Comparer le nombre d'enregistrements, effectuer des contrôles ponctuels des données et former les agents | 1 à 2 semaines |
En résumé : la plupart des projets de migration complète durent de 2 à 6 semaines, et le transfert des données prend généralement moins d’une semaine. Les phases 3 à 6 peuvent se chevaucher ; il est donc préférable de commencer les préparatifs au plus tôt pour optimiser la durée du projet.
Le processus de migration : échéanciers de migration estimés en fonction de la taille et de la complexité du projet
Le tableau ci-dessous récapitule chaque étape d'un projet pour trois scénarios courants. Les temps de transfert proviennent de nos journaux de bord. Les autres étapes correspondent à des plages de planification basées sur les durées des étapes détaillées plus loin dans cet article.
| Scénario | Installation et démonstration | Corrections de tests et de cartographie | Migration complète (transfert) | Delta et basculement | Total typique |
|---|---|---|---|---|---|
| Configuration standard et réduite : moins de 10 000 enregistrements, peu de champs personnalisés | 15 à 30 min | 1 à 2 h | ~35 min (9 sur 10 en ~4,5 h) | 1 à 2 h | Environ 1 jour |
| Taille moyenne avec champs personnalisés : 10 000 à 100 000 enregistrements, plusieurs rediffusions de la démo | 1 à 2 h | 1 à 3 jours | ~4 h (9 sur 10 en ~1 jour) | 2 à 4 h | 2 à 5 jours |
| Gestion d'entreprise ou fusion de plusieurs services d'assistance : plus d'un million d'enregistrements, objets personnalisés, objectif de limite basse | 1 à 2 jours de planification | 3 à 7 jours | ~2 jours (9 sur 10 en ~8,5 jours) | une demi-journée | 2 à 6 semaines |
Dans un projet d'envergure, le temps est principalement consacré à la révision et à la prise de décisions, et non au temps machine. C'est pourquoi les gains les plus importants proviennent de tests précoces et d'une limitation stricte du périmètre. Les conseils d'accélération ci-dessous couvrent ces deux aspects.
Durée typique de migration des données en fonction du volume de données
Le tableau ci-dessous présente la durée des transferts de données lors Help Desk Migration observées, regroupées par nombre d'enregistrements déplacés. Les colonnes indiquent le nombre d'exécutions, l'intervalle couvert par la moitié centrale des exécutions, la médiane et le temps d'exécution minimal (9 exécutions sur 10) avant la fin.
| Volume de données (enregistrements) | Courses | Plage typique (50 % du milieu) | Médian | 9 sur 10 terminent dans les |
|---|---|---|---|---|
| Petit : moins de 10 000 | 496 | 15 min – 1,5 h | ~35 min | ~5 h |
| Moyen : 10K – 100K | 572 | 1,5 h – 11 h | ~4 h | ~1 jour |
| Grand : 100 000 – 1 million | 457 | 5 h – 1 jour | ~12 h | ~2 jours |
| Très grand : 1 m et plus | 263 | 21 h – 5 jours | ~46 h | ~8,5 jours |
Ces durées sont issues de migrations réelles et non d'une formule. Elles concernent les transferts API à API, quel que soit le niveau d'abonnement utilisé par chaque client. Les sources CSV, databaseet boîtes mail, dont la vitesse varie, sont exclues de cette analyse. Le transfert de 30 000 enregistrements peut ainsi prendre une heure ou presque une journée, selon les plateformes décrites dans la section suivante.
Temps de migration par plateforme (limites d'API)
Les limites de l'API de chaque plateforme déterminent la vitesse à laquelle les enregistrements peuvent être lus (exportation) ou écrits (importation). Le tableau répertorie 13 plateformes avec leurs limites d'API documentées pour les niveaux standard et supérieur, ainsi que les temps d'exportation et d'importation observés lors de migrations d'environ 100 000 enregistrements.
| Plate-forme | Limite d'API (niveau standard / niveau supérieur) | Exportation, environ 100 000 enregistrements | Importation, ~100 000 enregistrements | Notes |
|---|---|---|---|---|
| Zendesk | 200 / 2 500 tr/min | 7 h | 24 h | Cible commune la plus rapide |
| Freshdesk | 100 / 700 tr/min | 6,5 h | 23 h | Rapide dans les deux sens |
| Freshservice | 100 / 500 tr/min | 17 h | 23 h | Lent en tant que source ; la vitesse d'exportation augmente à peine avec le volume |
| Jira Service Management | système à points (quota horaire) | 25 h | 25 h | Cible commune la plus lente de loin : ~1 250 enregistrements/h quelle que soit la taille |
| Intercom | 10 000 tr/min par application ; plus élevé sur demande | 5 h | 5 h | Rapide dans les deux sens ; limites comptabilisées par tranches de 10 secondes |
| HubSpot Service Hub | 600 / 1 140 tr/min | 1 h | 6 h | Exportation très rapide |
| Salesforce Service Cloud | quotidien : ~100 000 requêtes/jour | 30 h | 70 h | Plafond journalier ; ralentit fortement au-dessus des records à 1 million (voir ci-dessous) |
| Zoho Desk | crédits journaliers | 2,5 h | 13 h | Crédits journaliers ; largement répandus |
| ServiceNow | configurable par l'administrateur | 2 h | 19 h | Cela dépend des limites propres à l'instance |
| Halo | 60 tr/min (300 tr/min / 5 min) | 4,5 h | 12 h | Limite la plus basse documentée dans le tableau |
| Pylon | non documenté | n/a (cible uniquement) | 23 h | Confirmez la limite avec Pylon |
| Front | 50 / 200 tr/min | 32 h | 20 h | La limite basse correspond aux périodes de faible activité |
| Gorgias | 120 tr/min (40 tr/min / 20 s) | n / A | 19 h | Cible lente |
Les limites des API ont été vérifiées par rapport à la documentation développeur de chaque fournisseur en novembre 2026. Ces limites étant fréquemment modifiées, et la plupart des fournisseurs proposant des offres supérieures ou des modules complémentaires, il est conseillé de vérifier votre propre abonnement avant de planifier une migration. Pour obtenir une valeur précise pour vos données,
Relokia a réalisé la migration Freshservice Help Desk Migration de Vanta vers Jira Service Management en seulement 21 jours, transférant plus de 128 000 tickets tout en préservant l'historique, les pièces jointes et l'intégrité des journaux d'audit. Voici comment nous avons procédé :
Vanta : Plus de 128 000 billets transférés en seulement 21 jours
Relokia a réalisé la migration Freshservice Help Desk Migration de Vanta vers Jira Service Management en seulement 21 jours, transférant plus de 128 000 tickets tout en préservant l'historique, les pièces jointes et l'intégrité des journaux d'audit. Voici comment nous avons procédé :
Du lancement du projet à son achèvement réussi en seulement 21 jours, Vanta a migré plus de 128 000 tickets, 512 000 commentaires, 86 000 pièces jointes et plus de 4 200 demandeurs et agents de Freshservice vers Jira Service Management, préservant le contexte historique et l'intégrité complète de la piste d'audit.
Le respect des délais serrés a été rendu possible grâce à des options de migration automatisées, des configurations sur mesure et une approche itérative. Les images intégrées ont été transférées en tant que pièces jointes aux tickets, tandis que des étiquettes personnalisées basées sur les champs de groupe ont permis de maintenir les enregistrements migrés organisés et faciles à identifier.
Le forfait d'assistance Premium comprenait une nouvelle migration, donnant à Vanta le temps d'appliquer des personnalisations, de valider les résultats et de finaliser le transfert sans prolonger le délai de projet de 21 jours.
Qu'est-ce qui influence la durée d'une migration de données ?
Les limites de l'API constituent le plafond. Quatre autres facteurs déterminent dans quelle mesure une migration s'en approche et combien de temps dure le projet.
- Nombre d'enregistrements. Chaque ticket est associé à des commentaires ; un seul ticket peut contenir des centaines, voire des milliers de commentaires, et chaque commentaire fait partie du transfert. Le volume sert de référence.
- Pièces jointes. Chaque fichier est téléchargé séparément ; les pièces jointes ont donc plus d’importance que le nombre de tickets. Un compte volumineux avec peu de pièces jointes peut être traité plus rapidement qu’un compte plus petit rempli de captures d’écran et de PDF. Le nombre de fichiers étant difficile à estimer à l’avance, les migrations comportant un grand nombre de pièces jointes sont les plus difficiles à prévoir.
- Les forfaits varient de part et d'autre. La plupart des fournisseurs adaptent les limites d'API au forfait choisi : plus le forfait est élevé, plus le nombre d'appels API autorisés est important. Par exemple, Freshservice propose 100 requêtes par minute avec le forfait Starter et 500 avec le forfait Enterprise, avec des options supplémentaires permettant d'atteindre jusqu'à 2 000 requêtes (voirFreshservice la documentation de l'API).
- Fusion de plusieurs services d'assistance en un seul. La consolidation ne consiste pas en une seule migration, mais en plusieurs migrations vers une même cible. Chaque source est traitée comme une migration distincte, et chaque migration suivante aboutit dans une cible contenant déjà des données. Nos ingénieurs techniques peuvent évaluer vos besoins en matière de migration et déterminer si une approche parallèle (multithread) ou séquentielle permettra d'obtenir les résultats les plus rapides. Mayvik a transféré des données de Freshdesk, Zendesk, Desk.com et Groove vers Help Scout de cette manière.
Notre guide sur les défis liés à la migration des données du support client répertorie tout ce qui peut ralentir un projet, ainsi que les solutions possibles.
Chronologie de la migration des données, étape par étape
Le temps de transfert ne représente qu'une partie d'un projet de migration. Le calendrier ci-dessous décrit l'ensemble du processus et la durée habituelle de chaque étape.
Étape 1 : Cartographiez vos données et exécutez une migration de démonstration (15 à 30 minutes)
Voici donc les principales options que vous pouvez envisager pour choisir une méthode de transition de données :
Une démonstration gratuite dure généralement entre 15 et 30 minutes. L'assistant de migration vous permet de connecter les plateformes source et cible (vous devez disposer de droits d'administrateur sur les deux). Vous sélectionnez ensuite les enregistrements à transférer, associez les agents et les groupes, et mappez les champs d'organisation, de client, de ticket et d'article. Les étapes de mappage précises varient selon la paire de plateformes à migrer. Vous pouvez également utiliser des options automatisées prédéfinies pour personnaliser l'importation.
La démonstration est plus longue si la configuration préalable à la migration n'est pas effectuée. Avant de commencer, rassemblez les identifiants d'accès pour les deux plateformes, créez les profils et groupes d'agents correspondants sur la plateforme cible et configurez les champs personnalisés requis pour les tickets. Si de nombreux champs personnalisés sont nécessaires, prévoyez plusieurs étapes de mappage.
Étape 2 : Examiner les résultats de la démonstration (de quelques minutes à 2 heures)
L'examen d'une démo prend quelques minutes. Tester les résultats d'une migration de données complète prend au moins 1 à 2 heures. La démo reproduit la migration complète ; par conséquent, si un élément n'est pas migré dans la démo, il ne le sera pas non plus dans la migration complète. Relancez la démo autant de fois que nécessaire pour optimiser le mappage.
Vérifiez que :
- Les commentaires ont les auteurs corrects
- Les billets sont attribués aux agents appropriés
- Les champs personnalisés contiennent les valeurs correctes
- Les entreprises et les clients sont liés
- Les pièces jointes arrivent avec leurs noms
- Les articles se trouvent dans les sections et catégories appropriées
- Le partage de l'accès à la migration permet à votre équipe de contribuer à la validation.
Le partage de l'accès à la migration permet à votre équipe de contribuer à la validation.
Étape 3 : Préparez votre équipe et le service d’assistance cible (moins de 2 heures)
Commencez l'intégration des agents dès que possible. La durée dépend du nombre d'agents et de la plateforme cible. La migration elle-même est rapide :
- Désactivez les automatisations sur la cible ou demandez une étiquette : 5 à 30 minutes
- L'équipe d'assistance cesse de travailler dans la source : 5 minutes
- Coupez les canaux de communication sur la source : 5 à 15 minutes
- Activation des canaux de communication sur la cible : 15 minutes à 1 heure
Étape 4 : Exécuter la migration complète (de quelques heures à quelques jours)
Il s'agit du temps de transfert indiqué dans les tableaux de volume et de plateforme. Votre équipe peut continuer à travailler sur le centre d'assistance source pendant l'exécution. Vous pouvez suivre la progression dans le tableau des enregistrements, qui affiche les enregistrements récupérés et transférés, et vous recevrez un e-mail une fois la migration terminée. Si l'exécution doit s'effectuer pendant les heures de bureau, la migration par intervalles vous permet de mettre en pause et de reprendre la migration complète en coordination avec notre équipe.
Étape 5 : Exécuter une migration delta pour les nouveaux enregistrements
Les tickets créés ou mis à jour dans le système source lors de la migration complète peuvent être transférés ultérieurement grâce à la migration delta, disponible avec l'abonnement Premium. Validez le résultat avant de transférer les agents vers le système cible.
8 façons d'accélérer votre migration de données
Pour accélérer la migration d'un service d'assistance, d'un système ITSM ou RMM, plusieurs mesures permettent de réduire le temps de transfert des données, de simplifier la préparation et d'éviter les retards inutiles. De l'optimisation des limites d'API au nettoyage des données sources, en passant par la rationalisation du mappage des champs et l'utilisation de la migration parallèle, une approche adaptée peut rendre l'ensemble du projet plus rapide et plus prévisible. Voici quelques pistes pour accélérer votre migration sans compromettre l'exactitude des données ni la continuité de votre activité.
- Demandez à votre fournisseur une augmentation temporaire de votre limite d'API. Intercom accepte les demandes d'augmentation de limite, Freshdesk vend des appels API supplémentaires et Zendesk propose une option API haut volume qui porte les forfaits éligibles à 2 500 requêtes par minute.
- Ignorer les pièces jointes. L'option « Ignorer les pièces jointes » permet de déplacer les enregistrements sans
les fichiers. Excluez les pièces jointes de tous les tickets ou de ceux dont la dernière mise à jour remonte à plus de 6, 12 ou 24 mois. Réduisez le temps de migration et les coûts de stockage en ne transférant que les fichiers nécessaires à votre équipe. Idéal pour les migrations importantes, les fichiers obsolètes et pour éviter la saturation du stockage. - Filtrez les enregistrements anciens ou non pertinents. Moins d'enregistrements signifie moins d'appels API. Vous n'êtes pas obligé de tout migrer vers votre nouvelle plateforme. Utilisez les options de filtrage de l'assistant de migration pour sélectionner les enregistrements à transférer et exclure les données non pertinentes, comme tous les tickets ou ceux dont la dernière mise à jour remonte à plus de six mois. Si les filtres standard ne répondent pas à vos besoins, vous pouvez demander des options de filtrage supplémentaires à notre équipe technique. Elle peut vous aider à configurer des filtres personnalisés en fonction de la portée de votre migration, afin que vous ne transfériez que les données nécessaires, réduisiez les appels API et gagniez du temps.
- Migration multithread avec Help Desk Migration. Migrez en parallèle. Le transfert asynchrone et multithread s'exécute en parallèle, envoyant plusieurs requêtes simultanément au lieu d'une par une, ce qui réduit le temps d'attente des réponses. Il est recommandé d'utiliser une limite d'API plus élevée, car les requêtes parallèles sont comptabilisées dans cette limite. Cette fonctionnalité est disponible dans les abonnements Premium et Entreprise.
- Passez à un forfait supérieur pendant la migration. Un forfait plus élevé sur une plateforme plus lente augmente généralement sa limite d'API pendant toute la durée de l'exécution.
- Migrez d'abord les enregistrements les plus récents. Transférez en priorité les tickets les plus récents afin que votre équipe puisse traiter les problèmes clients actifs pendant que les enregistrements plus anciens migrent en arrière-plan. Cette option est idéale pour les interruptions de service limitées, un support continu, les budgets serrés et pour tester les tickets actifs avant la mise en service. Disponible uniquement pour la migration complète.
- Utilisez la migration delta pour la transition. Transférez les tickets créés ou mis à jour dans la source après la migration complète, afin de garantir que votre nouvelle plateforme dispose des données les plus récentes avant la mise en production. Cela minimise les interruptions de service et évite les pertes de données. Disponible avec l'abonnement Premium.
- Utilisez la migration par intervalles pour l'adapter aux heures de bureau. Suspendez la migration complète pendant les heures de pointe et reprenez-la ensuite. Vous pouvez la suspendre jusqu'à cinq fois, pour une durée maximale de cinq jours à chaque fois, en coordination avec notre équipe.
Pour les migrations complexes, nos services de migration gérée offrent un soutien expert en matière de planification, de personnalisation, de mappage des données, de limites d'API et de validation afin de garantir une transition en douceur avec un minimum de perturbations.
Pandora: Migration à l'échelle de l'entreprise réalisée en seulement 4 semaines
En seulement 4 semaines, sans aucune interruption de service, Pandora a réalisé une migration à l'échelle de l'entreprise de Zendesk vers Salesforce Service Cloud, consolidant les données de support client sur plus de 6 500 points de vente et 37 000 employés dans le monde entier.
La migration a transféré l'intégralité des historiques de tickets et de clients, les enregistrements d'appels, les pièces jointes, les notes internes, les conversations parallèles et les flux de travail métier, tout en préservant les relations entre les données.
Pour respecter les délais du projet, l'équipe a utilisé une approche itérative avec cinq migrations de démonstration afin de valider le mappage des champs et les configurations avant le transfert final. Les déclencheurs du système Salesforce ont été temporairement désactivés pour éviter les blocages et garantir une transition fluide.
Migration manuelle, automatisée ou gérée : comparaison des délais
Un script élaboré en équipe, un outil de migration en libre-service et un service de migration géré diffèrent principalement par le temps passé avant et après le transfert, et non pendant le transfert.
| Critère | Manuel (script personnalisé) | Outil Help Desk Migration | Service de migration géré par Help Desk Migration |
|---|---|---|---|
| Temps d'installation | Des semaines, voire des mois, pour étudier les deux API | Quelques minutes suffisent pour se connecter et créer une carte grâce à un assistant | Notre équipe définit le périmètre du projet et cartographie les données avec vous |
| Essai | Construit et répété par votre équipe | Migration de démonstration sur un échantillon, à réexécuter si nécessaire | Des démonstrations et un plan de validation pour le projet |
| Gestion des limites de l'API | Votre code doit limiter la fréquence et réessayer | Intégré à l'outil | Intégré, plus les demandes de limites des fournisseurs prévues à l'avance |
| Champs personnalisés, filtres, fusions | Quel que soit le projet de votre équipe | Cartographie standard et options automatisées, filtrage. Demandez des filtres personnalisés ou des personnalisations de migration supplémentaires à notre équipe technique afin d'adapter le processus à vos données et aux besoins de votre projet. | Filtrage personnalisé, mappage personnalisé, consolidation multi-sources |
| Durée typique du projet | Des semaines à des mois | Quelques heures à quelques jours | De quelques jours à quelques semaines, selon l'étendue |
| Coût | Temps d'ingénierie, souvent caché | Tarification selon le volume d'enregistrements et les options, forfait d'assistance (tarification) | Prix calculé en fonction du volume d'enregistrements, des options et du forfait d'assistance (services de migration). |
Un service géré ne signifie pas forcément du code personnalisé pour chaque projet. L'équipe de Help Desk Migrationutilise le même moteur éprouvé que l'outil en libre-service ; la vitesse de migration reste donc identique, mais la planification, la cartographie et la validation sont prises en charge par votre équipe.
pour voir comment vos propres enregistrements se comportent sur votre itinéraire, ou discutez avec un expert d'un projet d'entreprise ou multi-sources.
FAQ
D'après nos journaux, les migrations de plus d'un million d'enregistrements ont pris en moyenne 46 heures. La moitié des exécutions se sont terminées en 21 heures à 5 jours, et 9 sur 10 en environ 8,5 jours. Une cible à faible capacité, comme Jira Service Management prendrait environ un mois, tandis qu'une cible à capacité journalière, comme Salesforce Service Cloud, pousse l'exécution vers la limite supérieure de cette fourchette. En ajoutant quelques jours à une semaine pour la cartographie et les tests autour du transfert, un projet d'un million de tickets se réalise généralement en une à trois semaines, et non en trois mois.
Ces délais correspondent généralement à l'ensemble d'un projet réalisé manuellement ou avec une solution sur mesure : plusieurs semaines de planification, une migration de test scriptée, le transfert et plusieurs semaines d'assurance qualité. Avec un outil de migration éprouvé, le mappage et les tests prennent de quelques minutes à quelques jours, et le transfert lui-même quelques heures pour la plupart des comptes. Les projets de très grande envergure ou multi-sources nécessitent toujours une planification rigoureuse, mais un délai de plusieurs mois implique généralement un travail manuel considérable.
Oui. Chaque pièce jointe est téléchargée séparément ; un compte contenant de nombreux fichiers peut donc prendre plus de temps qu'un compte plus important avec peu de fichiers. Les articles de la base de connaissances sont généralement moins nombreux que les tickets, mais les images intégrées et la structure des articles (sections et catégories) rallongent le temps de traitement et de vérification. Si les pièces jointes ralentissent le transfert, l'option « Ignorer les pièces jointes » permet de transférer les enregistrements sans les fichiers.
Pour les données du service d'assistance dans Salesforce Service Cloud (incidents, contacts et articles de la base de connaissances), ZendeskversSalesforce d'après nos journaux, ont pris en moyenne environ 6 heures pour 10 000 à 100 000 enregistrements et environ 12 heures pour 100 000 à 1 million. Au-delà d'un million d'enregistrements, Salesforceralentit le processus : ZendeskversSalesforce de cette taille ont pris en moyenne 3,4 jours. Ces chiffres ne concernent pas une migration complète de Sales Cloud CRM. Consultez notre Salesforce Service Cloud dédiée à la migration vers pour connaître le nombre d'enregistrements pris en charge.
La migration parallèle s'exécute sur plusieurs threads, envoyant simultanément de nombreuses requêtes afin de réduire le temps d'attente des réponses. Elle est particulièrement utile pour les comptes volumineux comportant de nombreux types d'enregistrements, et moins pertinente si vous avez déjà atteint la limite de l'API du fournisseur ; dans ce cas, il est conseillé d'augmenter cette limite au préalable. Les enregistrements associés, tels que les tickets et leurs demandeurs, sont toujours créés dans le bon ordre, et une migration de démonstration vous permet de vérifier le résultat avant l'exécution complète.
Oui. Les agents continuent de travailler sur le service d'assistance source pendant la migration complète, car le transfert s'effectue via l'API sans bloquer le compte. Désactivez d'abord les automatisations sur le système cible afin que les tickets importés n'entraînent pas l'envoi d'e-mails aux clients. Le guide de migration sans interruption de service décrit la procédure de basculement.
Les tickets créés ou mis à jour dans la source après le début de la migration complète ne sont pas inclus dans cette opération. La migration delta les déplace lors d'une étape ultérieure, beaucoup plus courte, permettant ainsi aux agents de passer à la cible en conservant l'historique complet. La migration delta est disponible avec l'abonnement Premium. La liste de contrôle générale de migration des données indique où la migration delta intervient dans le processus de basculement.
Oui, avec la migration par intervalles. Vous pouvez interrompre la migration complète jusqu'à cinq fois, pour une durée maximale de cinq jours à chaque fois, et la reprendre en coordination avec l' Help Desk Migration . Par exemple, vous pouvez éviter de surcharger l'API pendant les heures de pointe du support. La migration par intervalles est différente de la migration delta, qui déplace les enregistrements créés après l'exécution principale. Les étapes de suspension et de reprise sont décrites dans la section d'aide « Premiers pas ».
Lors d'une migration de démonstration, l'assistant de migration affiche une barre de progression indiquant le pourcentage de données transférées. Lors d'une migration complète, un tableau récapitulatif indique le nombre d'enregistrements récupérés et transférés. Vous recevrez un courriel une fois la migration (de démonstration ou complète) terminée.
Comparez la cible avec la source : nombre d’enregistrements par type, auteurs des commentaires, responsables des tickets, valeurs des champs personnalisés, pièces jointes et catégories d’articles. Vérifiez un échantillon de tickets anciens, récents et comportant de nombreuses pièces jointes, puis activez les déclencheurs, les automatisations et les notifications dans la cible. Recueillez les commentaires des agents lors de leurs premiers jours dans le nouveau centre d’assistance. La liste de contrôle post-migration répertorie chaque vérification.
Commencez par vérifier le tableau de la plateforme : une lenteur lors de l’exécution vers une cible à faible limite, comme Jira Service Management, Haloou Front est souvent normale. Si le nombre d’enregistrements dans le tableau de progression reste inchangé pendant plusieurs heures, il est possible qu’une limite d’API quotidienne ou un jeton expiré ait interrompu l’exécution. Dans ce cas, contactez notre équipe d’assistance en lui communiquant votre ID de migration afin qu’elle puisse consulter les journaux.
