Cambio fornitore software: come prendere in carico il codice

La conclusione prima di cominciare

Prendere in carico il codice di un altro fornitore è un lavoro di intelligence prima ancora che di sviluppo. Chi lo sottovaluta si trova a fare debug su un sistema che non capisce, con credenziali incomplete, su un’architettura che nessuno ha mai documentato. Questa guida esiste per evitare quel momento.
I passi che seguono sono in ordine. Saltarne uno non accelera il processo: lo rende più costoso.

Prima di toccare una riga di codice

Il passaggio fornitore software aziendale comincia con una raccolta documentale, non con l’accesso al repository. Hai bisogno di sapere cosa stai per prendere in carico prima di capire come farlo.
Chiedi al fornitore uscente tutto questo, per iscritto:

1. Accesso al repository del codice sorgente (con storico dei commit)
2. Credenziali agli ambienti: produzione, staging, sviluppo
3. Accesso al pannello di hosting o cloud provider
4. Documentazione tecnica esistente (anche parziale)
5. Elenco delle dipendenze esterne: API di terze parti, licenze software, servizi SaaS collegati
6. Backup recenti del database

Cosa va storto di solito: il fornitore uscente consegna solo il codice e dimentica le credenziali degli ambienti. Oppure consegna tutto, ma il repository non ha storico perché lavoravano con file compressi via email. Senza storico dei commit, perdi il contesto di ogni scelta tecnica presa negli ultimi anni.
Se il contratto non prevede la consegna del codice sorgente in modo esplicito, fermati qui e parla con un legale prima di procedere. La proprietà del codice è una questione contrattuale, non tecnica.

Audit del codice: capire cosa hai ricevuto

Ricevuto l’accesso, il passo successivo è un audit tecnico. L’obiettivo non è giudicare il fornitore precedente: è capire lo stato reale del sistema che stai per mantenere.
Cosa verificare nell’audit:

1. Stack tecnologico: quali linguaggi, framework e versioni sono in uso. Controlla se le versioni sono ancora supportate dai rispettivi vendor.
2. Dipendenze: esegui un controllo delle librerie di terze parti. Quante sono obsolete? Quante hanno vulnerabilità note?
3. Test automatici: esistono? Coprono le funzionalità critiche? Un sistema senza test è un sistema che non puoi modificare con sicurezza.
4. Struttura dell’architettura: c’è separazione tra logica di business e presentazione? Il codice è leggibile o è un monolite senza struttura?
5. Segreti nel codice: password, chiavi API e token hardcoded nel sorgente sono un problema di sicurezza immediato da risolvere prima di qualsiasi altra cosa.

Cosa va storto di solito: si sottovaluta il tempo dell’audit e si inizia a sviluppare subito. Dopo qualche settimana emergono dipendenze rotte, configurazioni ambigue o logiche di business nascoste in file che nessuno aveva aperto. Meglio investire qualche giorno nell’analisi che scoprire i problemi in produzione.
Per un’analisi approfondita dei segnali che indicano un codice in cattivo stato, la guida sul refactoring software legacy copre i criteri di valutazione in dettaglio.

Mappare gli ambienti e le dipendenze esterne

Un’applicazione non vive solo nel suo codice. Vive in un insieme di servizi, configurazioni e integrazioni che il fornitore precedente gestiva spesso in modo implicito.
Crea una mappa degli ambienti: dove gira il codice in produzione, chi gestisce il server o il cloud, come funziona il deploy. Se il fornitore uscente gestiva l’infrastruttura, hai un problema in più: devi capire se puoi migrare o se sei vincolato a quella configurazione specifica.
Poi mappa le dipendenze esterne. Ogni API di terze parti, ogni servizio SaaS collegato, ogni licenza software è un punto di rischio. Alcune potrebbero essere intestate al fornitore precedente, non a te. Chiedi esplicitamente se ci sono contratti o abbonamenti da trasferire.
Cosa va storto di solito: si scopre che il dominio, il certificato SSL o l’account del servizio di email transazionale sono intestati al fornitore precedente. Trasferirli richiede tempo e, a volte, la collaborazione di chi sta uscendo, che non sempre è motivata.

Configurare l’ambiente di sviluppo del nuovo team

Il nuovo fornitore deve riuscire a far girare il progetto in locale prima di toccare la produzione. Questo passaggio sembra ovvio, ma è spesso il primo scoglio concreto.
Documenta (o fai documentare) ogni passaggio necessario per avviare l’applicazione in un ambiente fresco: variabili d’ambiente, database di test, configurazioni specifiche. Se ci vogliono più di trenta minuti per avviare il progetto da zero su una macchina nuova, c’è un problema di configurazione da risolvere subito.
Cosa va storto di solito: l’applicazione gira solo con una configurazione specifica che nessuno ha mai scritto da nessuna parte. Il fornitore precedente la conosceva a memoria. Il nuovo team impiega giorni a ricostruirla per tentativi.
Questo è anche il momento giusto per verificare il processo di deploy: come si porta una modifica dal codice alla produzione? Esiste un sistema di integrazione continua o si fa tutto a mano?
Se stai valutando se il progetto è recuperabile o se conviene ripartire da zero, la guida sul software rescue aiuta a fare questa valutazione in modo strutturato.

