Migration · 19 sept. 2026 · 12 min de lecture

Migrer depuis ManageEngine Service Desk Plus — un guide de terrain

Ce qu'il faut emporter, ce qu'il faut laisser derrière soi, et comment scripter l'export CSV de SDP vers LinaDesk sans casser l'historique des utilisateurs.

Toute migration ITSM est un petit projet d'archéologie. Dix ans d'historique de tickets, trois ou quatre générations de champs personnalisés, une règle SLA à moitié oubliée qui ne s'applique que pendant le gel de fin d'exercice fiscal — tout cela doit survivre à la bascule, faute de quoi l'équipe d'exploitation perd sa mémoire institutionnelle. Ce guide s'adresse à l'ingénieur ou au responsable IT à qui l'on a confié une instance ManageEngine Service Desk Plus (SDP) avec pour mission de la migrer vers LinaDesk avant le prochain cycle de renouvellement.

Nous partons du principe que vous disposez de SDP on-premise (Build 14xxx ou 15xxx), de quelque part entre 5 000 et 200 000 tickets historiques, d'un annuaire d'utilisateurs adossé à Active Directory, et d'une petite poignée d'intégrations email/LDAP. Si votre SDP est l'édition MSP, ou si vous utilisez l'édition Enterprise avec un module CMDB fortement renseigné, certains mappages ci-dessous devront être étendus — la nature du travail reste néanmoins la même.

Pourquoi les organisations migrent hors de SDP

Avant d'aborder la mécanique, les raisons — car elles orientent les décisions de mappage ultérieures. En pratique, les équipes qui lancent une migration SDP vers LinaDesk s'appuient sur une ou plusieurs des raisons suivantes :

La raison compte, car elle dicte ce qui est réellement transporté. Une migration motivée par la KVKK préserve généralement tout, car les auditeurs poseront des questions. Une migration motivée par les coûts laissera volontiers de côté les fonctionnalités que personne n'utilise.

Phase 1 — Découverte (2 semaines)

La phase de découverte existe pour éviter les deux pires issues d'une migration ITSM : des données manquantes qui s'avèrent importantes et des données migrées qui s'avèrent inutiles. Deux semaines paraissent longues — elles ne le sont pas.

Faire l'inventaire de l'instance SDP

Faites un inventaire honnête. Depuis la console d'administration de SDP, consignez les éléments suivants dans un tableur partagé :

Le résultat n'est pas un document — c'est une liste de décisions. Chaque élément est étiqueté conserver, reconstruire ou abandonner. Une règle empirique : si moins de trois tickets au cours des douze derniers mois ont utilisé un modèle ou un champ personnalisé, c'est un candidat à l'abandon.

Interroger l'équipe d'exploitation

La découverte ne se limite pas à une visite de la console d'administration. Asseyez-vous avec trois techniciens N1, un responsable N2 et le manager du service desk. Demandez-leur quels rapports ils ouvrent chaque semaine, quelles macros ils utilisent, et quels champs ils laissent habituellement vides. Les tableaux de bord que personne n'ouvre correspondent aux champs dont personne n'a besoin.

Cartographier les dépendances d'intégration

SDP est souvent le pivot de systèmes adjacents : un outil de supervision publie des alertes sous forme de tickets, un scanner d'actifs écrit des enregistrements de CI, une intégration paie déclenche des demandes d'intégration RH. Chacune de ces intégrations doit être soit redirigée vers l'API de LinaDesk, soit suspendue pendant la bascule. En manquer une, et le lundi matin apporte une pile de tickets orphelins.

Phase 2 — Mappage des données

Le modèle de données de SDP et celui de LinaDesk sont cousins, pas jumeaux. Le tableau ci-dessous est le mappage que nous utilisons comme point de départ ; la personnalisation ajoute toujours des lignes.

