Migration de données pour les fournisseurs de services gérés : votre PSA, pas vos clients
Recherchez « migration de données pour les fournisseurs de services gérés » et vous trouverez des articles à n'en plus finir sur le transfert des boîtes aux lettres clients vers Microsoft 365.
Cette page concerne votre PSA, vos tickets, votre service d'assistance : le système qui assure le fonctionnement de votre entreprise. En tant que fournisseur de services gérés (MSP), ces données appartiennent à des dizaines, voire des centaines de clients simultanément. L'isolation par client, la continuité de la facturation et une migration sans interruption sont donc primordiales. Découvrez comment fonctionne la planification de migration spécifique à votre secteur, puis appliquez-la à la migration d'un PSA pour MSP, où les enjeux sont encore plus importants.
Sans carte de crédit Config rapide
Plus de 60 000 entreprises nous font confiance
Types de migration de données : Que contient une migration PSA ?
Le passage à un système de gestion de tickets (PSA) ne se limite pas à une simple migration de tickets. En réalité, chaque ticket est lié à des tableaux de bord, des files d'attente, des champs personnalisés, des politiques de SLA et des configurations qui doivent tous être conservés après la migration. Voici le détail du processus, en commençant par les données du service d'assistance, dans l'ordre où la plupart des fournisseurs de services gérés (MSP) les traitent :
| Record établi | Ce que cela inclut | Que regarder dans un film | Note d'isolation par client |
|---|---|---|---|
| Assistance technique et tickets PSA | Dossiers, tickets, fils de discussion, forums, files d'attente, statuts, étiquettes, champs personnalisés | Les structures des panneaux et des files d'attente correspondent rarement à une seule d'un quai à l'autre | Les billets doivent conserver la relation avec l'entreprise ou le client approprié |
| Saisie des heures et contrats | Journaux de temps, enregistrements de contrats, configurations, références de facturation | L'État facturant n'est généralement pas inclus dans le dossier médical (voir ci-dessous) | Les termes du contrat restent spécifiques à chaque client et ne sont pas applicables à plusieurs clients |
| Base de connaissances | Articles, catégories, visibilité par client versus visibilité interne, pièces jointes aux articles | Les paramètres de visibilité nécessitent une décision, et non pas seulement une règle de cartographie | Les articles partagés nécessitent une décision explicite quant aux clients qui peuvent y accéder |
| Données clients et contacts | Entreprises, contacts, sites, hiérarchie organisationnelle, structure des agents et des groupes | C'est la base sur laquelle repose le reste de la migration | Où l'isolement réussit ou échoue en premier |
| Médias et pièces jointes | Images intégrées, pièces jointes, limites de taille et de conservation | Les limites de taille des cibles peuvent être plus strictes que celles de la source | Les pièces jointes héritent de l'isolation du ticket ou de l'enregistrement auquel elles appartiennent |
| 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 varie considérablement selon la paire de plateformes | Les fils de discussion restent isolés tant que le ticket parent l'est |
| Journaux d'appels et enregistrements | Relevés téléphoniques et liens d'enregistrement joints aux billets | Les liens d'enregistrement pointent parfois vers un système tiers qui se déplace séparément | Même dépendance que les pièces jointes |
Il s'agit de sept ensembles d'enregistrements, et non d'un seul. Les tickets constituent l'élément central : ils représentent la plus grande quantité, et il est facile de confondre un changement de PSA avec une migration de tickets. Cependant, chacun des six autres ensembles d'enregistrements bénéficie d'une isolation spécifique à chaque client afin de le protéger lors de son déplacement. Les entrées de temps et les contrats ont une incidence financière que les tickets n'ont pas. Les données client sont la base sur laquelle repose tout le reste. Même des éléments aussi courants que les pièces jointes et les journaux d'appels héritent de leur isolation du ticket ou de l'enregistrement auquel ils sont liés. Aucun d'entre eux n'est optionnel, même si personne ne les a mentionnés au départ.
Ce qui sera effectivement transféré dépendra des fonctionnalités déployées par votre plateforme source et de celles que votre plateforme cible est capable de gérer. Ce tableau vous sert de document de cadrage à évaluer avant tout engagement.
Plateformes de migration prises en charge pour les entreprises MSP
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.
Pourquoi l'isolation par client est la véritable exigence, et non le nombre de tickets
L'isolation n'est pas une fonctionnalité que l'on peut simplement activer. Elle dépend de la manière dont les données sont mappées et vérifiées lors de la migration. C'est ce qui distingue la migration d'un service d'assistance MSP d'un projet mono-locataire : les données appartiennent à plusieurs clients, le mappage et la validation doivent donc être effectués pour chaque client, et non une seule fois pour l'ensemble des données.
Ce seul fait rallonge considérablement la durée d'un projet, bien plus que le volume de données lui-même. Une migration concernant 40 clients avec des volumes de données modérés peut nécessiter plus de temps de définition du périmètre et de validation qu'une migration pour un seul client avec un nombre d'enregistrements beaucoup plus important. Chaque client requiert une analyse et une validation spécifiques du mappage avant la mise en production.
L'isolation n'est pas un service offert automatiquement par une plateforme. Elle résulte de choix effectués lors de la cartographie et est confirmée par une validation pour chaque client avant la migration ; elle ne tient pas pour acquise simplement parce que les deux plateformes affichent le terme « multitenant » sur leurs pages marketing.
Voici à quoi ressemble une cartographie délibérée dans Autotask PSA
À quoi ressemble concrètement une approche « délibérée » ? Dans Autotask PSA, chaque contact doit être associé à une entreprise. Impossible de contourner le système. Les contacts individuels de votre système source sont automatiquement rattachés à une entreprise lors du mappage, sans aucune gestion autonome.
Autotask PSA ne vous permet pas non plus de modifier l'entreprise d'un contact après sa création, c'est précisément pourquoi une migration de démonstration pour vérifier l'attribution de l'entreprise est plus importante ici, en particulier si vous fusionnez des comptes.
Côté reporting, la validation s'effectue via le tableau de bord en temps réel de l'Assistant de migration, qui suit les tickets, les agents, les contacts et les entreprises comme des entités distinctes pendant le transfert. Un rapport final détaille les éléments transférés, ceux qui ne l'ont pas été et les raisons de ces transferts. Rien n'est automatisé : il s'agit d'une règle de mappage et d'un tableau de bord consultés manuellement, une affirmation moins ambitieuse, mais plus réaliste, que « l'isolation est intégrée ».
Voici à quoi ressemble le mappage par client : Migration depuis ConnectWise
Prenons ConnectWise l'exemple concret de ConnectWise migration est regroupé au sein d'une entreprise, elle-même divisée en sites pour les clients multi-sites. Ces relations doivent donc être correctement cartographiées pour chaque client.
Cela devient d'autant plus important lorsque la plateforme source regroupe plusieurs clients sous un même enregistrement d'entreprise. Il s'agit d'un problème à résoudre avant le début de la migration, et non pendant son exécution. Aucun outil ne permet de séparer automatiquement les données clients mélangées ; cela requiert une intervention humaine, une décision et une cartographie rigoureuse. Cette même rigueur s'applique à la migration de données pour les sociétés de services informatiques en général ; l'isolation n'est pas une spécificité des fournisseurs de services gérés, mais elle revêt ici une importance accrue.
Un autre mythe à déconstruire : le multitenant est une fonctionnalité du produit, et non le résultat d'une migration. Une plateforme multitenant peut héberger des clients distincts sans qu'ils interagissent entre eux pendant son exécution. Cela ne dit rien sur la destination des données lors d'une migration entre deux plateformes multitenant. C'est là que les arguments des fournisseurs divergent. Si quelqu'un vous propose une migration, demandez-lui de quel côté de cette lacune il parle.
Valider chaque client avant la mise en service
En pratique, la validation par client avant la bascule consiste à vérifier individuellement les enregistrements mappés de chaque client, et non à échantillonner l'ensemble des données :
Pour un fournisseur de services gérés (MSP) avec une poignée de clients, ce processus est rapide. Pour un MSP avec des dizaines ou des centaines de clients, c'est cette partie du projet qui monopolise le temps, bien plus que le transfert des données lui-même.
Il est conseillé de valider chaque client individuellement avant la migration. En cas d'erreur, vous pouvez annuler la migration du client concerné sans impacter les autres clients validés. Cela permet d'isoler les problèmes et de simplifier le contrôle de la migration globale.
Les questions de sécurité et de conformité sont des sujets prioritaires pour les fournisseurs de services gérés (MSP) qui évaluent un partenaire de migration, et c'est normal. Consultez Help Desk Migrationla politique de sécurité de ainsi que l'approche d'isolation proposée par le fournisseur pour votre migration spécifique.
Réservez un appel d'évaluation des besoins en matière de migration
Les disques PSA qui ont un prix
La migration d'un service d'assistance MSP ne se limite pas aux tickets. Un PSA conserve les données de temps et les enregistrements de contrats au même titre que les tickets, et ces deux éléments ont un impact financier que les tickets n'ont pas. Perdre la trace de l'historique d'un ticket, c'est s'exposer à des problèmes de service. Perdre la trace de la facturation d'une entrée de temps, et trois semaines après la migration, on se retrouve avec une partie des heures facturables du mois précédent qui n'ont jamais été facturées. Tout dirigeant de MSP vous le dira : ce ne sont pas des situations comparables.
| Type d'enregistrement | Se déplace directement | Cartographie des besoins | Conséquences sur la facturation |
|---|---|---|---|
| Billets | Oui | Au niveau du terrain, généralement simple | Non |
| Entrées horaires | Comme les archives | Oui, la structure varie selon la paire | Oui |
| Contrats | Partiellement | Voir l'espace réservé ci-dessous | Oui |
| Configurations | Partiellement | Cela dépend du modèle d'actif | Parfois |
| Entreprises | Oui | Isolation critique, voir ci-dessus | Non |
| Contacts | Oui | Lié à la cartographie de l'entreprise | Non |
| Sites | Oui | Lié à la cartographie de l'entreprise | Non |
| Politiques SLA | Rarement en tête-à-tête | Généralement reconstruit, non déplacé | Non |
| Champs personnalisés | Non | Configuration manuelle sur la cible | Parfois |
| Les pièces jointes | Oui | La taille et les limites de rétention varient | Non |
Saisie des heures vs. État de facturation
Les saisies de temps sont généralement migrées en tant qu'enregistrements, mais pas en tant qu'état de facturation, pour une raison structurelle : le statut de facturation se trouve généralement dans la couche financière de la plateforme, et non dans le ticket ou la saisie de temps elle-même. L' Autotask PSA l'explique bien. Une saisie de temps associée à un ticket doit être approuvée et validée avant de devenir une ligne facturable. Les tâches effectuées et leur durée sont correctement migrées avec l'enregistrement. En revanche, la question de savoir si une personne a déjà approuvé, validé ou facturé la tâche est distincte.
Une facturation qui est généralement prise en compte dans le flux de travail de facturation propre à la plateforme cible plutôt que d'être transférée automatiquement.
Options de l'assistant et nuances de la plateforme
Help Desk Migration mentionne l'option « Migrer les entrées de temps » dans l'assistant de migration. Cette option permet de transférer les enregistrements utilisés par les agents pour consigner leur temps sur les tickets. Il s'agit d'une option prise en charge et fonctionnelle, et non d'une demande de développement spécifique. Cependant, la description publiée ne précise pas si les statuts (approbation, validation ou facturation) sont transférés avec la migration pour vos plateformes respectives.
Il s'agit d'une lacune légitime dans les informations publiques, considérez donc le comportement général de l'état de facturation décrit ci-dessus comme fiable et posez directement la question relative à l'indicateur spécifique à cette paire à votre spécialiste en migration.
Les contrats en tant qu'objets personnalisés
Les contrats sont traités de la même manière. Ni ConnectWise PSA ni Autotask PSAne les incluent comme type d'enregistrement standard dans leur liste de champs publiée. La documentation de ConnectWise PSA couvre les membres, les contacts, les entreprises et les tickets. Celle d' Autotask PSAcouvre les agents, les entreprises, les contacts et les tickets. Les contrats relèvent de la migration des objets personnalisés, au même titre que les actifs et les garanties, et sont gérés par les Services Professionnels plutôt que par le flux de mappage de champs standard.
En résumé : les contrats ne sont pas automatiquement inclus dans la migration de vos tickets. Prévoyez un budget spécifique pour eux, en tant que projet à part entière.
Structure de l'entreprise au contact
Help Desk Migration transfère les tickets et les enregistrements de contacts entre les plateformes PSA, préservant ainsi la structure entreprise-contact qui garantit la séparation des dossiers de chaque client. La réconciliation de la facturation est traitée comme une étape distincte du transfert des enregistrements sous-jacents. Si votre évaluation dépend du comportement précis des indicateurs de facturation pour votre paire de plateformes, il est conseillé de le vérifier directement avant de définir le périmètre de la migration.
Consultez la Autotask PSA documentation relative à l'importation des données pour obtenir des informations spécifiques à la plateforme.
Migration à faire soi-même, gérée ou personnalisée : comment choisir sa migration pour les fournisseurs de services gérés
Il existe trois façons de réaliser la migration du service d'assistance pour les opérations MSP, et celle qui vous convient le mieux dépend davantage du nombre de clients que du volume d'enregistrements :
Assistant de migration, libre-service
Idéal pour les petits fournisseurs de services gérés (MSP) avec un nombre restreint de clients, migrant une seule paire de plateformes bien prises en charge sans configuration complexe par client. Vous définissez le périmètre des champs, effectuez une migration test, l'analysez, puis lancez la migration complète.
Service géré
La plupart des projets MSP adoptent cette approche par défaut, car la cartographie client par client pour des dizaines, voire des centaines de clients, nécessite un dialogue, et non le simple remplissage d'une liste de contrôle. C'est le Help Desk Migrationpar du service de migration gérée proposé : nous définissons le périmètre du projet avec vous, élaborons la cartographie, effectuons une migration test pour validation, puis prenons en charge la migration.
Conseil
Pour les cas plus complexes : données sources inhabituelles, objets personnalisés, plusieurs plateformes sources à consolider simultanément, ou un problème de séquencement parallèle à un projet côté client distinct.
Les importateurs PSA natifs méritent d'être salués. La plupart des plateformes PSA disposent d'un CSV ou natif, et pour un ensemble de données propre et bien défini provenant d'une source unique, cet outil remplit parfaitement sa fonction. Alors, en quoi un service de migration géré se justifie-t-il réellement ? Là où un importateur natif n'a pas été conçu : le mappage par client à grande échelle, le rapprochement des enregistrements de facturation entre plateformes aux modèles financiers différents, et la validation qui vérifie les données de chaque client individuellement au lieu de se baser sur un échantillon agrégé.
Imaginez deux fournisseurs de services gérés (MSP) côte à côte. Le premier gère deux clients et un volume de tickets modeste sur des plateformes bien documentées, avec une correspondance quasi parfaite. Le libre-service est alors parfaitement adapté. Le second gère 50 clients, et son nombre total d'enregistrements peut sembler inférieur sur le papier à celui du MSP à deux clients. Cela n'a aucune importance. 50 clients signifient 50 correspondances et 50 validations, car ce travail est proportionnel au nombre de clients, et non au nombre de lignes. Il ne diminue pas comme lors d'une migration mono-locataire lorsque le volume baisse.
Aucune API dans votre source ? Cela change la donne dès le départ. Certaines configurations PSA anciennes ou fortement personnalisées n'exportent qu'au format CSV, ce qui est utilisable, mais cela modifie la part du projet automatisable par rapport à celle qui reste à cartographier manuellement.
Pour une version spécifique à chaque plateforme, Halo Service Solutions la migration et ConnectWise vers Freshdesk la migration couvrent deux des paires entre lesquelles les MSP migrent le plus souvent.
Découpe sans interruption de service visible
La phase de basculement est le moment où la migration du service d'assistance pour les opérations MSP devient concrète : vous ne pouvez pas vous permettre une interruption de maintenance que vos clients remarqueront.
Cette contrainte explique pourquoi la migration s'apparente à une opération parallèle plutôt qu'à un simple basculement : les deux plateformes restent actives pendant un certain temps après l'exécution de la migration principale, et une migration Delta déplace tout ce qui est créé ou mis à jour pendant cette période : nouveaux tickets, réponses, entrées de temps, avant que la source ne soit définitivement retirée.
L'exploitation simultanée de deux plateformes a une conséquence qu'il convient d'anticiper : la gestion des tickets par les agents sur les deux systèmes pendant la période de chevauchement, et la nécessité d'un système de numérotation cohérent. Il s'agit d'une décision prise en amont, et non d'un détail réglé le jour de la migration.
Deux décisions en particulier, toutes deux prévues avant le début de la transition
Premièrement, la numérotation des tickets : la plateforme cible peut-elle conserver la numérotation de la source ou doit-elle initier sa propre séquence ?
Cela dépend vraiment de la plateforme cible. La documentation d' Autotask PSAindique que l'ID et le numéro de ticket sont des champs distincts, ce qui permet d'enregistrer le numéro source. En revanche, la documentation de ConnectWise PSA mentionne l'ID, mais pas de champ séparé pour le numéro de ticket. Par conséquent, ce dernier est reçu comme une valeur et ne correspond pas nécessairement à la séquence propre à ConnectWise. Si vos clients sont attentifs aux numéros de ticket, vérifiez ce point spécifiquement pour votre plateforme cible avant de définir le périmètre du projet. La plateforme que vous quittez n'est pas un indicateur fiable de celle vers laquelle vous vous dirigez.
Deuxièmement : quand le portail client bascule-t-il ? C’est une question simple, mais aux conséquences plus importantes qu’il n’y paraît. Les clients ont cette URL dans leurs favoris et s’y sont connectés un nombre incalculable de fois. Programmer ce basculement après coup, une fois les données transférées, est précisément la façon dont une migration techniquement réussie peut se transformer en une expérience client désastreuse.
Il n'existe pas de migration PSA sans interruption de service, et quiconque prétend le contraire cherche à vous vendre quelque chose, pas à vous informer. D'après l'expérience de Help Desk Migration, la réalité est un impact quasi imperceptible pour le client. La qualité de cette migration dépend du nombre de clients, de la configuration du portail et de la façon dont la plateforme cible gère la numérotation des tickets. Un fournisseur de services gérés (MSP) dont les clients communiquent exclusivement par e-mail bénéficie généralement d'une migration plus simple qu'un fournisseur utilisant un portail client très sollicité. Un système de moins à migrer en production, un risque de dysfonctionnement en moins.
Réservez un appel d'évaluation de votre projet de migration →
Combien coûte réellement une migration MSP et combien de temps cela prend-il ?
La tarification de la migration de données pour un fournisseur de services gérés (MSP) suit une logique différente de celle d'un projet mono-locataire, et la première question qui se pose est la même : quel sera le coût et combien de temps cela prendra-t-il ? C'est une question légitime. Voici ce qui influe concrètement sur le prix :
Le nombre de clients est la variable qui distingue un projet MSP d'un projet mono-client, et il a souvent un impact plus important sur les coûts et les délais que le volume brut d'enregistrements. Une migration à faible volume répartie sur 40 clients peut s'avérer plus coûteuse et plus longue qu'une migration à volume élevé pour une seule entreprise, car le mappage et la validation sont proportionnels au nombre de clients, et non au nombre de lignes. La saisie des données et la complexité des contrats accentuent ce phénomène : un PSA avec plusieurs types de contrats et des règles de facturation détaillées par client est plus long à mapper qu'un PSA avec une structure simple, quel que soit le volume de tickets.
La présence d'une API dans votre source influe directement sur le coût et le délai. L'accès à une API implique généralement une automatisation accrue. Les sources CSVuniquement ou fortement personnalisées nécessitent généralement un mappage manuel plus important avant même le début de la migration. La tarification de Help Desk Migrationtient compte de ces variables et n'est pas forfaitaire par enregistrement.
Au lieu de tourner autour du pot, parlons chiffres. Help Desk Migration Le prix de 1 000 enregistrements coûte 100 $. La de 10 000 enregistrements coûte 514 $. Le calcul est simple : plus le volume est important, plus le prix est avantageux. C'est pourquoi 40 petites migrations par client ne sont pas aussi rentables qu'une seule grande migration pour un seul client.
Les forfaits de services s'adaptent à la complexité : Standard couvre une migration unique avec basculement brutal, Premium gère jusqu'à 50 000 enregistrements avec un support dédié, et Signature et Enterprise ajoutent la migration Delta, la migration par intervalles, la migration multithread et une équipe de compte dédiée pour les projets plus importants impliquant plusieurs clients.
Rien de tout cela ne remplace un devis. Help Desk Migration ne fixe un prix définitif qu'après une migration de démonstration gratuite qui confirme le fonctionnement du système.
Estimez le coût de votre migration en fonction du nombre de vos clients et de vos plateformes, surtout si vous êtes un petit fournisseur de services gérés (MSP) où l'autonomie des clients est souvent la solution idéale. Vous avez un plus grand nombre de clients et une plus grande complexité ? Un entretien de cadrage vous apportera une réponse bien plus pertinente qu'une estimation basée sur le volume.
Deux fournisseurs de services gérés, deux migrations, deux histoires vraies
Deux témoignages concrets de migration vers un service de partenariat client (PSA) pour fournisseurs de services gérés (MSP) sont plus convaincants que n'importe quelle promesse.
VestaTech, s'installe dans ConnectWise PSA
VestaTech, société de services informatiques et de sécurité basée à Ardooie, en Belgique, et membre du groupe Vestagroup, devait migrer environ 2 000 tickets, clients et enregistrements d'activité associés de Freshservice vers ConnectWise PSA. Avant la migration, l'équipe utilisait un script d'exportation interne et avait déjà écarté l'importation manuelle, jugée trop lourde pour un tel volume de données. Le test initial a révélé quelques erreurs mineures, que VestaTech et son équipe de support ont corrigées avant la migration complète. Après analyse des résultats, VestaTech a conclu qu'aucune autre solution n'était aussi performante. La migration de VestaTech vers ConnectWise constitue un excellent exemple pour les entreprises de services qui adoptent une solution PSA complète. Elle illustre un changement direct de plateforme plutôt qu'une fusion, une distinction importante pour la suite.
ROIcode, fusion de deux instances de support en une seule
ROIcode, une entreprise de services et de technologies de l'information basée à Denver, dans le Colorado, souhaitait fusionner ses deux systèmes de support technique distincts, Kayako Classic et Zendeskunique hébergé dans le cloud Kayako , plutôt que de les désactiver complètement. La fusion des comptes de ROIcode dans Kayakoa permis de consolider les deux sources de support technique en une seule instance, tout en préservant l'historique complet des demandes d'assistance de l'entreprise depuis le premier jour. Si votre équipe doit fusionner des comptes suite à une acquisition, plutôt que de changer entièrement de plateforme, cette étude de cas vous montre comment mener à bien ce processus.
Parcours de migration documentés vs. résultats clients
Au-delà des témoignages clients cités, Help Desk Migration a documenté et cartographié les chemins de migration pour les plateformes PSA et RMM les plus utilisées par les MSP : SuperOps, Syncroet Atera, ainsi que des guides étape par étape pour ConnectWise les migrations, Autotask PSA les migrations, la SuperOps liste de contrôle de migration des donnéeset la Halo Service Solutions liste de contrôle de migration des données.
Il est important de bien comprendre la signification de ces deux types de preuves, car les fournisseurs de services gérés (MSP) qui évaluent un prestataire remarquent lorsque la distinction devient floue. Un Help Desk Migration prend en charge cette paire de plateformes et qu'un mappage existe déjà, et non qu'un projet d'une taille ou d'une complexité particulière a été exécuté. Les deux sont importants. Ils ne remplacent pas l'un l'autre, et toute page qui les considère comme interchangeables mérite une attention particulière. témoignage client nommé, comme celui de VestaTech ou de ROIcode, est un résultat: une entreprise, une migration, un résultat, rapporté une seule fois et sans extrapolation. Un parcours de migration documenté est différent. Il indique que
L'échelle est l'autre aspect de la question de la confiance. Help Desk Migration a réalisé plus de 60 000 migrations, prend en charge plus de 100 plateformes et est conforme aux normes SOC 2 Type II et SOC 3 Ces informations ne remplacent en rien les arguments de VestaTech ou de ROIcode. Elles confirment simplement que la même rigueur dont font preuve ces deux entreprises est applicable à grande échelle, et non ponctuellement.
Avant de vous pencher sur ce sujet, commencez ici
Pour un fournisseur de services gérés (MSP), il convient de définir le périmètre de la migration client par client, et non comme un seul et même ensemble de données volumineux.
Avant de procéder à une migration, effectuez les cinq mêmes vérifications pour chaque client :
N’utilisez pas la même configuration pour tous les clients sans vérifier les différences. Un client à faible volume d’activité, avec une structure d’entreprise ou des champs personnalisés différents, peut nécessiter une configuration différente de celle d’un client beaucoup plus important.
Halo Service Solutions Les listes SuperOps de contrôle de migration de données et Help Desk Migrationde suivent la même structure : connexion, configuration, sélection, mappage et test. Utilisez ce format comme point de départ pour votre propre liste de contrôle de migration par client.
La règle est simple : un client, une revue de cartographie, une validation avant la mise en production.
Foire aux questions
Le service d'assistance d'un fournisseur de services gérés (MSP) est la couche de gestion des tickets et de support technique intégrée à un PSA (Software Service Agreement), ou parfois un outil autonome, permettant aux techniciens d'enregistrer, d'acheminer et de résoudre les demandes de nombreux clients à partir d'une seule instance. Il est généralement associé à la facturation, aux contrats et à la gestion des actifs, plutôt que de fonctionner comme un outil de support indépendant. Comparez les logiciels ITSM pour MSP si vous envisagez d'en choisir un ou de réévaluer votre situation.
Un fournisseur de services gérés (MSP) est un modèle d'entreprise : une société qui gère l'informatique d'autres entreprises dans le cadre d'un contrat. Une plateforme d'automatisation des services professionnels (PSA) est une catégorie de logiciels qui centralise la gestion des tickets, des saisies de temps, des contrats et de la facturation. La plupart des MSP utilisent une PSA plutôt qu'un service d'assistance classique, car une PSA intègre une dimension financière absente d'un service d'assistance traditionnel. Voir ConnectWise la migration pour un exemple concret.
Pour un fournisseur de services gérés (MSP), l'interface de gestion des services (PSA) sert de système d'exploitation pour la gestion des dossiers clients. Les tickets, les saisies de temps, les contrats et la facturation sont tous suivis pour un client, un site ou un contact spécifique, souvent en fonction des données RMM. Un service d'assistance s'arrête à la résolution du ticket. Une PSA poursuit le suivi jusqu'aux heures travaillées et à la facture générée. Consultez l' Autotask PSA pour une illustration concrète de cette structure.
Les différentes sources abordent ce sujet différemment, mais la plupart des frameworks divisent la migration de données en migration du stockage, database , migration des applications et migration des processus métier. Ce modèle est conçu pour l'infrastructure et non spécifiquement pour les PSA ou les enregistrements de tickets. Si c'est bien ce que vous recherchiez, la la Help Desk Migrationdocumentation sur décrit le fonctionnement au niveau des enregistrements, applicable aux données des services d'assistance.
Il n'existe pas d'outil idéal. Le choix dépend des plateformes concernées, de la présence d'une API dans la source et de la part de la migration nécessitant un mappage personnalisé ou une simple correspondance de champs. Pour les données PSA et de support technique en particulier, comparez Help Desk Migrationde les services de migration avec l'outil d'importation natif de votre plateforme source avant de prendre une décision.
Le choix de la meilleure solution dépend du nombre de vos clients, de vos besoins en facturation et suivi du temps intégrés, et du niveau d'intégration requis. Certains fournisseurs de services gérés (MSP) utilisent un PSA dédié, ConnectWise ou Autotask. D'autres optent pour un service d'assistance allégé, associé à une facturation distincte. Comparez les solutions d'assistance et de gestion des services informatiques (ITSM) conçues pour les MSP avant de considérer un PSA complet comme la seule option.
Au-delà de la solution PSA elle-même, votre suite d'outils comprend généralement un logiciel RMM pour la surveillance et la gestion à distance, une plateforme de documentation et parfois un système de gestion des tickets. Parmi les exemples de solutions PSA et RMM proposées aux MSP, citons ConnectWise PSA, Autotask PSA, Halo Service Solutions, SuperOps, Syncro, Atera, NinjaOneet SherpaDesk, ainsi que des outils ITSM conçus spécifiquement pour les MSP, comme ManageEngine ServiceeDesk Plus MSP. Consultez la SuperOps section consacrée aux concurrents pour découvrir une solution tout-en-un plus récente.
Un CRM assure le suivi du pipeline des ventes, des contacts et des transactions. Un PSA, quant à lui, suit la prestation de services : tickets, temps passé, contrats et facturation aux clients existants (et non aux prospects). Certaines plateformes combinent les deux, mais pour un MSP, le PSA sert généralement de système de référence pour les interventions de service, tandis que le CRM, s'il est utilisé, reste axé sur le développement commercial. Découvrez comment ConnectWise structure ces données.
L'expression « MSP dans le cloud » désigne généralement un fournisseur de services gérés qui prend en charge l'infrastructure cloud d'un client, ou la migration de ce client vers des services cloud comme Microsoft 365. Il s'agit d'un projet différent de celui abordé sur cette page : la migration de vos propres données PSA et de support technique, et non celle de l'environnement cloud d'un client. Pour comprendre pourquoi les MSP changent de plateforme, la version de cette question consacrée aux plateformes.
Les cadres de migration courants incluent le réhébergement, le changement de plateforme, le rachat, la refactorisation, la mise hors service, la conservation et la relocalisation ; un modèle conçu pour la migration d'infrastructures et d'applications, et non pour les données PSA ou de tickets. Si vous êtes arrivé ici suite à une recherche sur la migration vers le cloud, découvrez comment fonctionne le processus de migration au niveau des enregistrements pour les données de support technique et PSA.