Il vendor lock-in nasce quando cambiare partner, piattaforma o tecnologia richiede costi e rischi sproporzionati. La dipendenza può essere tecnica, contrattuale o semplicemente dovuta al fatto che accessi e conoscenza sono concentrati fuori dall’azienda.
I segnali da controllare
Prima che diventi un’emergenza, il lock-in lascia quasi sempre segnali riconoscibili.
- Repository non controllati dall’azienda
- Account cloud o store intestati al fornitore
- Documentazione insufficiente
- Deploy eseguibile da una sola persona
- Dati difficili da esportare
- Contratti poco chiari su codice e asset
Ridurre la dipendenza senza riscrivere tutto
La soluzione non è eliminare qualsiasi tecnologia proprietaria. Serve sapere quali dipendenze esistono, quanto costerebbe sostituirle e quali accessi devono rimanere sotto controllo aziendale.
Preparare un piano di uscita
Anche in un rapporto sano è utile sapere come avverrebbe un handover: cosa consegnare, quali credenziali trasferire, quali competenze documentare e quanto tempo servirebbe.
La libertà tecnologica si progetta quando il rapporto con il fornitore funziona, non quando è già diventato urgente cambiarlo.
Vuoi applicarlo al tuo progetto?
Possiamo partire da una valutazione del contesto attuale e capire quali decisioni hanno priorità.
Approfondisci Cambio software houseDomande frequenti
Usare AWS o Firebase significa essere in lock-in?
Non automaticamente. Il rischio dipende da quanto il sistema usa servizi specifici e dalla difficoltà reale di migrazione.
Posso cambiare software house senza riscrivere tutto?
Spesso sì. Un assessment iniziale serve proprio a distinguere ciò che può essere mantenuto da ciò che va sostituito.