Migration des données pour les entreprises de services informatiques : du nombre de tickets à l’étendue complète
Commençons par un point que la plupart des équipes négligent jusqu'à ce qu'il soit trop tard : votre centre de services n'est pas un simple outil. Il renferme l'historique de toutes vos relations clients. Par conséquent, lorsque vous décidez de changer de plateforme ITSM, tout cet historique doit vous suivre.
Help Desk Migration déplace les agents et cartographie proprement vos tickets, contacts et l'historique de votre entreprise, vous assurant ainsi une intégrité complète des données ITSM.
Sans carte de crédit Config rapide
Plus de 60 000 entreprises nous font confiance
Étendue de la migration de données : Sept ensembles d’enregistrements, un projet
Avant de planifier la migration de vos données, recensez tous les types d'enregistrements présents sur votre plateforme de support. Analysez vos données actuelles pour déterminer les éléments à migrer, puis comparez vos systèmes source et cible afin d'établir un plan de correspondance précis des champs.
| Record établi | Ce que cela inclut | Que regarder dans un film |
|---|---|---|
| données du service d'assistance et du centre de services | Dossiers, tickets, conversations, statuts, étiquettes, champs personnalisés | Cela détermine le volume global du projet. Définissez d'abord son périmètre. |
| Enregistrements ITSM | Incidents, demandes de service, enregistrements de changement, enregistrements de problème, politiques SLA, chaînes d'approbation, éléments de configuration | Trois de ces sept types nécessitent généralement un remappage ou une reconstruction, et non un transfert direct |
| Base de connaissances | Articles, catégories, dossiers, visibilité interne vs. publique, pièces jointes aux articles | Les paramètres de visibilité ne correspondent pas toujours à un équivalent sur la plateforme cible |
| Données clients et contacts | Entreprises, contacts, sites, hiérarchie organisationnelle, structure des agents et des groupes | La structure des groupes doit souvent être redéfinie lorsque la plateforme cible modélise les équipes différemment |
| Médias et pièces jointes | Images intégrées, pièces jointes | Le volume de pièces jointes peut allonger votre fenêtre de migration davantage que le nombre de tickets |
| Historique des e-mails | Flux entrants et sortants liés aux tickets, préservation des en-têtes | La préservation des en-têtes dépend de ce que la plateforme source stocke réellement, et non seulement de ce qu'elle affiche |
| Journaux d'appels et enregistrements | Relevés téléphoniques et liens d'enregistrement joints aux billets | Il s'agit généralement d'un lien vers un système téléphonique, et non d'un enregistrement. Vous migrez la référence, pas l'audio. |
Note de bas de page : la couverture par ensemble d’enregistrements dépend de ce que la plateforme source expose et des modèles cibles.
Vous êtes arrivé ici en pensant uniquement aux tickets ? C’est normal. Mais une fois la liste complète affichée, l’étendue des enregistrements ITSM devient beaucoup plus claire, et rapidement. Prenons un projet typique : une migration vers Ivantiou ServiceNow.
Vous souhaitez en savoir plus sur une plateforme spécifique ? Consultez les pages Jira Service Management de Freshservice migration ou pour découvrir comment un ensemble d’enregistrements unique se comporte au sein de cette plateforme cible.
La de migration de la base de connaissances traite à elle seule de la structure et de la visibilité des articles. Vous hésitez encore entre plusieurs plateformes avant d'envisager une migration ? Commencez par consulter le guide des logiciels de support technique pour les entreprises informatiques.
Il est important de préciser que la « migration de données » englobe également deux projets qui ne sont pas abordés sur cette page. Database et d'applications concerne les systèmes internes à votre entreprise, et non le service d'assistance. La migration de terminaux ou de locataires concerne les appareils et les comptes utilisateurs, et non les incidents ou les tickets. Ces deux types de migration sont bien réels. Aucun des deux ne nécessite la procédure décrite ci-dessous.
Intégrations de migration ITSM prises en charge
Accelo
Atera
Atlas
Autotask PSA
BMCHelixITSM
BoldDesk
Chatwoot
ConnectWise
Crisp
CSV
Custify
Deskpro
DevRev
Dixa
Document360
Drift
Dynamics 365
eDesk
eGain
Enchant
Forumbee
FreeScout
Freshchat
Freshdesk
Freshservice
Front
FyneDesk
Gladly
Glassix
Gleap
GLPI
Gmail
Google Docs
Gorgias
Groove
Halo Service Solutions
HappyFox
Harmony
HelpCrunch
HelpDesk
HelpDocs
Helpjuice
Help Scout
HelpShift
HelpSpot
HubSpot Service Hub
InstantDocs
Intercom
Ivanti
Jira Service Management
Jitbit HelpDesk
Kayako
Kayako Classic
KnowledgeOwl
Kundo
Kustomer
Lansweeper
Live Agent
LiveChat
Manage Engine
Mayday
Missive
NinjaOne
Odoo Helpdesk
Oracle Service Cloud (RightNow)
osTicket
((OTRS)) Community Edition
Outlook
Paligo
Plain
Planhat
Pylon
Reamaze
Request Tracker
Respond.io
Richpanel
Salesforce Service Cloud
ServiceDesk Plus
ServiceNow
SherpaDesk
Siit
SmarterTrack
SolarWinds Service Desk
SolarWinds Web Help Desk
SparrowDesk
Spiceworks
Spiceworks Cloud
SQLite
SuperOps
SupportBee
SupportPal
Syncro
SysAid
SysAid (Cloud)
Tawk.to
TeamSupport
TeamworkDesk
Thena
Thulium
Tidio
TOPdesk
Trengo
Unthread
Vitally
Vivantio
Zammad
Zendesk
Znuny
Zoho Desk
Zoho Mail
Veuillez vérifier l'orthographe du nom ou nous laisser un message.
Les types de disques qui se vendent bien, et les trois qui se vendent rarement bien
Tous les types d'enregistrements ne migrent pas de la même manière. Les enregistrements ITSM essentiels, tels que les tickets et les pièces jointes, sont transférés avec une fidélité quasi parfaite, mais la logique opérationnelle — notamment les SLA, les chaînes d'approbation et les relations entre éléments de configuration (CI) — ne peut pas être simplement déplacée. Les plans de migration réussis doivent tenir compte du remappage personnalisé et de la reconstruction nécessaires pour ces trois types d'actifs spécifiques à la plateforme.
| Type d'enregistrement | Modèle typique | Condition |
|---|---|---|
| Incidents | Se déplace directement | La structure de billetterie de base correspond généralement à une correspondance un à un entre les plateformes |
| Demandes de service | Se déplace directement | Même schéma structurel que les incidents dans la plupart des schémas cibles |
| Enregistrements de modification | Se déplace directement | Structurellement similaires aux tickets dans la plupart des plateformes ITSM |
| Enregistrements de problèmes | Se déplace directement | Structurellement similaires aux tickets dans la plupart des plateformes ITSM |
| Champs personnalisés | Déplacement direct, sous réserve de correspondance avec le schéma | La fidélité dépend de la présence d'un champ équivalent dans le schéma cible |
| Les pièces jointes | Se déplace directement | Transfert au niveau fichier, généralement intact |
| Politiques SLA | Nécessite un remappage | Recréez manuellement vos objectifs SLA (tels que les délais de première réponse et de résolution) dans le système cible avant le transfert principal des données. Vous pouvez également conserver l'historique des indicateurs SLA sous forme de données statiques en lecture seule pour chaque ticket grâce à la personnalisation. |
| Chaînes d'approbation | Généralement reconstruit dans la cible | La plateforme calcule elle-même la logique d'approbation et le statut au lieu de les stocker sous forme d'enregistrement portable |
| Éléments de configuration | Nécessite un remappage | Les relations entre les éléments de configuration dépendent de la façon dont la CMDB cible modélise les actifs et les dépendances |
Pourquoi seulement trois types d'enregistrements posent-ils problème ? Parce que les politiques SLA et les chaînes d'approbation n'ont jamais été considérées comme des « données », mais comme de la logique. La plateforme cible recalcule les délais et les états d'approbation des SLA selon ses propres règles d'escalade et son propre moteur de workflow. On ne peut pas simplement copier une valeur d'une plateforme à l'autre et s'attendre à ce qu'elle ait la même signification. Les éléments de configuration rencontrent un problème similaire, mais sous un angle différent : les relations entre les éléments de configuration dépendent de la façon dont la CMDB cible structure les actifs et les dépendances, et cette structure correspond rarement, champ par champ, à celle de la plateforme source.
Les incidents, les demandes de service, les enregistrements de changement et les enregistrements de problème ne présentent pas ce problème. Ce sont principalement des enregistrements simples : un statut, une description, quelques champs personnalisés et quelques pièces jointes. Il suffit de préserver la structure, de réaffecter les champs lorsque le schéma ne correspond pas, et leur conversion se fait sans difficulté.
Réservez un appel d'évaluation des besoins en matière de migration
Témoignage client
e-Core a migré un client de Zendesk vers Jira Service Management
Migration Zendesk vers Jira Service Management
Tickets, contacts, agents, entreprises, pièces jointes, notes : tout a été transféré sans problème. Puis l’équipe s’est heurtée à un obstacle : l’attribution de chaque ticket à une organisation se désorganisait constamment après la migration. Ils ont donc dû développer une solution personnalisée pour la maintenir en place.
Ils ont donc divisé le travail en deux phases : d’abord les tickets résolus, puis les autres. Ce schéma se répète systématiquement lors des migrations ITSM. La majeure partie de la structure d’un centre de services reste intacte après la migration. Les exceptions concernent les éléments qu’il est préférable d’anticiper avant la mise en service, plutôt que de devoir les corriger à la hâte après.
Les tests permettent de détecter ces trois exceptions tant qu'il est encore facile et peu coûteux de les corriger. Vérifiez vos types d'enregistrements par rapport à cette matrice avant de définir le périmètre du projet, et non après.
Comment se déroule réellement la migration de données pour les entreprises de services informatiques
La migration de votre service d'assistance informatique avec Help Desk Migration suit cinq étapes claires dans l'assistant de migration en libre-service.
Connectez vos plateformes
Connectez vos plateformes source et cible dans l'Assistant de migration. Saisissez les identifiants d'accès pour les deux outils ITSM ; Help Desk Migration authentifie chaque connexion. Aucune installation ni script n'est requis. L'assistant analyse les deux schémas et liste tous les types d'enregistrements disponibles pour le transfert.
Sélectionnez vos données
Choisissez les ensembles d'enregistrements à migrer : incidents, agents, tickets, tâches et articles de la base de connaissances. Migrez l'ensemble des données ou limitez le transfert à un sous-ensemble défini : l'assistant déplace uniquement les éléments sélectionnés. C'est ici que vous définissez les limites du projet avant même qu'un seul enregistrement ne quitte la source.
Cartographiez vos champs
Associez vos champs aux schémas qui ne correspondent pas. Alignez les statuts des tickets, les priorités, les types de demandes, les agents et les champs personnalisés entre la source et la cible afin d'éviter toute erreur de correspondance. L'assistant propose automatiquement des associations par défaut ; vous pouvez ensuite ajuster les éléments nécessitant un traitement spécifique. Cette étape garantit l'intégrité référentielle lors du transfert massif d'enregistrements.
Exécuter une migration de démonstration
Effectuez une migration de démonstration gratuite avant tout engagement. L'assistant transfère un petit lot d'enregistrements afin que vous puissiez vérifier le mappage des champs, les pièces jointes et les relations sur la plateforme cible. Consultez les résultats, téléchargez les rapports et assurez-vous que tout est correctement mappé. Ajustez et relancez la démonstration autant de fois que nécessaire.
Lancer la migration complète
Lancez la migration complète une fois la démo validée. Help Desk Migration transfère tous les enregistrements sélectionnés vers la plateforme cible sans interruption de service, permettant ainsi à votre équipe de poursuivre son travail. Effectuez ensuite une migration différentielle pour transférer les tickets créés pendant la migration, puis finalisez la bascule : tout sera conservé.
Coût et durée de la migration
Le coût et le calendrier dépendent tous deux des mêmes quatre variables :
Volume record
Combien de tickets, d'incidents et de documents connexes déplacez-vous ?
Profondeur de champ personnalisée
Combien de travail de cartographie chaque champ nécessite-t-il ?
Nombre d'instances sources
Un bureau se regroupant en un seul, ou plusieurs se regroupant en un seul
disponibilité de l'API
Que votre plateforme source en expose une, ou que vous ayez besoin d'un chemin de champ personnalisé comme l'a fait Hexagon Software Group
Avec le forfait Standard de Help Desk Migration, une migration de base sans personnalisation prédéfinie coûte 100 $ pour 1 000 enregistrements, tandis que pour 10 000 enregistrements dans les mêmes conditions, le prix s'élève à 514 $, soit bien moins de dix fois le prix initial. Plus la migration est importante, moins vous payez par enregistrement ; la profondeur des champs personnalisés influe bien plus sur ce coût que le volume lui-même.
Études de cas réussies de migration de données ITSM
Une transition ITSM inter-écosystèmes
e-Core, une société de conseil et d'externalisation d'applications Atlassian basée à Porto Alegre, au Brésil, devait migrer l'un de ses clients de Zendesk vers Jira Service Desk. La database du client était volumineuse et il souhaitait la conserver intégralement, sans repartir de zéro. Help Desk Migration a divisé le transfert en deux étapes : d'abord les tickets clôturés, puis le volume restant. Une solution personnalisée a été mise en place pour que chaque ticket soit correctement associé à l'organisation après la migration. Toutes les autres données ont été transférées sans problème : tickets, contacts, agents, entreprises, pièces jointes et notes. e-Core a effectué plusieurs migrations de test avant de procéder au transfert complet, étape cruciale de validation. Leur responsable technique a confirmé que les données nécessaires avaient été importées intactes dans Jira Service Desk.
L'histoire de la migration d'e-Core
Fenêtre d'accès courte, consolidation Zendesk , instance d'un partenaire comme source
Lenovo Private Cloud Solution devait transférer rapidement un volume important de tickets depuis l'instance Zendesk d'un partenaire vers sa propre instance pour une division basée à Bucarest, en Roumanie. Au lieu d'une gestion complète, l'équipe a opté pour une solution autonome avec l'assistant de migration et a transféré le volume de tickets entre les instances en un temps record. Mais la rapidité n'était pas le seul enjeu. Lenovo avait besoin de conserver ces données historiques pour référence ultérieure, et le responsable des opérations a par la suite souligné le suivi rigoureux de l'équipe commerciale tout au long du processus.
L'histoire de la migration de Lenovo Private Cloud Solution
Une source héritée sans API
Hexagon Software Group, un éditeur britannique de logiciels spécialisés en gestion immobilière et financière, devait migrer de ReadyDesk vers Freshdesk sans connexion API côté source. Help Desk Migration a conçu une stratégie de migration sur mesure couvrant à la fois les données du service d'assistance et la base de connaissances. La préservation de l'historique des appels était cruciale. Le chiffre d'affaires d'Hexagon repose en grande partie sur les services professionnels, et non uniquement sur les licences logicielles. Le consultant senior du client a par la suite souligné que l'historique migré offrait à l'équipe un enregistrement consultable à la demande, au lieu de repartir de zéro.
L'histoire de la migration d'Hexagon Software GroupTrois problématiques distinctes se présentent ici : une migration de plateforme inter-écosystèmes, une compression du volume et des délais de traitement des données, et une source héritée sans API. Ces trois cas couvrent une bonne partie de ce à quoi ressemblera probablement votre propre migration. Qu'on l'appelle migration de données pour les prestataires de services informatiques ou migration ITSM, peu importe. Le travail reste le même : migrer l'enregistrement complet, et pas seulement le ticket.
Réservez un appel d'évaluation des besoins en matière de migration
Avant de définir le périmètre du projet : cartographiez vos propres types d’enregistrements
Voici comment ça marche : la matrice ci-dessus est le modèle de Help Desk Migration, basé sur des projets concrets et non sur des suppositions. Mais ce n’est pas encore votre modèle. Appropriez-vous-le. Adaptez-le à votre propre paire de plateformes. Abordez votre réunion de cadrage en sachant déjà où vous rencontrerez des difficultés, au lieu de les découvrir trois semaines plus tard, lorsque les corrections seront coûteuses.
| Type d'enregistrement | Modèle général | Confirmé pour votre paire de plateformes ? | Besoin d'un remappage ? | Propriétaire |
|---|---|---|---|---|
| Incidents | Se déplace directement | Oui (API prise en charge) | Cartographie standard de l'état et des priorités | Responsable du service d'assistance |
| Demandes de service | Se déplace directement | Oui (API prise en charge) | Demande de mappage des articles du catalogue | Responsable du service d'assistance |
| Enregistrements de modification | Se déplace directement | Oui (Correspondance du schéma) | Cartographie des champs Risque, type et raison | Gestionnaire du changement |
| Enregistrements de problèmes | Se déplace directement | Oui (Correspondance du schéma) | relations entre la cause première et les incidents liés | Gestionnaire de problèmes |
| Champs personnalisés | Déplacement direct, sous réserve de correspondance avec le schéma | Audit requis | Créez des champs personnalisés correspondants dans la cible | Administrateur ITSM |
| Les pièces jointes | Se déplace directement | Oui (transfert direct de fichiers) | Non (Conserver le contenu intégré et les pièces jointes) | Responsable de la migration |
| Politiques SLA | Nécessite un remappage | Reconstruire dans la cible | Recréer les cibles ; indicateurs historiques via des champs personnalisés | Responsable de la prestation de services |
| Chaînes d'approbation | Généralement reconstruit dans la cible | Reconstruire dans la cible | Configurer le moteur de workflow dans le système cible | Responsable du processus ITSM |
| Éléments de configuration | Nécessite un remappage | dépendant du modèle | Aligner les modèles d'actifs et la hiérarchie de dépendance CI | Administrateur d'actifs / CMDB |
Veuillez remplir ce formulaire. Apportez-le lors de votre démonstration gratuite de migration. Cela vous permettra d'arriver avec un plan précis plutôt qu'avec une simple supposition, et de sécuriser la discussion sur le périmètre du projet avant même qu'elle ne commence.
FAQ : Migration de données pour les entreprises de services informatiques
La migration ITSM consiste à transférer les enregistrements d'une plateforme de gestion des services informatiques (incidents, demandes de service, modifications, problèmes, SLA, chaînes d'approbation et éléments de configuration) d'une plateforme à une autre. Elle diffère d'une migration classique de support technique car la plateforme calcule plusieurs de ces types d'enregistrements à la volée au lieu de les stocker ; il faut donc généralement les remapper plutôt que de les transférer directement. Vous rencontrerez ce type de migration lors d'un changement de plateforme vers ServiceNow ou un outil ITSM concurrent.
La plupart des sources convergent vers les mêmes quatre catégories : migration du stockage, database , migration d'applications et migration vers le cloud. La migration du stockage consiste à déplacer des données entre des systèmes de stockage physiques ou virtuels. Database les déplace entre database plateformes. La migration des applications s'effectue lors du remplacement d'un système logiciel par un autre. La migration vers le cloud les déplace vers une infrastructure cloud. Aucune de ces quatre catégories ne concerne le service d'assistance. Consultez Help Desk Migrationla procédure pour obtenir des informations spécifiques à ce service.
Cela dépend du volume de vos enregistrements, de la complexité de vos champs personnalisés, du nombre d'instances sources consolidées et de la disponibilité d'une API sur votre plateforme source. À noter : un faible volume de tickets avec une logique de champs personnalisés complexe peut coûter plus cher qu'un volume important et simple, car le travail de mappage influe davantage sur le prix que le nombre de tickets. Consultez des tarifs .
Cela dépend de votre plateforme source, de votre plateforme cible et de la part de la tâche nécessitant une intervention manuelle par rapport à une gestion en libre-service. Pour les migrations de centres de services et de services informatiques (ITSM), Help Desk Migration importe les données de projet internes sur plus de 100 plateformes prises en charge, ce qui le distingue d'un outil ETL généraliste conçu pour databaseou les applications. Comparez les modes de déploiement sur la page Help Desk Migration des services de
Cela implique généralement de transférer les incidents, les demandes, les enregistrements de changement et les éléments de configuration ServiceNow d'une autre plateforme ServiceNow inversement. ServiceNow calcule en interne les SLA et l'état d'approbation ; par conséquent, la migration vers ou depuis ServiceNow nécessite généralement de remapper ces types d'enregistrements plutôt que de les transférer tels quels. la ServiceNow page de migration pour plus de détails spécifiques à chaque plateforme.
Dans le cadre ITIL : stratégie de service, conception de service, transition de service, exploitation de service et amélioration continue des services. Une migration de plateforme relève généralement de la transition de service, car elle modifie la manière dont vous fournissez les services existants sans nécessairement changer la stratégie sous-jacente. Les fonctionnalités d'assistance par l'IA de la plateforme cible interviennent de plus en plus à cette étape. Consultez la section « IA dans ITSM » pour en savoir plus sur les implications pour votre historique de migration.
Aucun fournisseur n'est la solution idéale pour toutes les entreprises de services informatiques. Tout dépend du volume de données à traiter, de la paire de plateformes et de la disponibilité des API côté source. Help Desk Migration a mené à bien des projets de migration de données de toutes tailles pour des entreprises de services informatiques, avec plus de 60 000 migrations réalisées à son actif. Comparez Help Desk Migrationles clients de à ceux de votre secteur et de votre paire de plateformes avant de prendre votre décision.
Cela dépend des plateformes ITSM concernées et des types d'enregistrements inclus. Help Desk Migration est compatible avec ServiceNow, Jira Service Management, Freshservice, Zendesk, SysAid, Ivantiet ManageEngineeDesk Plus, entre autres. consultez les études de cas publiées concernant des migrations ITSM similaires à votre configuration.
On les appelle souvent les 7 R. Ils sont issus de la migration d'infrastructures cloud : réhéberger, replatformer, racheter, refactoriser, retirer, conserver et relocaliser. Ils décrivent comment déplacer les applications et les charges de travail vers le cloud, et non comment déplacer les enregistrements du service d'assistance entre les plateformes. La migration d'un service d'assistance est un projet à part entière, avec ses propres types d'enregistrements et sa propre séquence. Découvrez comment Help Desk Migration gère cela.
La gestion des services informatiques (ITSM) englobe les pratiques de conception, de fourniture et de support des services informatiques : gestion des incidents, gestion des changements, traitement des demandes, etc. Elle s’exécute sur une plateforme dédiée, comme Jira Service Management, où ces processus sont organisés sous forme d’enregistrements structurés. Consultez la migration vers Jira Service Management pour savoir comment ces enregistrements sont transférés d’une plateforme à l’autre.
Prêt à migrer votre centre de services ITSM ?
Effectuez une migration de démonstration gratuite pour tester vos données réelles sur la plateforme cible. Aucun environnement de test, aucune donnée fictive. Vos enregistrements réels, au bon endroit, prêts à être analysés.
Planifiez une consultation de migration
Sans carte de crédit Certifié SOC 2 Plus de 40 000 migrations effectuées