Vuoi sapere qual è la best practice per cambiare piattaforma ITSM?
Ti possiamo mostrare una panoramica di alto livello del percorso da seguire per avviare una trasformazione della piattaforma ITSM.
Cambio piattaforma ITSM: migrazione o trasformazione?
Condividi sui social
Migrazione ITSM vs trasformazione ITSM: come cambiare piattaforma senza perdere valore
Zoi Raskou
Pubblicato il 23 luglio 2026
Ultimo aggiornamento il 24 luglio 2026
17 min di lettura
Zoi Raskou
Pubblicato il 23 luglio 2026
Ultimo aggiornamento il 24 luglio 2026
17 min di lettura
Questo blog spiega perché una semplice migrazione spesso ripropone le inefficienze esistenti e come un approccio guidato dalla trasformazione possa generare valore duraturo per il business.
Se sei sempre più frustrato dalla tua attuale piattaforma di service management, probabilmente ti sei già posto una domanda: e adesso?
Forse i costi di licenza sono diventati difficili da giustificare. Forse il valore che la tua CMDB prometteva non si è mai del tutto concretizzato. O magari i tuoi team si ritrovano a lavorare aggirando lo strumento, invece di usarlo davvero a proprio vantaggio.
Qualunque sia il motivo scatenante, la decisione che hai davanti non riguarda solo quale piattaforma scegliere, ma anche come affrontare il cambiamento.
Questa scelta conta molto più di quanto molti leader immaginino. E sbagliarla può rivelarsi uno degli errori più costosi che un’azienda possa commettere.
Perché l’istinto a migrare spesso non basta
Quando le organizzazioni decidono di abbandonare una piattaforma ITSM legacy, l’istinto naturale è trattare il cambiamento come un intervento puramente tecnico. Si mappano i processi esistenti, si individuano le funzionalità equivalenti nel nuovo strumento, si trasferiscono i dati, si riqualificano i team e si mette in esercizio la nuova piattaforma.
È quello che comunemente viene definito una migrazione “lift and shift”, l’approccio più diffuso nelle transizioni ITSM in ambito enterprise.
Il suo fascino è comprensibile: la migrazione appare come un’opzione a rischio più contenuto. Preserva ciò che già esiste, mettendo a proprio agio gli stakeholder ed evitando le difficoltà percepite legate al change management. Sulla carta, sembra un percorso lineare dal punto A al punto B.
Ma qui sta il problema: se la tua piattaforma attuale non genera valore, non è solo la tecnologia a frenare la tua organizzazione. A pesare sono i processi costruiti intorno ad essa, le abitudini radicate nel tempo e la mancanza di allineamento organizzativo che la sostiene.
Trasferire gli stessi processi e le stesse abitudini in un nuovo strumento non risolve nulla. Significa semplicemente riprodurre i problemi esistenti in un ambiente più moderno in apparenza, introducendo al tempo stesso nuove criticità impreviste. Questo può accadere per differenze di compatibilità tra le funzionalità di origine e di destinazione, oppure per disparità tra le feature e le capacità delle due piattaforme.
In pratica: hai investito in una trasformazione ma hai ottenuto solo una copia incompleta (o peggiore) di ciò che avevi prima.
Il risultato è prevedibile: nel giro di 6/12 mesi, i team iniziano a sollevare le stesse criticità. L’adozione resta disomogenea. Emergono nuove frustrazioni legate alla novità dello strumento e a funzionalità poco fluide. I problemi di visibilità dei dati non sono scomparsi. E nel frattempo hai investito un budget significativo in un programma che non ha avuto un impatto concreto. Anzi, si potrebbe sostenere che la situazione sia persino peggiorata.
Che cosa significa davvero trasformazione ITSM?
Una trasformazione del service management parte da un presupposto completamente diverso: invece di chiedersi “come possiamo replicare ciò che abbiamo nel nuovo strumento?”, si chiede: “che cosa significa, per la nostra organizzazione, fare buon service management e come possiamo costruirlo?”.
L’attenzione si sposta dalla tecnologia ai risultati: si definisce il modello operativo futuro, si comprende come i servizi debbano essere erogati e si determina quale esperienza serva al business e ai suoi utenti. Solo a quel punto l’organizzazione dovrebbe valutare in che modo strumenti, processi e automazione possano abilitare questa visione.
Partendo dai risultati di business desiderati, anziché dall’implementazione tecnica, le organizzazioni evitano di ricreare inefficienze esistenti su una nuova piattaforma e pongono invece le basi per il successo nel lungo periodo.
Questa distinzione può sembrare filosofica, ma ha conseguenze molto concrete su come il programma viene strutturato, su chi viene coinvolto, sui tempi necessari e, in ultima analisi, sui risultati che riesce a ottenere
Una trasformazione considera il cambio di piattaforma come un’opportunità per ripartire da basi nuove. Non per scartare il patrimonio di conoscenze accumulato, ma per rimettere in discussione processi, workflow e configurazioni stratificati nel tempo, chiedendosi se stiano davvero supportando il business.
Molte organizzazioni enterprise scoprono che una parte significativa delle personalizzazioni ITSM non esiste per una reale esigenza di business, ma perché qualcuno le ha create anni fa per gestire casi particolari o problemi isolati, che col tempo si sono sommati. Queste personalizzazioni comportano un carico di manutenzione, rendono più complessi gli aggiornamenti e spesso finiscono per offuscare ciò che le best practice ITIL raccomanderebbero in modo naturale.
La trasformazione parte dalla situazione attuale dell’azienda e disegna un percorso per portarla dove desidera arrivare, eliminando la complessità accumulata nel tempo. Semplifica, standardizza e modernizza i processi ITSM core, introduce un approccio orientato prima di tutto al valore per il business (evitando di ricadere nell’eccesso di personalizzazioni) e, aspetto cruciale, prepara l’organizzazione a sfruttare capacità come IA e automazione, che per funzionare correttamente richiedono dati puliti e strutturati, oltre a modalità operative coerenti.
Nulla di tutto questo accade automaticamente passando a una nuova piattaforma. Servono una progettazione intenzionale, lo coinvolgimento degli stakeholder e un approccio strutturato al cambiamento.
Il ruolo dell’Organisational Change Management e perché è indispensabile
Tra tutti gli elementi che distinguono una trasformazione da una migrazione, nessuno è più importante dell’Organisational Change Management (OCM). Ed è anche l’elemento più spesso sottovalutato (o addirittura completamente trascurato) nei programmi guidati dalla tecnologia.
L’OCM è molto più di un piano di comunicazione o di un calendario formativo: è uno sforzo continuativo e strutturato, accompagnato da un cambiamento culturale, che serve a coinvolgere le persone nel percorso di trasformazione, comunicando la visione e i benefici attesi, per costruire fiducia, allineamento e capacità che rendano l’adozione solida e duratura anche ben oltre il go-live.
Nella pratica, questo significa coinvolgere gli stakeholder giusti al momento giusto. Significa comprendere, insieme ai leader, come il lavoro si svolge oggi e quali risultati si vogliono ottenere, attraverso sessioni di discovery. Significa attivare steering group per valorizzare il patrimonio di conoscenze interne e integrare gli elementi di strumenti e processi che funzionano davvero. Significa ascoltare i team, le loro frustrazioni, le loro idee e le loro esigenze.
Significa collaborare prima che vengano prese decisioni di configurazione e integrare il feedback ricevuto nella soluzione, co-creando valore. In definitiva, si tratta di costruire in modo iterativo una soluzione focalizzata su ciò che il business vuole raggiungere e di definire un percorso che assicuri il risultato, la sostenibilità nel tempo della soluzione e la sua adozione.
Il motivo per cui questo aspetto è così importante è semplice: le piattaforme ITSM coinvolgono quasi tutte le persone in un’organizzazione. Un cambiamento nel modo in cui vengono aperti gli incident, gestite le richieste o approvati i change ha implicazioni per ogni team che dipende dal supporto IT, vale a dire praticamente tutti i team.
Se le persone giuste non vengono coinvolte nella definizione dei nuovi modi di lavorare, tenderanno a opporvisi. E la resistenza, in ambito ITSM, non è soltanto un inconveniente: si traduce direttamente in scarsa adozione, workaround e peggioramento della qualità dei dati, compromettendo il valore dell’intero investimento. A questo si aggiungono il costo del ritardo e l’impatto che una soluzione ITSM inefficace può avere sulla produttività complessiva dell’organizzazione.
La resistenza alla trasformazione può inoltre generare costi nascosti, molto più difficili da misurare: aziende che perdono l’opportunità di modernizzare, innovare e restare al passo con l’evoluzione del mercato. La tecnologia può anche essere andata live, ma la trasformazione si è fermata e l’opportunità è stata mancata.
Le cinque fasi integrate di una trasformazione del service management
Capire come si presenta, nella pratica, una trasformazione ben strutturata aiuta a comprendere perché produca risultati diversi rispetto a una migrazione. Alla base, un programma di trasformazione si sviluppa in cinque fasi distinte, ciascuna delle quali si basa sulla precedente.
L’onboarding è la fase in cui si costruiscono le fondamenta. In questa fase vengono prima le persone, poi la tecnologia: si identificano le persone che saranno impattate dalla trasformazione in tutta l’organizzazione, si costruisce fiducia attraverso un coinvolgimento strutturato degli stakeholder, si creano steering group con il giusto livello di autorità e si allineano gli obiettivi prima ancora di iniziare la progettazione della soluzione. Le organizzazioni che saltano questa fase per passare direttamente alla configurazione della piattaforma costruiscono su basi instabili. Senza un vero allineamento a livello di leadership, ogni decisione progettuale diventa una negoziazione e ogni go-live si trasforma in una battaglia per l’adozione.
La progettazione segue un modello iterativo incentrato sulla discovery: Invece di limitarsi a documentare ciò che esiste e ricostruirlo altrove, la fase di design mette in discussione i processi attuali attraverso decision sprint e workshop strutturati, nei quali il team approfondisce le scelte che definiranno il nuovo modello di service management.
L’obiettivo non è preservare la complessità legacy, ma arrivare a una soluzione basata su ciò di cui il business ha realmente bisogno, guidata dalle best practice ITIL e dalle capacità della piattaforma. Questa fase produce requisiti di implementazione chiari e un solution design che gli stakeholder hanno contribuito a definire in modo concreto.
Implementazione e validazione adottano un approccio iterativo per garantire che la soluzione sia allineata agli obiettivi dell’organizzazione. La configurazione viene sviluppata in modo incrementale, testata attraverso cicli di User Acceptance Testing (UAT) e affinata sulla base del feedback diretto. Non si tratta di una sequenza lineare del tipo “si sviluppa e poi si testa”, ma di un ciclo continuo.
L’empowerment delle persone è la fase per cui la maggior parte delle migrazioni non ha un vero equivalente. Invece di limitarsi a una formazione standard per gli utenti finali erogata nella settimana precedente al go-live, questa fase investe nello sviluppo di competenze reali all’interno dell’organizzazione attraverso enablement basato sui ruoli, formazione sulla gestione della soluzione e un percorso di rafforzamento della fiducia che consente ai team di governare la piattaforma, anziché dipendere a tempo indeterminato dal supporto esterno.
È questa la differenza tra un team capace di evolvere il proprio modello di service management al cambiare delle esigenze e un team che deve aprire un ticket di supporto ogni volta che ha bisogno di modificare un workflow.
La realizzazione dei benefici chiude il cerchio. Un programma di trasformazione dovrebbe definire fin dall’inizio il successo in termini misurabili (produttività, costi, tassi di adozione, prontezza all’IA) e monitorare attivamente questi indicatori, riportandone i risultati.
Questa fase assicura che l’investimento nella trasformazione si traduca in outcome documentati e visibili, capaci di giustificare l’approccio adottato e di orientare la fase successiva di evoluzione
Come capire se ti serve una migrazione o una trasformazione
Non tutti i progetti ITSM richiedono un programma di trasformazione completo. Se i processi attuali sono ben progettati, i dati sono puliti e l’unico elemento da cambiare è la tecnologia sottostante, allora una migrazione più mirata può essere la scelta giusta. Nella pratica, però, questa descrizione si adatta a pochissime grandi organizzazioni. Molto dipende anche dalla piattaforma verso cui ci si sta spostando: non tutte le piattaforme sono compatibili con un trasferimento diretto dei dati.
Le domande di diagnosi più oneste da porsi sono queste:
I processi attuali sono davvero adatti allo scopo, oppure nel tempo hanno accumulato workaround ed eccezioni? Se i tuoi team escono regolarmente dallo strumento per portare avanti il lavoro (ad esempio usando email, excel o canali informali) è un segnale che il problema non riguarda solo la piattaforma, ma anche la progettazione dei processi.
I team di service management e le funzioni di business condividono davvero una visione coerente di cosa significhi “funzionare bene”? Se l’IT e il resto dell’organizzazione hanno aspettative diverse su livelli di servizio, tempi di risposta e processi di fulfilment, il solo cambio di piattaforma non colmerà questo divario, perché il problema non è tecnologico.
I leader senior sono allineati su ciò che vogliono ottenere dal service management, non solo in termini di riduzione dei costi ma anche di risultati di business? I programmi di trasformazione hanno successo quando sono guidati da un intento strategico. Se il programma è di proprietà esclusiva dell’IT ed è impostato solo come iniziativa di contenimento dei costi, verrà trattato come tale e il valore organizzativo più ampio non verrà mai realmente espresso.
Se le risposte sincere a queste domande mettono in evidenza problemi di fondo che vanno oltre la tecnologia, una migrazione non li risolverà. Una trasformazione sì. Per questo è fondamentale avere le idee chiare su questa distinzione prima di scegliere l’approccio da adottare. Se non riesci a valutare la situazione con sufficiente obiettività, può essere utile richiedere una discovery consultation a un partner di fiducia specializzato in soluzioni.
La domanda non è solo dove stai andando, ma dove vuoi arrivare come organizzazione?
La decisione di abbandonare una piattaforma ITSM legacy è una sfida con cui si confronta un numero sempre crescente di organizzazioni enterprise. La combinazione di costi in aumento, valore realizzato limitato e funzionalità AI poco accessibili sta spingendo i leader a riconsiderare se l’investimento attuale sia davvero giustificato e, per molti, la risposta sincera è che non lo sia.
Ma il valore della prossima decisione non dipenderà dalla piattaforma che sceglierai. Dipenderà da come affronterai la transizione. Una migrazione ti porta su una nuova piattaforma. Una trasformazione ti porta verso un modello operativo migliore: più semplice, più standardizzato, più allineato al business e realmente pronto a cogliere tutto ciò che il service management moderno rende possibile.
Se sei un leader senior che sta valutando le diverse opzioni, la domanda più importante da portare sul tavolo non è “verso quale strumento dovremmo migrare?”, ma “che tipo di organizzazione di service management vogliamo diventare e siamo davvero pronti a costruirla nel modo giusto?”.
Scritto da
Principal Technical Consultant