C'è un momento preciso in cui molte aziende si accorgono di essere in trappola. Di solito arriva quando il fornitore aumenta i prezzi in modo significativo, quando la piattaforma smette di supportare una funzionalità critica, o quando si decide di cambiare direzione e ci si rende conto che portare via i propri dati è molto più complicato del previsto. A quel punto, il costo reale di certe scelte tecnologiche diventa improvvisamente visibile.
Il vendor lock-in è esattamente questo: una condizione in cui il costo di uscita da una piattaforma, un servizio o un fornitore è diventato così alto, in termini economici, tecnici o di tempo, da rendere il cambiamento praticamente impossibile. Non è sempre il risultato di una scelta sbagliata in partenza. A volte è la conseguenza naturale di anni di integrazione profonda con un sistema che funzionava bene. Ma è sempre qualcosa che si può prevenire, almeno in parte, se si sa cosa cercare.
Le forme del lock-in: non è solo una questione di contratti
Quando si pensa al lock-in si pensa subito ai contratti pluriennali con penali di uscita. Esistono, certo, ma sono la forma più trasparente e negoziabile del problema. Le forme più insidiose sono tecniche.
Il lock-in sui dati è forse il più comune. Alcune piattaforme rendono facile importare dati ma difficile esportarli, o li esportano in formati proprietari che richiedono lavoro significativo per essere usati altrove. Un CRM che tiene i tuoi contatti in una struttura non standard, un e-commerce che non permette l'export completo dello storico ordini, un ERP che produce backup leggibili solo dal suo stesso motore: sono tutti esempi di dipendenza dai dati che non si vede finché non serve uscire.
Il lock-in tecnologico riguarda le integrazioni. Più un sistema è integrato con altri tramite API proprietarie, webhook specifici, plugin sviluppati ad hoc, più il costo di migrazione cresce. Non perché qualcuno lo abbia pianificato così, ma perché ogni integrazione è un filo che lega il sistema all'ecosistema del fornitore.
C'è poi il lock-in di competenze. Se l'unica persona in azienda capace di gestire un certo sistema è il fornitore stesso, o un consulente certificato su quella piattaforma specifica, si è già in una posizione di dipendenza. Non si tratta solo di soldi: si tratta di potere negoziale. Chi sa che non puoi fare a meno di lui ha poco incentivo a venire incontro alle tue esigenze.
I segnali da non ignorare
Alcune situazioni dovrebbero accendere un campanello d'allarme già durante la valutazione di una piattaforma o di un fornitore.
Se la documentazione per l'export dei dati è vaga, incompleta o assente, vale la pena chiedere esplicitamente come funzionerebbe una migrazione. La risposta, o l'assenza di risposta, dice molto. Lo stesso vale per le API: esistono? Sono ben documentate? Permettono accesso completo ai dati o solo a un sottoinsieme?
Un altro segnale è l'ecosistema chiuso. Piattaforme che funzionano bene solo con i loro strumenti nativi, che scoraggiano le integrazioni con terze parti o le rendono costose tramite marketplace proprietari, stanno costruendo attorno a te una dipendenza funzionale. Non è detto che sia sbagliato sceglierle, ma va fatto consapevolmente.
Infine, il modello di pricing. Strutture tariffarie che crescono in modo non lineare con l'uso, o che diventano significativamente più costose man mano che si usano più funzionalità avanzate, sono spesso progettate per rendere il cambiamento economicamente doloroso prima ancora che sia tecnicamente difficile.
Come progettare sistemi più liberi
La buona notizia è che esistono principi progettuali che riducono strutturalmente la dipendenza da singoli fornitori. Non eliminano il lock-in, ma lo rendono gestibile.
Il primo è privilegiare standard aperti. Formati dati come JSON, CSV, XML; protocolli come REST o GraphQL; database con driver standardizzati: tutte scelte che rendono i dati portabili e le integrazioni più facili da replicare su un sistema diverso. Quando si valuta una piattaforma, chiedersi sempre: se domani dovessi portare questi dati altrove, quanto ci vorrebb?
Il secondo è separare i livelli. Un'architettura in cui il frontend è disaccoppiato dal backend, il backend è disaccoppiato dal database, e le integrazioni passano per uno strato di API ben definito, è intrinsecamente più portabile di un monolite che fa tutto internamente. Non è sempre necessario arrivare a un'architettura a microservizi, ma il principio di separazione delle responsabilità vale sempre.
Il terzo è documentare le integrazioni. Ogni connessione tra sistemi dovrebbe essere documentata, con i flussi di dati, i formati usati, le dipendenze. Non solo per facilitare una futura migrazione, ma per rendere il sistema manutenibile nel tempo da chiunque, non solo da chi lo ha costruito.
Infine, negoziare le clausole di uscita prima di firmare. Cosa succede ai dati se si rescinde il contratto? In quale formato vengono consegnati? Entro quanto tempo? Sono domande che sembrano fuori luogo durante una trattativa commerciale, ma che possono fare la differenza anni dopo.
Il caso specifico del software custom
Uno degli argomenti che sentiamo spesso nelle conversazioni con le aziende che valutano un software su misura è proprio questo: "E se poi il vostro fornitore non c'è più, o aumenta i prezzi, o non vuole più seguire il progetto?"
È una domanda legittima, e la risposta onesta è che dipende da come viene strutturato il rapporto fin dall'inizio. Un software custom sviluppato su stack proprietario, senza documentazione, con il codice sorgente trattenuto dal fornitore, è potenzialmente più vincolante di una piattaforma SaaS. Al contrario, un software sviluppato su tecnologie standard e open source, con codice di proprietà del cliente, documentazione adeguata e test automatizzati, è un asset che il cliente può portare con sé e affidare a chiunque.
In Redergo lavoriamo sempre garantendo la proprietà del codice al cliente, usando stack tecnologici diffusi e documentando le scelte architetturali. Non perché sia un obbligo contrattuale, ma perché è l'unico modo sensato di costruire un rapporto di lungo periodo. Un cliente che può andarsene se vuole, e sceglie di restare, è molto più solido di uno che non ha alternative.
Il cloud non è immune
Vale la pena spendere qualche parola sul cloud, perché è un contesto in cui il lock-in è particolarmente sottile. I grandi provider come AWS, Google Cloud e Azure offrono servizi estremamente comodi e ben integrati tra loro. Il problema è che più si usano i servizi managed di un singolo provider, più il costo di migrazione verso un altro cresce.
Una funzione Lambda su AWS, un Cloud Run su Google, una Azure Function: tecnicamente sono tutti container, ma le modalità di deployment, monitoring, scaling e integrazione con gli altri servizi sono profondamente diverse. Chi ha costruito un'intera architettura su servizi proprietari di un singolo cloud si trova di fatto vincolato a quel provider anche senza aver firmato alcun contratto di esclusiva.
La risposta non è necessariamente evitare il cloud o rinunciare ai servizi managed, ma essere consapevoli di dove si sta accumulando dipendenza e bilanciarla con scelte architetturali che mantengano un livello minimo di portabilità. Containerizzare le applicazioni con Docker, usare Kubernetes per l'orchestrazione, adottare strumenti di Infrastructure as Code multi-cloud: sono tutte pratiche che aumentano la libertà di movimento senza rinunciare ai vantaggi del cloud.
Libertà di scelta come criterio di valutazione
Il punto finale, forse il più importante, è culturale. Il lock-in non è quasi mai il risultato di una singola decisione sbagliata, ma l'accumulo di tante piccole scelte fatte senza pensare all'uscita. Ogni integrazione aggiuntiva, ogni personalizzazione su una piattaforma chiusa, ogni anno di contratto rinnovato senza rinegoziare le condizioni è un mattone in più nel muro.
Valutare una tecnologia includendo il costo potenziale di uscita nel calcolo non significa essere pessimisti o non fidarsi dei fornitori. Significa fare scelte consapevoli, con gli occhi aperti sui rischi. Le aziende che ci riescono hanno più potere negoziale, più flessibilità strategica e meno brutte sorprese quando il mercato o le loro esigenze cambiano.
E cambiano sempre.