Entité SDPEntité LinaDeskRemarques
DemandeursUtilisateurs (rôle : EndUser)Mappage sur l'UPN, pas sur l'user_id interne — voir la section AD.
TechniciensUtilisateurs (rôle : Technician)Préserver l'appartenance aux groupes de techniciens en tant qu'équipes LinaDesk.
GroupesÉquipesLe Support Group de SDP correspond en 1:1 propre à une équipe LinaDesk.
RequêtesTicketsPréserver le CreatedAt d'origine en tant que CreatedAtUtc (voir l'antidatage).
Notes de requêteTicketCommentsL'indicateur privé/public se mappe directement.
Pièces jointes de requêteAttachmentsL'emplacement de stockage des blobs change ; les URL dans le corps des notes doivent être réécrites.
ActifsAssetsLe ProductType de SDP correspond à AssetCategory de LinaDesk.
Champs additionnels d'actifCustomFields (scope=Asset)Mappage de type : texte SDP → string LinaDesk ; liste déroulante SDP → enum LinaDesk.
Solutions (articles KB)KnowledgeArticlesL'indicateur de statut d'approbation est préservé.
Catégories / Sous-catégories / ÉlémentsArbre de catégories (imbriqué)LinaDesk utilise un arbre imbriqué unique ; la répartition à trois niveaux de SDP est aplatie en un chemin.
Politiques SLASlaPoliciesLes heures ouvrées sont déplacées vers WorkCalendar ; voir la section SLA.
Business RulesAutomationsRéécriture nécessaire — pas d'import direct.
Demandes de changementChangesLes chaînes d'approbation CAB sont reconstruites dans le flux ChangeApproval de LinaDesk.

Les lignes qui demandent le plus de temps d'ingénierie, d'après notre expérience, sont les champs personnalisés, les catégories et les politiques SLA. Tout le reste est mécanique.

Phase 3 — Export

SDP propose trois moyens d'extraire les données : les exports planifiés intégrés, l'API REST v3, et l'accès direct à la base de données. Les trois ont leur utilité.

L'API REST v3 pour les données structurées

L'API est la source correcte pour les utilisateurs, les techniciens, les groupes, les catégories, les politiques SLA, et toute entité dont vous avez besoin avec l'ensemble complet de ses champs. Les endpoints sont stables, respectent la pagination, et renvoient du JSON qui se mappe proprement sur notre schéma cible.

Un script PowerShell minimal pour récupérer toutes les requêtes, page par page, dans un répertoire de blobs JSON :

# requires SDP TECHNICIAN_KEY with read access
$sdpUri  = "https://sdp.internal/api/v3/requests"
$authKey = $env:SDP_TECHNICIAN_KEY
$outDir  = "C:\migration\raw\requests"
New-Item -ItemType Directory -Force -Path $outDir | Out-Null

$rowsPerPage = 100
$rowIndex    = 1

