Migrare da ManageEngine Service Desk Plus — una guida sul campo

Ogni migrazione ITSM è un piccolo progetto di archeologia. Dieci anni di storico ticket, tre o quattro generazioni di campi personalizzati, una regola SLA semi-dimenticata che si applica solo durante il blocco di fine anno fiscale — tutto questo deve sopravvivere al trasferimento, altrimenti il team operativo perde la memoria istituzionale. Questa guida è scritta per l'ingegnere o il responsabile IT a cui è stata affidata un'installazione di ManageEngine Service Desk Plus (SDP) con l'incarico di spostarla su LinaDesk prima del prossimo ciclo di rinnovo.

Diamo per scontato che abbiate SDP on-premise (Build 14xxx o 15xxx), un numero di ticket storici compreso tra 5.000 e 200.000, un archivio utenti basato su Active Directory e una manciata di integrazioni email/LDAP. Se il vostro SDP è l'edizione MSP, oppure gestite l'Enterprise con il modulo CMDB densamente popolato, alcune delle mappature qui sotto dovranno essere estese — la forma del lavoro resta comunque la stessa.

Perché le organizzazioni migrano via da SDP

Prima della meccanica, le motivazioni — perché plasmano le decisioni di mappatura successive. In pratica, i team che avviano una migrazione da SDP a LinaDesk arrivano a una o più delle seguenti conclusioni:

• KVKK e residenza dei dati. L'edizione cloud di SDP risiede su infrastruttura Zoho fuori dalla Turchia. La sua edizione on-premise è a posto su questo fronte, ma il modello di licenza spinge i clienti verso il cloud al rinnovo. Le organizzazioni turche vincolate dall'Articolo 9 della KVKK (trasferimento transfrontaliero) preferiscono un fornitore on-premise a controllo turco come assicurazione contro una migrazione cloud forzata.
• Traiettoria dei costi per tecnico. Il prezzo per tecnico di SDP è aumentato costantemente dal 2022, e il prezzo modulare (componenti aggiuntivi per change, project, CMDB) si accumula. Un'alternativa a licenza fissa elimina le sorprese al momento del rinnovo.
• Ergonomia dell'interfaccia e delle scorciatoie da tastiera. L'interfaccia di SDP precede gli standard di design dell'era Linear. I team i cui tecnici L1 vivono nella coda tutto il giorno lo sentono quotidianamente.
• Distribuzioni air-gap o su reti classificate. I clienti governativi e della difesa non possono eseguire i componenti aggiuntivi cloud di SDP; ogni funzionalità che desiderano deve girare all'interno del loro perimetro.

La motivazione conta perché detta cosa viene portato con sé. Una migrazione guidata dalla KVKK tipicamente conserva tutto, perché gli auditor lo chiederanno. Una migrazione guidata dai costi lascerà volentieri indietro le funzionalità che nessuno usa.

Fase 1 — Discovery (2 settimane)

La fase di discovery esiste per prevenire i due peggiori esiti di una migrazione ITSM: dati mancanti che si rivelano importanti e dati migrati che si rivelano spazzatura. Due settimane sembrano tante — non lo sono.

Fare l'inventario dell'installazione SDP

Fate un inventario onesto. Dalla console di amministrazione di SDP, raccogliete quanto segue in un foglio di calcolo condiviso:

• Numero totale di richieste, suddiviso per stato (Aperta, In sospeso, Risolta, Chiusa) e per anno di creazione.
• Tutti i template di richiesta in uso — inclusi quelli di cui nessuno ricorda più chi li abbia creati.
• Tutti i campi personalizzati, per modulo. Annotate il tipo di campo, se è obbligatorio e quali template lo referenziano.
• Tutte le policy SLA, con le loro definizioni di orario lavorativo, i livelli di escalation e i criteri di corrispondenza.
• Tutte le regole di automazione (Business Rules, Field & Form Rules, Custom Triggers, Time Triggers).
• Tutti i template email e le regole di notifica.
• Tutti i workflow di approvazione.
• Tutti i ruoli, con le mappature dei permessi.
• Ogni integrazione: LDAP/AD, server email, SCCM/probe, API di terze parti.

