Fusionnez ou divisez les instances Zendesk® sans manquer une réponse
Migrez Zendesk® vers Zendesk® sans perte de données, interruption de service ni perturbation opérationnelle. Que vous consolidiez vos données suite à une acquisition ou que vous sépariez vos environnements par marque, région ou exigences de conformité, cette approche de migration de données est conçue pour garantir la continuité de l'activité de vos agents et la réception des réponses par vos clients.
Sans carte de crédit Config rapide
Utilisé par 40 000+ sociétés
Pourquoi fusionner ou scinder les instances Zendesk®
Les organisations fusionnent leurs comptes Zendesk® après des fusions-acquisitions, une consolidation interne ou lorsqu'elles souhaitent réduire les coûts liés à la maintenance de plusieurs systèmes.
Les équipes choisissent de fusionner les instances Zendesk® lorsque :
Vous avez acquis une autre société et vous devez fusionner les comptes Zendesk® afin que les agents puissent consulter et répondre en conservant l'intégralité du contexte historique.
Après la consolidation des instances Zendesk® , les équipes ont besoin d'une visibilité partagée et de tableaux de bord de reporting unifiés pour toutes les fonctions de support.
La présence de plusieurs instances Zendesk® entraîne des flux de travail dupliqués, des automatisations redondantes et des lacunes dans la précision des rapports.
En choisissant de fusionner les instances Zendesk® , les équipes éliminent les flux de travail dupliqués, réduisent la prolifération de l'automatisation et centralisent la gestion des SLA tout en préservant les données historiques et en minimisant les perturbations.
La séparation des instances Zendesk® devient essentielle lorsque les marques, les régions ou les obligations de conformité exigent une indépendance.
Les équipes séparent les instances Zendesk® lorsque :
Les flux de travail ou les SLA sont en conflit entre les départements ou les régions géographiques.
Les équipes ont besoin d'autonomie opérationnelle pour répondre aux exigences réglementaires ou de conformité locales.
Un reporting ou une identité visuelle distincts sont nécessaires pour les interactions avec les clients.
Cette approche de migration contrôlée Zendesk® réduit les conflits de flux de travail, les tickets mal acheminés et les erreurs de reporting, tout en offrant aux départements ou aux marques la liberté dont ils ont besoin.
Pourquoi la migration Zendesk® vers Zendesk® semble risquée (et comment nous éliminons ce risque)
Une migration Zendesk® vers Zendesk® semble risquée lorsqu'elle est effectuée sans visibilité ni validation.
Risque : Perte de données critiques
La simple idée de perdre des tickets, des pièces jointes, des notes privées, des enregistrements d'appels ou l'historique des échanges suffit à faire hésiter les équipes. Un clic malencontreux pourrait sembler irréversible.
Comment Help Desk Migration gère cela :
Notre service de migration de données garantit la migration précise de chaque ticket, pièce jointe et conversation. Les migrations de démonstration vous permettent de visualiser vos données réelles transférées en toute sécurité avant de vous engager. Rien n'est perdu, rien n'est endommagé.
Risque : Interruption de service et perturbation du support
Vos agents continuent de travailler et vos clients de répondre. Toute interruption de service est inacceptable lors de la consolidation des instances Zendesk® .
Comment Help Desk Migration gère cela :
Toutes les migrations de données Zendesk® s'exécutent en arrière-plan, Zendesk® restant opérationnel. Lors d'une migration delta, vous pouvez migrer les nouvelles activités, ce qui garantit la continuité du support et le respect des SLA.
Risques : Flux de travail défaillants, tickets mal acheminés et cartographie incorrecte
Des marques, des formulaires, des responsables ou des statuts incorrects peuvent bloquer les équipes et engendrer de la confusion, des problèmes de communication et des erreurs de reporting lors de la consolidation des instances Zendesk® .
Comment Help Desk Migration gère cela :
L'assistant de migration vous aide à mapper avec précision les tickets, les utilisateurs, les champs personnalisés, les macros et les déclencheurs. Les cas particuliers, comme les tickets fusionnés, les suivis ou les utilisateurs suspendus, sont gérés automatiquement. Vous validez chaque étape du mappage, ce qui réduit les risques à néant.
Risques : Coût, continuité des rapports et contexte historique
Migrer un trop grand volume de données peut engendrer des coûts supplémentaires. Les rapports Explore ne sont pas migrés par défaut. Il est donc possible que des pièces jointes, des captures d'écran ou des notes soient perdues.
Comment Help Desk Migration gère cela :
Notre service de migration de données vous permet de filtrer les tickets et les données, de préserver l'intégrité des rapports et de conserver tous les détails historiques pertinents. Vous gardez la maîtrise du périmètre et du coût.
Ce qui paraissait risqué devient prévisible, sûr et réversible. Les agents continuent de travailler, les clients continuent de recevoir des réponses et la direction a la certitude que la migration Zendesk® vers Zendesk® sera une réussite.
Avec une démonstration Help Desk Migration , vous ne devinez pas, vous voyez le système fonctionner avant même que cela n'ait d'importance.
Sans carte de crédit Config rapide
Comment fonctionne la migration Zendesk® vers Zendesk®
Préparer · Cartographier · Tester · Mettre en production · Valider
Préparer
Un transfert Zendesk® vers Zendesk® réussi commence par une préparation minutieuse :
- Sélectionnez l'instance Zendesk® cible (fusion ou division) en fonction des besoins de l'entreprise.
- Alignez les marques, les formulaires, les groupes et les SLA pour qu'ils correspondent à l'architecture prévue.
- Confirmez l'accès de niveau administrateur aux instances Zendesk® source et cible.
- Définissez le périmètre de la migration : historique complet ou uniquement les tickets récents et ouverts.
- Répertoriez tous les champs personnalisés, macros, déclencheurs et automatisations, y compris les dépendances.
- Identifier les tickets archivés, les tickets fusionnés, les utilisateurs suspendus et les cas particuliers pouvant nécessiter un traitement personnalisé.
Carte
Le mappage définit précisément le comportement des données après la migration :
- Billets : statuts, marques, formulaires, destinataires.
- Utilisateurs et organisations : déduplication, associations multi-entreprises, gestion des utilisateurs suspendus.
- Champs personnalisés : normalisation des listes déroulantes, comportement des balises et gestion des champs à formulaires multiples.
- Règles : les macros sont entièrement migrées ; les automatisations sont désactivées pendant la migration et réactivées manuellement.
Test
Les tests confirment l'exactitude et renforcent la confiance :
- Migrer 20 tickets réels, y compris des cas particuliers comme les tickets multi-marques, les utilisateurs fusionnés et les suivis.
- Vérifiez la cohérence des conversations, des pièces jointes, des champs personnalisés et des statuts.
- Affinez le mappage en fonction des résultats et relancez les migrations de démonstration si nécessaire.
Mise en service
La migration complète s'effectue tandis que votre instance Zendesk® source reste en ligne :
- La migration delta permet de transférer les nouvelles réponses et les mises à jour des agents lors de la bascule.
- Les agents poursuivent leurs activités et les clients continuent de recevoir de l'aide.
- La migration s'effectue en arrière-plan afin de garantir une continuité opérationnelle totale.
Valider
Il s'agit d'un processus contrôlé de migration des données du service client, et non d'un pari en libre-service :
- Rapprocher les nombres de tickets et d'utilisateurs pour confirmer que toutes les données ont été migrées correctement.
- Reconstruisez les rapports Explore, car les données de reporting ne sont pas migrées par défaut.
- Réactivez intentionnellement les automatisations pour éviter les déclenchements inattendus.
- Archivez l'instance source à des fins de conformité ou d'archivage.
- Il s'agit d'un processus contrôlé de migration des données du service client, et non d'un pari en libre-service.
Problèmes courants de migration Zendesk® vers Zendesk® que nous prenons en charge
Problème 1 : Les marques inactives ou par défaut entraînent des erreurs d’acheminement
Problème:
Les marques inactives sur l'instance source peuvent être remplacées par défaut par une marque sélectionnée sur l'instance cible, ce qui peut entraîner un mélange de tickets entre les marques.
Solution:
Le service Help Desk Migration filtre et associe les marques inactives selon vos exigences, garantissant ainsi que les tickets soient attribués à la marque appropriée sans confusion.
Problème n° 2 : Les champs déroulants génèrent des balises inutiles
Problème:
Les champs déroulants présents dans plusieurs formulaires de tickets peuvent créer des étiquettes indésirables après la migration.
Solution:
Adaptez le mappage pour supprimer les champs non pertinents et désactivez éventuellement le balisage automatique du contenu, réduisant ainsi le bruit des balises tout en préservant les données critiques.
Problème n° 3 : Les billets archivés n’apparaissent pas dans les vues
Problème:
Les billets archivés existent dans le système mais n'apparaissent pas dans les affichages par défaut, ce qui suscite des inquiétudes quant à la possibilité que des « billets aient été perdus »
Solution:
Tous les tickets archivés sont inclus dans la migration des données, et nous vous guidons pour les confirmer via une recherche par identifiant ou par caractères génériques.
Problème n° 4 : Incohérences entre les tickets résolus et les tickets clôturés
Problème:
Les tickets résolus peuvent se fermer automatiquement après 28 jours , ce qui a un impact sur le suivi de leur statut.
Solution:
Nous prenons en compte le comportement d'automatisation Zendesk® et vous pouvez associer les statuts des tickets afin que l'historique reste précis, tout en vous permettant de contrôler les automatisations futures.
Problème n° 5 : Différences de fuseaux horaires / Conversion UTC
Problème:
L'API utilise le fuseau horaire UTC ; les horodatages des tickets peuvent apparaître décalés d'une heure après la migration.
Solution:
Notre service gère la normalisation des fuseaux horaires et assure une vérification post-migration afin de garantir que les horodatages correspondent aux paramètres locaux de votre équipe.
Problème 6 : Limitations des agents légers
Problème:
Les agents Light ne peuvent pas être propriétaires de tickets clôturés ni publier de commentaires publics, ce qui limite la manière dont les tickets apparaissent dans les affectations.
Solution:
Nous attribuons au préalable les tickets et commentaires des agents légers aux agents appropriés, évitant ainsi les lacunes en matière de responsabilité.
Problème 7 : Restrictions d’adresse IP ou erreurs de connexion
Problème:
Les outils de migration peuvent échouer si les instances Zendesk® source ou cible restreignent certaines adresses IP.
Solution:
Nous vous accompagnons dans place de listes blanches d'adresses IP et la configuration sécurisée afin de prévenir les pannes.
Problème n° 8 : Incohérences dans l’index de recherche Zendesk®
Problème:
Le nombre de billets affiché lors des recherches peut ne pas correspondre au nombre réel de billets.
Solution:
L'assistant Help Desk Migration valide les comptes via les données de l'API, et nous pouvons vous aider à réindexer si nécessaire.
Numéro 9 : Statuts de tickets personnalisés
Problème:
Seuls les statuts personnalisés ou par défaut peuvent être associés simultanément.
Solution:
Nous guidons le client dans la désactivation des statuts personnalisés et la reconnexion du compte, en assurant un mappage correct des statuts de tickets .
Exemples de réussite de migrations Zendesk® vers Zendesk®
UrbanYou a conservé plus de 200 000 tickets après la consolidation des comptes
Industrie:
Services à domicile
Problème:
UrbanYou avait besoin de transférer plus de 200 000 tickets, contacts, pièces jointes, notes et contenus de la base de connaissances historiques d'un ancien compte Zendesk® vers un nouveau compte créé après son acquisition, mais les outils natifs de Zendesk®ne conservaient pas suffisamment de détails.
Comment nous avons résolu le problème :
UrbanYou a effectué une migration de démonstration gratuite afin de vérifier l'intégrité des tickets, puis a procédé à une migration entièrement automatisée avec l'assistance d'experts guidant chaque étape.
Résultat:
L'intégralité du contexte d'assistance historique, y compris les tickets, les pièces jointes et les notes, a été migrée sans interruption, offrant aux agents un accès immédiat à l'historique client.
« La migration de nos données Zendesk® avec Help Desk Migration s'est déroulée sans le moindre problème. »
Noga Edelstein
Co-fondatrice d'UrbanYou
Roland Corporation a réalisé une consolidation complexe d'instances pour une plateforme de support globale
Industrie:
Instruments électroniques et de musique
Problème:
Roland devait consolider les données du service client d'une instance Zendesk® régionale en une instance globale centrale afin d'unifier les opérations de support, une tâche impliquant les tickets, les contacts, les entreprises, les agents et les groupes.
Comment nous avons résolu le problème :
Help Desk Migration a appliqué une combinaison de processus de migration automatisés et personnalisés, cartographiant soigneusement les entités clés et préservant la structure du flux de travail entre les comptes.
Résultat:
Une consolidation sophistiquée Zendesk® vers Zendesk® a été réalisée avec succès, toutes les données critiques étant préservées et la continuité du support maintenue.
« Honnêtement, j'ai été très agréablement surpris par la réactivité de l'entreprise. Je me demandais même si je dormais ! J'ai obtenu des réponses à pratiquement toutes mes questions en quelques heures seulement, malgré le décalage horaire. »
Paul McCabe,
vice-président de l'expérience client mondiale chez Roland Corporation
Ozonics LLC a effectué une migration en une nuit vers un Zendesk® fonctionnel
Industrie:
Produits de plein air / de consommation
Problème:
Ozonics LLC avait besoin d'un moyen rapide et fiable de migrer son système de support existant vers Zendesk® et de le rendre pleinement opérationnel dès le jour ouvrable suivant.
Comment nous avons résolu le problème :
L'équipe Help Desk Migration les a accompagnés lors d'une démonstration et d'une migration complète, permettant à Ozonics de préconfigurer Zendesk® et d'effectuer le transfert pendant la nuit.
Résultat:
Le lendemain matin, Zendesk® était pleinement fonctionnel avec toutes les données historiques, éliminant ainsi les temps d'arrêt et les ressaisissements manuels.
« La migration s'est déroulée comme prévu, nous n'avons constaté aucun problème dans les données transférées. »
Stacey Hippen,
directrice des opérations chez Ozonics LLC
Migration du Centre d'aide (Base de connaissances)
Help Desk Migration transfère les articles, les traductions, la hiérarchie, les pièces jointes et les métadonnées entre les centres d'assistance Zendesk® tout en respectant les limitations de la plateforme. Suivez les instructions ci-dessous pour garantir une migration complète et sans erreur.
- Le rôle d'administrateur du guide est requis pour tout le contenu du Centre d'aide.
- Accès à toutes les marques en cours de migration.
- Autorisation de gérer les langues et les paramètres régionaux.
- Accès à la consultation des articles archivés ou en brouillon s'ils nécessitent une migration.
- Chaque marque doit être migrée séparément en utilisant son URL de marque.
- Les migrations multimarques sont prises en charge, mais suivies individuellement.
- Si des articles de marques différentes partagent des identifiants ou des slugs, ils sont renommés lors de la migration afin d'éviter les conflits.
- La langue par défaut doit être identique entre la source et la cible.
- Correspondance univoque uniquement entre les paramètres régionaux. Plusieurs paramètres régionaux sources ne peuvent pas être associés à un seul paramètre régional cible.
- Les paramètres régionaux supprimés dans le code source peuvent encore exister dans l'API ; leur migration échouera.
- Les noms de langue de l'interface utilisateur Zendesk® peuvent différer des codes API (par exemple, fr-fr → Français, fr → Français (France)). Vérifiez dans Administration de la base de connaissances → Paramètres → Paramètres de langue.
- Les articles sans langue par défaut sont ignorés, sauf s'ils sont attribués manuellement ou via les paramètres de migration.
- Certaines localisations peuvent être ignorées si elles ne sont pas nécessaires.
- Articles en version préliminaire et publiés : La migration préserve l’État. Les versions préliminaires restent des versions préliminaires ; les articles publiés restent publiés.
- Articles archivés : impossible de les migrer. Veuillez les restaurer en tant que brouillon ou les publier au préalable.
- Dossiers et sections : les articles sans dossier sont déplacés vers un dossier par défaut. Les limites de sections/catégories et les profondeurs d’imbrication maximales sont conservées, mais doivent être vérifiées pour éviter les erreurs silencieuses.
- Articles triés et épinglés : l’ordre est préservé dans la mesure du possible ; les positions personnalisées peuvent nécessiter un ajustement après la migration.
- Les images, les fichiers, les balises et la mise en forme sont migrés tels quels.
- L’intégration de vidéos nécessite l’activation du contenu non sécurisé dans Zendesk®.
- Les liens à l'intérieur des articles sont mis à jour si l'option « Mettre à jour les liens croisés » est activée ; sinon, les redirections doivent être configurées manuellement.
- Les étiquettes et les marquages sont conservés.
- Les champs personnalisés des articles peuvent nécessiter un mappage ; les champs non pris en charge sont ignorés.
- Attribution des auteurs : les auteurs originaux sont conservés si des utilisateurs existent dans la cible ; sinon, la migration attribue l’utilisateur de l’API.
- Les dates de création et de mise à jour des articles sont conservées dans la mesure du possible.
- La mise à jour des liens croisés préserve les liens internes.
- Des redirections sont nécessaires si les liens croisés sont désactivés.
- Les identifiants sont renommés automatiquement si des doublons existent dans le centre d'aide cible.
- La migration est idempotente si les mêmes articles sont migrés à nouveau : les articles mis à jour écrasent les versions précédentes.
- Les articles supprimés ou les traductions retirées de la source ne sont pas automatiquement supprimés de la cible.
- Fournissez une liste d'articles pour la migration sélective. Si elle contient moins de 20 articles, vous pouvez effectuer cette opération dans une démo à l'aide de données personnalisées.
- Articles archivés (restaurer d'abord l'état de brouillon ou publié).
- Données du champ de canal.
- Tickets indésirables (onglet suspendu).
- Certains champs personnalisés ne sont pas pris en charge.
- Le contenu nouvellement migré peut mettre un certain temps à apparaître dans les résultats de recherche.
- Des retards d'indexation sont normaux et à prévoir après une migration.
- Articles archivés : même les articles personnalisés ne peuvent pas être migrés. Pour les inclure, vous devez d’abord les restaurer en tant que brouillons ou articles publiés.
- Données du champ Canal : Zendesk® ne permet pas la migration vers le champ Canal, ces informations ne peuvent donc pas être déplacées vers le champ par défaut.
- Tickets indésirables : les tickets de l’onglet « Suspendus » ne sont pas migrés.
Ne devinez pas. Validez votre migration Zendesk® vers Zendesk® sans interruption de service
Zendesk® vers Zendesk® :
Détails techniques importants
- Mappage des formulaires : Les formulaires de tickets peuvent être mappés entre la source et la cible.
- Champs de liste déroulante : les valeurs des listes déroulantes d’autres formulaires sont automatiquement ajoutées comme balises par Zendesk®. Ce comportement est inévitable.
- Mappage personnalisé : les champs inutiles peuvent être exclus afin de réduire le nombre de balises.
- Désactivation des balises : Zendesk® peut désactiver le balisage automatique ; les balises automatiques basées sur le contenu (Guide) peuvent également être désactivées, mais les balises des champs déroulants restent affichées sauf si elles sont supprimées du mappage.
- Les billets ne peuvent rester au statut « Nouveau » que s'ils ne sont pas attribués.
- Lorsqu'un nouveau ticket est attribué à l'agent par défaut, Zendesk® change automatiquement son statut en Ouvert.
- Par conséquent, le statut « Nouveau » est exclu du mappage de migration vers Zendesk®.
- Cartographie : Seuls les statuts par défaut ou personnalisés sont affichés pour la cartographie, jamais les deux en même temps.
- Passage aux statuts par défaut : pour associer les statuts par défaut, désactivez les statuts personnalisés dans votre compte et reconnectez-vous.
- Comportement des tickets : les tickets ayant un statut personnalisé sont traités comme des tickets fermés ; ils conservent toutes les caractéristiques des tickets fermés (impossible de les modifier, ils restent dans la catégorie « Fermé ») même si des automatisations existent, mais leur nom de statut ne change pas.
- Cartographie automatisée : tous les déclencheurs sont migrés.
- Détails consultables : Chaque condition et action est affichée pour vérification.
- Important : Si une action quelconque est omise, le déclencheur échouera après la migration.
- Disponible pour — définit les rôles qui peuvent utiliser la macro.
- Titre — le nom de la macro.
- Corps — le contenu ou les instructions appliqués par la macro.
- Actions — toutes les actions de la macro sont explicitement mappées. Si une action est omise ou non mappée, la macro échouera après la migration.
- Macros : statut actif/inactif, catégorie ou groupe. Par défaut, toutes les macros sont migrées.
- Déclencheurs : statut actif/inactif ou catégorie. Par défaut, tous les déclencheurs migrent.
Elvira Azymova
Elvira est une experte reconnue help desk migration et une figure de proue de notre équipe Ventes et Support. Forte de plus de 4 ans d'expérience et de plus de 2 000 migrations réussies à son actif, elle se spécialise dans la gestion de migrations de données d'entreprise à enjeux élevés, en veillant à l'intégrité totale des données et à la continuité opérationnelle.
Migration simplifiée Zendesk vers Jira Service Management
Migrez vos dossiers clients de Zendesk vers Jira Service Management en quelques clics. Notre solution prend en charge la migration pour que vous puissiez vous concentrer sur l'essentiel : répondre aux demandes de vos clients.
Explorez d'autres guides utiles sur la migration de données
Vous souhaitez en savoir plus ? Nos ressources mises à jour proposent des guides précieux pour améliorer le service client et gérer la migration des données du support technique. Consultez-les dès maintenant !
Les 11 meilleures alternatives et concurrents Spiceworks en 2026
Le 31 décembre 2021, Spiceworks a officiellement mis fin à la prise en charge de la version Desktop de….
11 Help Scout alternatives à envisager en 2026
Existe-t-il de nombreuses alternatives Help Scout ? Eh bien, les logiciels de support technique évoluent constamment et….
Comparatif des prix de 7 solutions de support technique : laquelle vous convient le mieux ?
Levez la main si vous avez récemment réfléchi aux tarifs Zendesk ! Êtes-vous à la recherche….