Se stai gestendo questo passaggio e hai dubbi su come procedere, raccontaci il tuo caso: possiamo fare un’analisi tecnica iniziale per capire cosa hai ricevuto e cosa serve per andare avanti.

Gestire il periodo di sovrapposizione

Salvo casi estremi, il cambio fornitore non avviene da un giorno all’altro. C’è un periodo in cui il vecchio fornitore è ancora formalmente attivo e il nuovo sta prendendo le misure. Questo periodo va gestito con attenzione.
Definisci in anticipo chi ha l’ultima parola su eventuali modifiche urgenti durante la transizione. Se entrambi i fornitori possono intervenire sul codice nello stesso momento, rischi conflitti e regressioni difficili da tracciare.
Stabilisci anche un punto di non ritorno: una data dopo la quale il vecchio fornitore non ha più accesso agli ambienti. Prolungare indefinitamente la sovrapposizione non è una strategia di sicurezza: è una fonte di confusione.
Cosa va storto di solito: il vecchio fornitore mantiene accesso agli ambienti per “sicurezza” anche mesi dopo la fine del contratto. Se nel frattempo c’è un incidente di sicurezza, la responsabilità diventa difficile da attribuire.

Prendere in carico la documentazione (e creare quella che manca)

La documentazione che ricevi raramente è completa. Spesso è assente. L’opinione netta, qui, è questa: un fornitore che consegna un progetto senza documentazione ha lavorato male, indipendentemente dalla qualità del codice. Non è una questione di stile: è una questione di professionalità.
Detto questo, il problema è tuo da risolvere. Il nuovo team deve produrre la documentazione che manca mentre prende confidenza con il sistema. Non dopo, non “quando c’è tempo”.
Cosa documentare per prima:

1. Architettura generale del sistema (anche uno schema a blocchi va bene)
2. Flussi principali dell’applicazione: come funziona il processo più critico per il business
3. Variabili d’ambiente e configurazioni necessarie per ogni ambiente
4. Procedure di deploy e rollback

Cosa va storto di solito: la documentazione viene rimandataa quando il team è già operativo e sotto pressione per nuove funzionalità. A quel punto non viene mai scritta, e ci si ritrova nella stessa situazione di partenza.
Per chi ha già vissuto la chiusura improvvisa di un fornitore, la guida su come recuperare software e dati copre il caso limite in cui il passaggio non è stato pianificato.

Costruire la exit strategy già adesso

Prendere in carico un progetto software è anche il momento giusto per costruire le condizioni che rendano il prossimo cambio meno traumatico. Non è pessimismo: è gestione del rischio.
Assicurati che il contratto con il nuovo fornitore preveda esplicitamente la proprietà del codice sorgente, la consegna del repository con storico completo e le procedure di uscita. Queste clausole si negoziano all’inizio, non quando il rapporto si deteriora.
Tieni aggiornata la documentazione tecnica come parte del lavoro ordinario, non come attività straordinaria. E verifica periodicamente che le credenziali degli ambienti siano accessibili a te, non solo al fornitore.
Per un approccio strutturato a questo tema, la guida sull’exit strategy software per PMI copre le clausole contrattuali e l’architettura indipendente dal fornitore.

FAQ

Q: Quanto tempo richiede il passaggio da un fornitore software a un altro?
A: Dipende dalla complessità del progetto e da quanto è documentato. Per un’applicazione medio-piccola con documentazione disponibile, bastano alcune settimane. Per sistemi grandi e mal documentati, l’onboarding può estendersi a qualche mese. La fase di audit iniziale è quella che determina tutto il resto.
Q: Il fornitore precedente è obbligato a consegnare il codice sorgente?
A: Dipende dal contratto. Se non specifica la proprietà del codice, la questione si complica. Prima di cambiare fornitore, verifica le clausole sulla proprietà intellettuale e sulla consegna del sorgente. In assenza di clausole chiare, potresti dover negoziare o ricorrere a un legale.
Q: Cosa fare se il codice ricevuto non ha documentazione?
A: Inizia con un audit tecnico per mappare l’architettura esistente. Strumenti di analisi statica e la lettura diretta del codice permettono di ricostruire la logica applicativa. Il problema più grave non è l’assenza di documentazione: è quando mancano anche le credenziali di accesso agli ambienti.
Q: Quando conviene riscrivere invece di prendere in carico il codice esistente?
A: Quando il costo di comprendere e mantenere il codice esistente supera quello di una riscrittura. Segnali concreti: dipendenze non aggiornabili, architettura senza test, nessuna separazione tra logica di business e presentazione. In quel caso, il refactoring o il software rescue diventano l’opzione più sensata.

Se stai affrontando un subentro su un progetto software aziendale e vuoi capire da dove partire, raccontaci il tuo caso: possiamo aiutarti a fare ordine prima di mettere mano al codice.