Exit strategy software PMI: come evitare il lock-in irreversibile

• Un fornitore software che chiude senza preavviso.
• Un contratto che non prevede l’esportazione dei dati in formato aperto.
• Un codice sorgente che nessuno, tranne chi l’ha scritto, riesce a leggere.

Queste tre situazioni hanno una cosa in comune: potevano essere evitate. Non con la fortuna, ma con una exit strategy costruita prima che il problema si presentasse. Questa guida spiega come farlo, passo dopo passo.

Perché le PMI finiscono in trappola

La dipendenza da un fornitore software non nasce da una scelta sbagliata. Nasce dall’assenza di una scelta consapevole.
Quando selezioni un gestionale o commissioni un software custom, il tuo focus è su funzionalità, costi e tempi. Raramente ti chiedi: “Come esco da qui se le cose vanno storte?” Eppure quella domanda vale quanto qualsiasi altra nel processo di valutazione.
Il lock-in si costruisce lentamente. Il fornitore accumula conoscenza del tuo sistema. I tuoi processi si adattano al software, non il contrario. I dati crescono e si stratificano in strutture proprietarie. Dopo qualche anno, cambiare diventa un’operazione che spaventa anche solo da pensare.
La sovranità digitale di una PMI non è un concetto astratto: è la capacità concreta di decidere con chi lavorare domani, senza che la storia tecnica di ieri ti blocchi le mani.

Passo 1: mappare la dipendenza attuale

Dove sei bloccato senza saperlo

Prima di costruire un’exit strategy, devi capire quanto sei già dipendente. Fai questo esercizio: immagina di dover cambiare fornitore software entro 90 giorni. Cosa succederebbe?
Rispondi a queste domande concrete:

• I tuoi dati sono esportabili in un formato aperto (CSV, JSON, XML standard) senza dover coinvolgere il fornitore?
• Hai accesso al codice sorgente del software, o solo all’applicativo compilato?
• La documentazione tecnica è sufficiente perché un altro sviluppatore possa prendere in mano il progetto?
• Il contratto prevede una clausola di portabilità dati con tempi e formati definiti?

Se hai risposto “no” o “non lo so” a due o più di queste domande, sei già in una posizione di dipendenza che richiede attenzione.

Classifica il rischio per livello

Non tutti i sistemi hanno lo stesso peso. Un foglio Excel che gestisce le ferie ha un rischio di lock-in basso. Il gestionale che contiene dieci anni di ordini, clienti e movimenti di magazzino ha un rischio alto.
Fai una lista dei software aziendali in uso e assegna a ciascuno un livello di criticità: alto (operatività bloccata senza di esso), medio (rallentamento significativo), basso (sostituibile in pochi giorni). Concentra l’exit strategy sui sistemi ad alto rischio.

Passo 2: le clausole contrattuali che devi pretendere

Molti problemi di lock-in si risolvono prima di firmare, non dopo. Ecco cosa inserire o verificare in qualsiasi contratto con un fornitore software.
Portabilità dei dati. Il contratto deve specificare che hai diritto a esportare tutti i tuoi dati in formato aperto, in qualsiasi momento, senza costi aggiuntivi e senza necessità di autorizzazione. Se questa clausola non c’è, aggiungila. Se il fornitore si oppone, è un segnale da non ignorare.
Accesso al codice sorgente. Per software custom, pretendi che il codice venga depositato in un repository di tua proprietà (o in escrow) fin dal primo giorno. Non al termine del progetto: dall’inizio. Ogni rilascio deve aggiornare quel repository.
Documentazione tecnica minima. Il contratto deve obbligare il fornitore a mantenere una documentazione tecnica aggiornata: architettura del sistema, dipendenze esterne, istruzioni per l’installazione e la configurazione. Senza questo, il codice da solo non basta.
Periodo di transizione assistita. In caso di fine rapporto, il fornitore deve garantire un periodo di supporto alla migrazione, con durata e costi definiti. Trenta o sessanta giorni sono un minimo ragionevole.
Se stai valutando un nuovo fornitore, l’articolo su come scegliere un’agenzia sviluppo software custom elenca le domande giuste da fare prima di firmare.

Passo 3: architettura software indipendente dal fornitore

Separare i dati dalla logica applicativa

L’architettura del tuo software determina quanto sei libero di muoverti. Un sistema dove i dati, la logica di business e l’interfaccia sono intrecciati in un unico blocco monolitico è molto più difficile da migrare di un sistema con componenti separati.
Quando commissioni un software custom o valuti un’integrazione, chiedi esplicitamente che i dati siano gestiti in un database standard (PostgreSQL, MySQL, MariaDB) con uno schema documentato. Se il fornitore usa un database proprietario o formati binari non standard, stai costruendo una trappola.
Le API sono il tuo alleato. Un sistema che espone i propri dati tramite API standard (REST o GraphQL con documentazione OpenAPI) ti permette di connettere altri strumenti, migrare gradualmente e mantenere la flessibilità nel tempo. L’articolo sulle API custom per integrare gestionali aziendali spiega come strutturarle correttamente.

Evitare le dipendenze tecnologiche opache

Alcune tecnologie creano lock-in per natura. Formati di file proprietari, protocolli di comunicazione chiusi, librerie senza licenza open source: ognuno di questi elementi è un punto di vulnerabilità.
Chiedi sempre al fornitore un elenco delle dipendenze tecnologiche del sistema (la cosiddetta SBOM, Software Bill of Materials). Se non sanno cos’è o si rifiutano di fornirla, hai già una risposta sulla loro affidabilità a lungo termine.

