Chiedete a un CIO nel 2019 se avrebbe spostato il proprio ITSM sul cloud e la risposta era raramente sfumata: certo che sì. Il percorso di migrazione era ben consolidato — ServiceNow guidava l'enterprise, Freshservice assorbiva il mid-market e ManageEngine si destreggiava con stack ibridi per i resistenti. L'ITSM on-premise sembrava una categoria legacy tenuta in vita solo dall'inerzia.
Fate la stessa domanda allo stesso CIO nel 2026 e sentirete una risposta più lunga. A volte riguarda la residenza dei dati. A volte riguarda la fattura per utente triplicata con una normale acquisizione. A volte è la sorpresa di scoprire che la politica di gestione dei dati di un fornitore è cambiata silenziosamente con un DPA aggiornato. Il filo conduttore: una classe crescente di organizzazioni per cui l'ITSM cloud ha smesso di essere la scelta predefinita.
Cosa è cambiato
1. La residenza dei dati è diventata una voce di audit P0, non una casella da spuntare
Dieci anni fa, le sanzioni GDPR erano rare e per lo più simboliche. Dopo dieci anni di applicazione, gli scostamenti tra "conforme sulla carta" e "conforme nella pratica" vengono controllati con più rigore. I corpi dei ticket — che contengono nomi personali, intervalli IP interni, occasionalmente screenshot di dati di produzione — rientrano nell'ambito del DPA. Quando il DPA richiede che i dati restino all'interno di una giurisdizione specifica e il team di audit chiede dove esattamente sono fisicamente archiviati i dati dei nostri ticket, la risposta deve essere dimostrabile.
Per le organizzazioni turche, la KVKK ha aggravato la situazione. Le dichiarazioni VERBIS per i trasferimenti cloud non sono banali, e il clima politico attorno alle infrastrutture dati controllate dall'estero si è fatto più caldo, non più freddo.
La via più breve verso una risposta di audit pulita è: i dati non hanno mai lasciato il nostro edificio.
2. Il prezzo per utente è cresciuto in modo non lineare rispetto alla realtà
Il prezzo dell'ITSM SaaS sembra ragionevole al primo acquisto. Un team di 30 tecnici che paga 40 $ per agente al mese sembra tollerabile — 14.400 $ l'anno. Aggiungete un altro team di 20 persone durante un'acquisizione e siete a 24.000 $. Aggiungete un modulo di conformità l'anno successivo (change management, oppure CMDB, oppure la proliferazione di posti nel portale self-service) e siete a oltre 60.000 $. Le trattative di rinnovo diventano eventi annuali, non automatici.
Gli acquirenti che hanno firmato un contratto a termine fisso cinque anni fa e ora affrontano aumenti del 40% sul listino al rinnovo sono esattamente le persone che cercano un modello di prezzo diverso.
3. L'adozione delle funzionalità si stabilizza
La maggior parte delle organizzazioni usa forse il 30% di ciò che il proprio ITSM offre. Il resto — l'integrazione AIOps mai collegata, il modulo CMDB mai popolato, l'app mobile mai distribuita — viene pagato ma resta inutilizzato. Le tabelle di prezzo enterprise SaaS sono costruite per ciò che è possibile, non per ciò che viene usato.
I fornitori on-premise, senza la stessa struttura di margine, tendono a raggruppare tutto in un'unica licenza. Questo sembra economico nella tabella delle funzionalità, ma spesso riflette un allineamento più sano tra ciò che si paga e ciò che si usa.
4. Il costo totale di proprietà ha smesso di favorire il cloud
Nell'era del 2015, "il cloud costa meno che gestire i propri server" era vero nella maggior parte dei casi. Nel 2026, gestire un modesto servizio .NET contro SQL Server Express su una VM da 50 €/mese presso un hoster europeo costa meno del numero minimo di posti dell'ITSM cloud più economico per lo stesso team. Il costo di calcolo dell'ITSM è trascurabile; il fattore distintivo è il modello di licenza.
Per cosa le organizzazioni scelgono oggi l'on-premise
Sovranità dei dati
Questo è il fattore trainante numero uno. I settori regolamentati (finanza, sanità, pubblica amministrazione, difesa) e le imprese turche soggette alla KVKK richiedono tipicamente che i corpi dei ticket e i dati identitari restino su un'infrastruttura che controllano. La controargomentazione — "il nostro fornitore SaaS ha la certificazione SOC 2 Type II" — non coglie il punto: la domanda dell'audit non è sono sicuri, è potete dimostrare dove risiedono fisicamente i dati alle 3 del mattino di un martedì.
Prevedibilità dei costi
Una licenza annuale fissa elimina il problema della scalabilità lineare. Aggiungere un tecnico non cambia la fattura. Aggiungere cento richiedenti non cambia la fattura. Le trattative di rinnovo diventano meccaniche, non conflittuali.
Capacità air-gap
I carichi di lavoro nucleari, aerospaziali e alcuni carichi governativi devono funzionare senza una rotta internet. L'ITSM SaaS moderno non può; l'on-premise può, banalmente.
Escrow del codice sorgente
Per le organizzazioni in cui un investimento ITSM decennale deve sopravvivere al fallimento del fornitore, le distribuzioni on-premise con escrow del codice sorgente offrono una garanzia di continuità che il SaaS non può offrire.
Cosa non è l'on-premise
Siamo onesti: l'ITSM on-premise ha storicamente avuto modalità di fallimento poco eleganti.
- Stanchezza da aggiornamento: i fornitori on-premise legacy rilasciavano aggiornamenti di versione maggiore ogni 18-24 mesi, ciascuno richiedente una migrazione a livello di progetto.
- Attrito nell'installazione: installer che duravano giorni interi su VM Windows Server configurate in modo bizzarro, con ticket di supporto al fornitore per le versioni delle DLL.
- Ritardo dell'interfaccia: l'interfaccia on-premise era spesso indietro di 2-3 anni rispetto a quella SaaS, sembrando datata al confronto.
L'ITSM on-premise moderno deve risolvere questi problemi. L'approccio di LinaDesk — pacchetti di aggiornamento firmati, installazione con un solo comando e la stessa interfaccia del riferimento SaaS (dark mode di qualità Linear, scorciatoie da tastiera, i18n in 8 lingue) — riflette ciò che abbiamo imparato osservando i fornitori legacy essere superati a metà degli anni 2010.
Dove porta questa tendenza
L'ITSM cloud resterà la maggioranza. La maggior parte delle organizzazioni non ha pressioni di conformità, non ha la scala per preoccuparsi del prezzo per utente ed è perfettamente felice di far girare il proprio service desk sull'infrastruttura di qualcun altro.
Ma la classe di organizzazioni per cui l'on-premise è la risposta giusta sta crescendo, non riducendosi. Il rimpatrio dal cloud è ormai una categoria — 37signals ha scritto pubblicamente del ritiro dei propri carichi di lavoro da AWS, e sebbene l'ITSM non sia il loro carico di lavoro, il calcolo è lo stesso.
I vincitori in questo segmento saranno i fornitori che offrono l'on-premise senza gli svantaggi storici: interfaccia moderna, pipeline di aggiornamento firmata, installer sensato e un modello di prezzo che non penalizza la scala.
Guarda LinaDesk in azione
Accedi alla nostra demo con un solo clic. Nessuna carta di credito, nessun banner sui cookie, nessun timer.
Apri il pannello demo