Il risultato non è un documento — è un elenco di decisioni. Ogni voce viene etichettata porta, ricostruisci o elimina. Una regola pratica: se meno di tre ticket negli ultimi dodici mesi hanno usato un template o un campo personalizzato, è un candidato all'eliminazione.

Intervistare il team operativo

La discovery non è solo un giro nella console di amministrazione. Sedetevi con tre tecnici L1, un lead L2 e il responsabile del service desk. Chiedete quali report aprono settimanalmente, quali macro usano e quali campi lasciano abitualmente vuoti. Le dashboard che nessuno apre sono i campi di cui nessuno ha bisogno.

Mappare le dipendenze di integrazione

SDP è spesso l'hub per sistemi adiacenti: uno strumento di monitoraggio pubblica avvisi come ticket, uno scanner di asset scrive record CI, un'integrazione paghe attiva richieste di onboarding HR. Ognuna di queste deve essere ripuntata verso l'API di LinaDesk oppure messa in pausa durante il cut-over. Dimenticarne una porta, il lunedì mattina, a una pila di ticket orfani.

Fase 2 — Mappatura dei dati

Il modello dati di SDP e quello di LinaDesk sono cugini, non gemelli. La tabella qui sotto è la mappatura che usiamo come punto di partenza; la personalizzazione aggiunge sempre righe.

Le righe che richiedono più tempo di ingegneria, nella nostra esperienza, sono i campi personalizzati, le categorie e le policy SLA. Tutto il resto è meccanico.

Fase 3 — Esportazione

SDP ha tre modi per far uscire i dati: le esportazioni pianificate integrate, la REST API v3 e l'accesso diretto al database. Tutte e tre hanno un loro posto.

La REST API v3 per i dati strutturati

L'API è la fonte corretta per utenti, tecnici, gruppi, categorie, policy SLA e qualsiasi entità di cui abbiate bisogno con l'intero set di campi. Gli endpoint sono stabili, rispettano la paginazione e restituiscono JSON che si mappa in modo pulito sul nostro schema di destinazione.

Uno script PowerShell minimo per estrarre tutte le richieste, pagina per pagina, in una directory di blob 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)

Gli script equivalenti per utenti, gruppi e asset sono copie strutturali. Teneteli sotto controllo di versione — li eseguirete almeno tre volte: una durante il dry-run, una durante la prova generale, una durante il cut-over.

Lettura diretta del database per gli allegati archiviati

SDP memorizza gli allegati fuori dal payload della richiesta. L'API restituisce i metadati ma non i blob. Per i byte effettivi, usate l'endpoint per allegato per singolo record (lento, ma rispetta i permessi) oppure leggete dalla tabella FileAttachment di SDP più la directory Attachments su disco. Su installazioni grandi (100k+ ticket con allegati), la seconda è l'unica opzione realistica — pianificate un rsync notturno.

Fase 4 — Conservazione dello storico dei ticket

Il campo singolarmente più importante della migrazione è CreatedAtUtc. Se torna silenziosamente al valore adesso, dieci anni di storico si comprimono in un solo giorno e ogni report SLA diventa privo di significato.

LinaDesk supporta la creazione retrodatata dei ticket tramite il suo endpoint di importazione massiva. La regola:

Ogni ticket, commento, transizione di stato e voce di audit porta il suo timestamp UTC originale. Nulla nel percorso di importazione può sovrascriverlo.

Concretamente: il created_time.value di SDP è una stringa Unix in millisecondi. Convertitela in UTC ISO-8601 e passatela come CreatedAtUtc. Fate lo stesso per resolved_time, closed_time e per il timestamp di creazione di ogni singola nota. Se una nota ha un updated_time diverso dal suo created_time, conservate entrambi — i team di audit a volte lo verificano.

Una trappola sottile: i timestamp di SDP sono memorizzati nel fuso orario dell'account, ma vengono riportati dall'API in UTC solo se l'utente della chiave tecnico ha UTC come proprio fuso orario di visualizzazione. Verificate questo una volta su tre record noti prima di fidarvi dell'intera esportazione.

Fase 5 — Ri-mappatura AD / LDAP