Passo 4: costruire il piano di uscita operativo

Avere buone clausole contrattuali e una buona architettura non basta. Serve un piano scritto che definisca cosa fare se il rapporto con il fornitore si interrompe.
Il piano deve rispondere a tre domande:
Chi fa cosa. Identifica internamente chi è responsabile della gestione del rapporto con il fornitore software. Questa persona deve conoscere le credenziali di accesso al repository, i contatti tecnici di secondo livello e la posizione di tutti i documenti contrattuali.
Dove sono le cose. Tieni un registro aggiornato che includa: URL del repository del codice, credenziali di accesso ai sistemi di produzione, backup recenti del database con data dell’ultimo test di ripristino, documentazione tecnica e contratti firmati. Non nella testa di qualcuno: in un documento condiviso e accessibile.
Quanto tempo ci vuole. Fai almeno una volta l’anno una stima realistica del tempo necessario per migrare il sistema su un nuovo fornitore. Se la risposta è “più di sei mesi”, hai un problema che va affrontato prima che diventi urgente.
Se il tuo sviluppatore di riferimento è già sparito o irraggiungibile, la checklist dei primi 7 giorni è il punto di partenza più utile che puoi trovare.
Se stai lavorando alla tua exit strategy e vuoi un confronto tecnico su come strutturarla, raccontaci il tuo caso.

Passo 5: testare l’exit strategy prima che serva

Un piano non testato è un piano che probabilmente non funziona. Questo vale per i backup, per i piani di continuità operativa e vale anche per l’exit strategy software.

Il test del backup dati

Esporta i tuoi dati nel formato previsto dal contratto. Poi prova a reimportarli in un sistema diverso, anche solo in un ambiente di test. Se l’esportazione fallisce, se i dati sono incompleti o se il formato non è leggibile senza strumenti proprietari, hai trovato un problema che è molto meglio scoprire adesso.

Il test di onboarding di un nuovo sviluppatore

Prendi la documentazione tecnica del tuo software e consegnala a qualcuno che non ha mai visto il progetto. Chiedigli di rispondere a tre domande: come si installa il sistema, dove sono memorizzati i dati degli ordini, come si aggiunge una nuova funzionalità. Se non riesce a rispondere leggendo la documentazione, quella documentazione non è sufficiente.
Questo test costa qualche ora di lavoro. Scoprire il problema durante una migrazione d’emergenza costa molto di più.

Passo 6: manutenzione dell’exit strategy nel tempo

Un’exit strategy costruita oggi e dimenticata domani perde valore rapidamente. Il software cambia, i fornitori cambiano, i contratti scadono e vengono rinnovati con condizioni diverse.
Fissa una revisione annuale che includa: verifica delle clausole contrattuali, aggiornamento del registro delle credenziali e dei documenti, test di esportazione dati, stima aggiornata dei tempi di migrazione.
Tieni d’occhio i segnali che indicano un fornitore in difficoltà: ritardi nelle risposte di supporto, mancato aggiornamento del software per periodi lunghi, cambiamenti frequenti nel team tecnico di riferimento. Questi segnali non significano necessariamente che il fornitore chiuderà, ma sono buoni motivi per tenere il piano di uscita aggiornato e pronto.
La manutenzione evolutiva del software custom include anche questo tipo di presidio: non solo aggiornare funzionalità, ma mantenere il sistema in una condizione da cui si può uscire senza traumi.
Un’opinione netta, a questo punto: chi vende software senza mai menzionare le condizioni di uscita sta facendo un favore a sé stesso, non a te. Un fornitore serio non ha nulla da nascondere su questo punto e non si oppone a clausole di portabilità ragionevoli. La resistenza su questi temi è già una risposta.

FAQ

Q: Cos’è un’exit strategy software per una PMI?
A: È il piano operativo che permette di cambiare fornitore software o migrare sistema senza perdere dati, continuità operativa o mesi di lavoro. Si definisce prima di firmare il contratto, non quando il rapporto è già in crisi.
Q: Quando è troppo tardi per costruire un’exit strategy?
A: Non è mai troppo tardi, ma più aspetti più costa. Se il fornitore ha accumulato anni di personalizzazioni non documentate e i dati sono in formati proprietari chiusi, la migrazione richiede un lavoro di reverse engineering che può richiedere mesi.
Q: Cosa significa portabilità dei dati nel software aziendale?
A: Significa poter esportare tutti i tuoi dati in un formato aperto e leggibile (CSV, JSON, XML standard) in qualsiasi momento, senza dover chiedere il permesso al fornitore e senza costi aggiuntivi. Se non è scritto nel contratto, non è garantito.
Q: Un software custom elimina il rischio di lock-in?
A: Riduce il rischio ma non lo elimina automaticamente. Un software custom sviluppato senza documentazione, senza accesso al codice sorgente e con tecnologie obsolete crea lo stesso lock-in di un SaaS chiuso. Le clausole contrattuali e la qualità del codice fanno la differenza.

Se gestisci il software aziendale della tua PMI e vuoi capire dove sei esposto a rischi di lock-in, in Press Start analizziamo la situazione tecnica e contrattuale e ti aiutiamo a costruire un piano di uscita praticabile. Raccontaci il tuo caso.