Il gestionale è nel cloud, i documenti sono accessibili e il lavoro procede. Poi cambiano le tariffe, serve un'integrazione che la piattaforma non supporta oppure il servizio non risponde più alle esigenze dell'azienda. A quel punto emerge una domanda: quanto sarebbe difficile cambiare?
La libertà di scegliere non dipende soltanto dalla possibilità di disdire un abbonamento. Dipende da quali dati possiamo recuperare, da come sono costruite le applicazioni e da ciò che serve per continuare a lavorare altrove. Valutare questi aspetti prima di una scelta cloud aiuta a riconoscere il vendor lock-in: una dipendenza dal fornitore che rende il cambiamento oneroso.
Una piattaforma può essere sostituibile sul piano contrattuale e difficile da abbandonare sul piano operativo. Per valutare il rischio conviene separare tre livelli:
Il contratto attraversa tutti e tre: definisce quali informazioni sono recuperabili, quale assistenza è prevista e che cosa accade alla cessazione del servizio. Una dipendenza può riguardare il gestore dell'infrastruttura, il produttore del software o chi ne cura l'implementazione: non sono necessariamente lo stesso soggetto.
Consideriamo un esempio ipotetico: una PMI esporta dal gestionale clienti e ordini in formato CSV. I file si aprono, ma non chiariscono come collegare ogni ordine ai suoi allegati e allo storico delle approvazioni. L'esportazione è riuscita; la ricostruzione del processo richiede ancora lavoro.
Una verifica utile parte da un insieme limitato di dati rappresentativi: controlliamo identificativi, relazioni, date, unità di misura, allegati e significato dei campi. Poi proviamo a importarli in un ambiente di verifica. Il criterio di riuscita è poterli usare correttamente, non soltanto ottenere un file scaricabile.
Anche il backup risponde a una domanda diversa: può consentire il ripristino del servizio originario senza permettere di ricostruirlo su un'altra piattaforma. Ripristino e portabilità vanno verificati separatamente.
Un database gestito o un servizio cloud specializzato possono ridurre attività operative e velocizzare un progetto. Rinunciarvi per principio può introdurre più lavoro e complessità di quanta ne elimini. La guida del Government Digital Service sul lock-in tecnico propone proprio di bilanciare valore del servizio e possibilità di cambiarlo.
Per una PMI la scelta utile è rendere esplicito il compromesso: quale beneficio otteniamo oggi, quale componente sarebbe da sostituire domani e quale impegno riteniamo accettabile. Non serve rendere ogni componente identica su tutti i cloud. Serve riconoscere dove una dipendenza può limitare una decisione importante.
Un'applicazione distribuita in un container può continuare a dipendere da un database specifico, da un sistema di identità o da un servizio di messaggistica. Trasferire il pacchetto applicativo non trasferisce automaticamente quei comportamenti, né le configurazioni che li collegano.
Usare più fornitori può essere appropriato, ma aggiunge aspetti da gestire: competenze, accessi, rete, monitoraggio e costi. Prima di introdurre una seconda piattaforma chiediamoci quale problema concreto risolve e come ne verificheremo il funzionamento. Il numero dei cloud utilizzati, da solo, non misura la libertà di scelta.
Per lo sviluppo personalizzato vanno chiariti anche diritti d'uso, disponibilità del codice e dipendenze da componenti di terzi. Non tutte le parti di una soluzione hanno lo stesso regime di licenza o possono essere trasferite nello stesso modo.
Il Data Act europeo, applicabile dal 12 settembre 2025, prevede misure per agevolare il cambio tra servizi di trattamento dei dati. Dal 12 gennaio 2027 è prevista l'eliminazione degli oneri di switching, inclusi quelli di uscita dei dati, nel perimetro della disciplina.
Questo non rende gratuita l'intera migrazione: adattare un'applicazione, verificare le informazioni e formare chi la usa resta lavoro. Ambito, condizioni ed eventuali eccezioni vanno verificati per il servizio concreto. Alla data di questo articolo, 13 novembre 2026, il passaggio del gennaio 2027 è ancora futuro.
Per costruire una stima credibile, separiamo il recupero e la trasformazione dei dati dagli adattamenti applicativi, dalla ricostruzione delle integrazioni e dal periodo in cui vecchio e nuovo ambiente devono convivere. Aggiungiamo verifiche, passaggio operativo e aggiornamento della documentazione.
La stima va confrontata con il costo e i vantaggi del restare. Un passaggio può non essere conveniente oggi e meritare comunque preparazione. Documentare una dipendenza rende più fondata anche la decisione di mantenerla.
Possiamo scegliere un flusso importante, per esempio la consultazione di un ordine con i suoi documenti, e verificare come ricostruirlo fuori dalla piattaforma di partenza. Usiamo un ambiente separato e dati di prova adeguati: nessun cambiamento al servizio operativo per il solo fatto di svolgere la verifica.
Registriamo che cosa funziona, quali elementi mancano e quali adattamenti servono. Perimetro, responsabilità e criteri di riuscita sono anche punti centrali della guida AWS alla strategia di uscita, sviluppata per il settore finanziario: non ne trasferiamo automaticamente gli obblighi a tutte le PMI.
Possiamo partire dai sistemi che sostengono il tuo lavoro e dalle integrazioni che li tengono insieme. Confrontiamo ciò che è esportabile con ciò che serve davvero per operare, individuando le dipendenze da approfondire prima di un nuovo investimento o di una migrazione cloud.
Se occorre intervenire, valutiamo una integrazione tra sistemi, un adattamento software o un percorso graduale. Valutiamo insieme quanto è trasferibile la tua soluzione: l'obiettivo è scegliere con più elementi, sia quando conviene cambiare sia quando conviene restare.