Gli utenti sono quasi sempre il join più difficile della migrazione. SDP identifica internamente un utente tramite il suo REQUESTERID. Active Directory identifica la stessa persona tramite il suo objectGUID. LinaDesk usa ExternalId (che raccomandiamo di impostare sull'objectGUID di AD).

La migrazione non può basarsi su nessuna delle due chiavi primarie da sola. Il join che usiamo, in ordine di priorità:

1. UPN (userPrincipalName). Sopravvive ai rinomina di AD e agli spostamenti tra foreste. Usatelo come join primario.
2. Indirizzo email. Ripiego se l'UPN manca.
3. sAMAccountName. Ultima risorsa, perché non è garantito unico tra le foreste.

Ogni utente che fallisce tutti e tre i join finisce in un file orphans.csv. In ogni migrazione reale che abbiamo eseguito, questo file ha tra le 20 e le 400 righe — persone che hanno lasciato l'azienda, account di servizio mai collegati ad AD e richiedenti che hanno inviato un singolo ticket via email nel 2018. Decidete il loro destino manualmente. Non saltate questo passaggio: quegli orfani possiedono ancora ticket storici e i loro nomi devono comparire correttamente nei report.

Fase 6 — Ri-mappatura delle policy SLA

Il modello SLA di SDP è un motore di regole piatto: corrispondenza per criteri della richiesta, applicazione di finestre di risposta/risoluzione contro un calendario di orario lavorativo. Il modello di LinaDesk è simile ma non identico:

• Gli Operational Hours di SDP ↔ WorkCalendar di LinaDesk.
• Gli Holidays di SDP ↔ WorkCalendarHoliday di LinaDesk.
• I criteri SLA di SDP ↔ le condizioni SlaPolicyMatch di LinaDesk.
• I livelli di escalation di SDP ↔ la catena SlaEscalation di LinaDesk.

L'unico scarto significativo riguarda le pause parziali. SDP consente di mettere in pausa l'SLA quando il ticket è Waiting for Requester. LinaDesk richiede che lo stesso comportamento sia modellato come un array esplicito PauseOnStatus nella policy SLA. Fate la mappatura nello script di migrazione invece di sperare che i valori di default coincidano — ogni istanza SDP che abbiamo esaminato aveva almeno uno stato di pausa non predefinito.

Per una discussione più approfondita sul lato calendario del design SLA, vedete l'articolo sul design del calendario SLA — le decisioni di modellazione lì descritte si applicano direttamente a come ricostruite il calendario in LinaDesk.

Fase 7 — Portale, branding, template di notifica

Questi non si migrano. Si ricostruiscono.

Il portale self-service di SDP è un guscio fortemente templato in stile Zoho. Quello di LinaDesk è un'interfaccia moderna basata su componenti con la stessa superficie di funzionalità ma una struttura diversa. Copiate gli asset visivi (logo, favicon, colori del brand) e i testi (messaggio di benvenuto, annunci della homepage, descrizioni delle categorie), e lasciate che un designer dedichi due giorni a ricostruire il portale nell'interfaccia di amministrazione di LinaDesk.

Per i template di notifica vale lo stesso discorso. Estraete ogni template email da SDP come HTML più un elenco di variabili, poi ricostruiteli nell'editor di template di LinaDesk. La sintassi delle variabili di LinaDesk è in stile {{Ticket.Number}}; quella di SDP è $Request.RequestID. Traducete automaticamente la sintassi; rivedete manualmente il testo.

Fase 8 — La corsa parallela di quattro settimane

Effettuare il cut-over in un solo weekend è un lancio di moneta. Far girare SDP e LinaDesk in parallelo per quattro settimane non lo è — trasforma un lancio di moneta in un esercizio di ingegneria.

La sequenza che raccomandiamo:

1. Settimana -4: LinaDesk distribuito. Dati storici importati. Tutti i tecnici L1 hanno le credenziali e hanno completato una sessione di formazione di 90 minuti. Il routing email punta ancora a SDP.
2. Settimana -3: Ri-importazioni notturne eseguite contro la delta API di SDP, mantenendo LinaDesk entro 24 ore da SDP. Ai tecnici viene chiesto di verificare a campione dieci nuovi ticket al giorno in LinaDesk e segnalare bug. Il portale resta spento.
3. Settimana -2: Il quindici per cento delle email in entrata viene instradato verso LinaDesk. I tecnici gestiscono entrambe le code. I report vengono generati in doppio e confrontati.
4. Settimana -1: Il cinquanta per cento delle email in entrata viene instradato verso LinaDesk. Il portale in beta è aperto a un piccolo gruppo di richiedenti pilota. Qualsiasi discrepanza P0/P1 blocca il cut-over.
5. Weekend di cut-over: Ri-importazione delta finale. Il routing email passa al 100% su LinaDesk. Il portale viene aperto a tutti i richiedenti. SDP viene impostato in sola lettura; resta online per 90 giorni a fini di audit.

Il periodo di sola lettura di 90 giorni conta. Gli enti regolatori (e l'audit interno) a volte fanno domande che richiedono di vedere come si presentava un ticket nel sistema di origine in una data specifica. Eliminare SDP il giorno dopo il cut-over è un errore che abbiamo visto due volte, ed entrambe le volte è finito in una scomoda conversazione sul legal-hold.

Checklist di validazione post-migrazione

Prima di firmare il completamento:

• I conteggi dei ticket corrispondono: SDP.count(status=Closed, year=2024) è uguale a LinaDesk.count(status=Closed, CreatedAtUtc between 2024-01-01 and 2024-12-31) entro ±0,1%.
• I richiedenti orfani sono stati gestiti: ogni utente in orphans.csv ha un placeholder in LinaDesk oppure è stato escluso esplicitamente, e i loro ticket storici mostrano un nome di richiedente preservato nel corpo del ticket.
• Parità dei report SLA: estraete il report di conformità SLA del trimestre precedente da SDP e da LinaDesk; i numeri dovrebbero essere entro ±1%. Delta più ampi indicano una configurazione errata del calendario o dello stato di pausa.
• Integrità degli allegati: campionate 200 ticket casuali degli ultimi cinque anni e verificate che ogni allegato si apra.
• Ricerca KB: cercate i cinque articoli della knowledge base più visualizzati in LinaDesk e confermate che compaiano tra i primi cinque risultati.
• Integrazioni: ogni webhook ripuntato, ogni sincronizzazione LDAP e ogni chiamata API in uscita è stata osservata attivarsi con successo almeno due volte.

Insidie comuni

Funzionalità presenti in SDP ma non in LinaDesk v1

L'elenco onesto. LinaDesk v1 non include:

• Un modulo di project management. Il sottomodulo Projects di SDP è usato da circa il 15% dei clienti SDP; se siete tra loro, questa è una decisione di scope, non un workaround.
• Un livello di multi-tenancy per MSP. LinaDesk è single-tenant per progettazione — ogni cliente gestisce la propria installazione.
• Un'app mobile nativa. L'interfaccia web di LinaDesk è responsive per mobile, ma un guscio nativo è nella roadmap v1.2, non nella v1.

Se una di queste è portante per la vostra operatività, risolvetela in fase di discovery, non la settimana prima del cut-over.

Sottostimare la migrazione dei campi personalizzati

Ogni migrazione che abbiamo esaminato aveva almeno un campo personalizzato popolato sul 60% dei ticket storici ma solo sul 3% dei ticket dell'ultimo anno. Qualcuno ha smesso di usarlo anni fa e nessuno lo ha rimosso. Migratelo comunque — i dati orfani restano dati visibili all'audit.

Fidarsi dell'interfaccia di esportazione "intervallo di date" di SDP

L'interfaccia di esportazione di SDP limita silenziosamente le righe a 5.000 in alcune build e a 10.000 in altre, e non c'è alcun errore — solo un CSV troncato. Usate sempre l'API per qualsiasi cosa sopra qualche centinaio di righe.

Letture correlate

• Perché l'ITSM on-premise sta vivendo un momento d'oro nel 2026
• Progettare calendari SLA che sopravvivono ai cambi turno e alle festività
• LinaDesk vs ServiceNow, ManageEngine, Freshservice — tabella di confronto
• Sicurezza e conformità LinaDesk