do {
  $inputData = @{
    list_info = @{
      row_count   = $rowsPerPage
      start_index = $rowIndex
      get_total_count = $true
      fields_required = @(
        "id","subject","description","status","priority",
        "created_time","resolved_time","closed_time",
        "requester","technician","group","category","subcategory","item",
        "udf_fields")
    }
  } | ConvertTo-Json -Depth 6 -Compress

  $resp = Invoke-RestMethod `
    -Uri "$sdpUri?input_data=$([uri]::EscapeDataString($inputData))" `
    -Headers @{ "authtoken" = $authKey } `
    -Method GET

  $resp.requests | ForEach-Object {
    $_ | ConvertTo-Json -Depth 12 |
      Out-File -Encoding utf8 "$outDir\req_$($_.id).json"
  }

  $total     = $resp.list_info.total_count
  $rowIndex += $rowsPerPage
} while ($rowIndex -le $total)

Les scripts équivalents pour les utilisateurs, les groupes et les actifs sont des copies structurelles. Gardez-les sous contrôle de version — vous les exécuterez au moins trois fois : une fois lors du test à blanc, une fois lors de la répétition générale, une fois lors de la bascule.

Lecture directe en base pour les pièces jointes archivées

SDP stocke les pièces jointes en dehors du corps de la requête. L'API renvoie les métadonnées mais pas les blobs. Pour récupérer les octets eux-mêmes, utilisez soit l'endpoint de pièce jointe par enregistrement (lent, mais respecte les permissions), soit une lecture directe dans la table FileAttachment de SDP couplée au répertoire disque Attachments. Sur les grandes instances (100 000+ tickets avec pièces jointes), la seconde option est la seule réaliste — prévoyez un rsync de nuit.

Phase 4 — Préservation de l'historique des tickets

Le champ le plus important de toute la migration est CreatedAtUtc. S'il retombe silencieusement sur maintenant, dix ans d'historique se compressent en une seule journée et chaque rapport SLA devient dénué de sens.

LinaDesk prend en charge la création de tickets antidatés via son endpoint d'import massif. La règle :

Chaque ticket, commentaire, transition de statut et entrée d'audit conserve son horodatage UTC d'origine. Rien dans le chemin d'import n'est autorisé à l'écraser.

Concrètement : le created_time.value de SDP est une chaîne en millisecondes Unix. Convertissez-la en UTC ISO-8601 et transmettez-la comme CreatedAtUtc. Faites de même pour resolved_time, closed_time, et l'horodatage de création de chaque note individuelle. Si une note possède un updated_time différent de son created_time, préservez les deux — les équipes d'audit vérifient parfois.

Un piège subtil : les horodatages de SDP sont stockés dans le fuseau horaire du compte mais ne sont rapportés en UTC par l'API que si l'utilisateur associé à la clé technicien a l'UTC comme fuseau d'affichage. Vérifiez ce point une fois sur trois enregistrements connus avant de faire confiance à l'ensemble de l'export.

Phase 5 — Remappage AD / LDAP

Les utilisateurs constituent presque toujours la jointure la plus difficile de la migration. SDP identifie un utilisateur en interne par son REQUESTERID. Active Directory identifie la même personne par son objectGUID. LinaDesk utilise ExternalId (que nous recommandons de faire correspondre à l'objectGUID AD).

La migration ne peut pas s'appuyer sur une seule clé primaire. La jointure que nous utilisons, par ordre de priorité :

  1. UPN (userPrincipalName). Il survit aux renommages AD et aux déplacements inter-forêts. À utiliser comme jointure principale.
  2. Adresse email. Repli si l'UPN est absent.
  3. sAMAccountName. Dernier recours, car il n'est pas garanti unique entre forêts.

Tout utilisateur qui échoue aux trois jointures va dans un fichier orphans.csv. Dans chaque migration réelle que nous avons menée, ce fichier compte entre 20 et 400 lignes — des personnes ayant quitté l'entreprise, des comptes de service jamais liés à AD, des demandeurs ayant soumis un seul ticket par email en 2018. Décidez de leur sort manuellement. Ne sautez pas cette étape : ces orphelins possèdent encore des tickets historiques et leurs noms doivent apparaître correctement dans les rapports.

Phase 6 — Remappage des politiques SLA

Le modèle SLA de SDP est un moteur de règles plat : correspondance selon les critères de la requête, application de fenêtres de réponse/résolution contre un calendrier d'heures ouvrées. Le modèle de LinaDesk est proche, mais pas identique :

L'écart le plus significatif concerne les pauses partielles. SDP permet de mettre le SLA en pause quand le ticket est En attente du demandeur. LinaDesk exige de modéliser ce même comportement via un tableau explicite PauseOnStatus dans la politique SLA. Effectuez ce mappage dans le script de migration plutôt que d'espérer que les valeurs par défaut s'alignent — chaque instance SDP que nous avons examinée comportait au moins un statut de pause non standard.

Pour une discussion plus approfondie du volet calendrier de la conception des SLA, voir l'article sur la conception des calendriers SLA — les décisions de modélisation qui y sont présentées s'appliquent directement à la reconstruction de votre calendrier dans LinaDesk.

Phase 7 — Portail, image de marque, modèles de notification

Ces éléments ne se migrent pas. Ils se reconstruisent.

Le portail self-service de SDP est une coquille fortement templatisée au style Zoho. Celui de LinaDesk est une interface moderne à base de composants, avec la même surface fonctionnelle mais une structure différente. Copiez les éléments visuels (logo, favicon, couleurs de marque) et le texte (message de bienvenue, annonces de la page d'accueil, descriptions de catégories), et laissez un designer passer deux jours à reconstruire le portail dans l'interface d'administration de LinaDesk.

Les modèles de notification suivent le même schéma. Extrayez chaque modèle d'email de SDP sous forme de HTML plus une liste de variables, puis reconstruisez-les dans l'éditeur de modèles de LinaDesk. La syntaxe de variable de LinaDesk est du type {{Ticket.Number}} ; celle de SDP est $Request.RequestID. Traduisez la syntaxe automatiquement ; relisez le contenu à la main.

Phase 8 — La marche en parallèle sur quatre semaines

Basculer en un seul week-end revient à jouer à pile ou face. Faire tourner SDP et LinaDesk en parallèle pendant quatre semaines ne l'est pas — cela transforme le pile ou face en exercice d'ingénierie.

Notre séquence recommandée :

  1. Semaine -4 : LinaDesk déployé. Données historiques importées. Tous les techniciens N1 disposent d'un identifiant et ont suivi une session de formation de 90 minutes. Le routage des emails pointe encore vers SDP.
  2. Semaine -3 : des réimports nocturnes tournent contre l'API delta de SDP, maintenant LinaDesk à moins de 24 heures de SDP. Les techniciens sont invités à vérifier ponctuellement dix nouveaux tickets par jour dans LinaDesk et à signaler les bugs. Le portail reste éteint.
  3. Semaine -2 : quinze pour cent des emails entrants sont routés vers LinaDesk. Les techniciens gèrent les deux files. Les rapports sont générés en double et comparés.
  4. Semaine -1 : cinquante pour cent des emails entrants sont routés vers LinaDesk. Le portail en bêta est ouvert à un petit groupe de demandeurs pilotes. Tout écart P0/P1 bloque la bascule.
  5. Week-end de bascule : réimport delta final. Le routage des emails passe à 100 % LinaDesk. Le portail est ouvert à tous les demandeurs. SDP passe en lecture seule ; maintenu en ligne 90 jours pour l'audit.

La période de lecture seule de 90 jours compte. Les régulateurs (et l'audit interne) posent parfois des questions qui nécessitent de voir à quoi ressemblait un ticket dans le système source à une date précise. Supprimer SDP le lendemain de la bascule est une erreur que nous avons vue commettre deux fois, et les deux fois elle s'est terminée par une conversation de mise sous garde juridique fort inconfortable.

Liste de vérification post-migration

Avant de valider :

Pièges courants

Fonctionnalités présentes dans SDP mais absentes de LinaDesk v1

La liste honnête. LinaDesk v1 ne livre pas :

Si l'un de ces éléments est structurant pour votre exploitation, réglez-le en phase de découverte, pas la semaine précédant la bascule.

Sous-estimer le périmètre de la migration des champs personnalisés

Chaque migration que nous avons examinée comportait au moins un champ personnalisé renseigné sur 60 % des tickets historiques mais sur seulement 3 % des tickets de la dernière année. Quelqu'un a cessé de l'utiliser il y a des années et personne ne l'a supprimé. Migrez-le quand même — une donnée orpheline reste une donnée visible en audit.

Faire confiance à l'interface d'export « plage de dates » de SDP

L'interface d'export de SDP plafonne silencieusement les lignes à 5 000 dans certaines versions et 10 000 dans d'autres, sans aucune erreur — juste un CSV tronqué. Utilisez toujours l'API pour tout ce qui dépasse quelques centaines de lignes.

Parlons de votre migration SDP

Nous avons exécuté ce guide de bout en bout quatre fois au cours des dix-huit derniers mois. Si vous planifiez la vôtre, nous vous présenterons le modèle de découverte que nous utilisons.

Contacter l'équipe LinaDesk

Lectures complémentaires