Software sviluppato da altri: come cambiare fornitore senza perdere il controllo

Il software sviluppato da altri può continuare a servire la tua azienda anche quando lo sviluppatore non è più disponibile. Se devi cambiare fornitore, il primo obiettivo è poter affidare il sistema a qualcuno sapendo quali materiali hai, cosa deve continuare a funzionare e quali verifiche mancano.

Per prendere in carico l’applicazione servono accessi autorizzati, una versione identificabile del codice, i dati necessari e un referente che sappia descrivere il comportamento atteso. Prima di decidere di rifarla, conviene distinguere ciò che oggi ne impedisce la gestione dalle parti che non rispondono più al lavoro del team.

Prima di cambiare fornitore, descrivi ciò che deve continuare a funzionare#

Partire dall’elenco dei bug è utile, ma non basta a spiegare il prodotto. Prepara anche alcuni percorsi che l’azienda usa davvero: aprire una commessa, assegnare un’attività, aggiornare un cliente, produrre un documento. Indica chi li svolge e quale risultato si aspetta.

Per ogni problema raccogli il punto di partenza, i passaggi, il risultato atteso e quello osservato. Se compare soltanto con alcuni dati o utenti, annotalo. Per le prime valutazioni usa esempi privi di informazioni riservate; gli accessi tecnici si concordano nel perimetro dell’incarico.

Cosa raccogliere per il passaggio di consegne#

L’inventario deve distinguere ciò che l’azienda controlla, ciò che può ottenere e ciò che manca. Non condividere password in un foglio: registra il servizio, il responsabile e il modo autorizzato per concedere l’accesso.

Il repository è un punto di partenza, non l’intera applicazione#

Il repository è l’archivio del codice e della sua cronologia. Una copia dei file può essere insufficiente per ricostruire le decisioni e la versione in uso. GitHub documenta il backup completo della cronologia tramite una copia mirror: è una possibilità tecnica, da scegliere secondo l’ambiente del progetto. Fonte: GitHub, backup dei repository.

Se il progetto è su GitHub, un trasferimento di proprietà porta con sé anche diversi elementi associati, compresi webhook, segreti e chiavi di deploy. Per questo il trasferimento va seguito da una revisione delle integrazioni e degli accessi, non trattato come un semplice cambio di cartella. Fonte: GitHub, trasferimento di un repository.

L’accesso tecnico e la proprietà del codice sono aspetti distinti. Prima di intervenire, occorre chiarire cosa consente l’accordo e quali componenti dipendono da licenze o servizi esterni. La guida sulla proprietà di un prodotto digitale aiuta a costruire questo inventario; i dubbi sul contratto richiedono una verifica dedicata.

Dati e backup devono essere consegnabili e ripristinabili#

Chiedi dove si trovano i dati, quali allegati restano fuori dal database e chi può eseguire un recupero. Un file chiamato “backup” non dimostra da solo che l’applicazione possa essere riavviata con quei materiali.

Per PostgreSQL, ad esempio, la documentazione distingue la creazione del dump dal ripristino e precisa le condizioni degli strumenti da usare. Nell’incarico proporrei una prova in ambiente separato, con controlli sui dati necessari ai flussi scelti. Il metodo concreto dipende dal database e dall’infrastruttura. Fonte: PostgreSQL, SQL Dump.

Come dovrebbe iniziare la presa in carico#

1. Concordare il perimetro: applicazione, ambienti, accessi, problemi e persone coinvolte.
2. Ricostruire il funzionamento: versione online, dipendenze, servizi e dati necessari.
3. Riprodurre i problemi scelti in condizioni controllate e annotare ciò che non è verificabile.
4. Proporre priorità e alternative, distinguendo correzioni, aggiornamenti e riscritture.
5. Verificare gli interventi sugli stessi casi e preparare rilascio e ripristino quando inclusi.

Se i bug sono già chiari e gli accessi disponibili, si può valutare un preventivo diretto per gli interventi. Se manca una visione attendibile dello stato del progetto, può essere utile una consulenza circoscritta. Sono modalità da scegliere sul caso, non una sequenza obbligatoria.

Riparare, sostituire una parte o riscrivere?#

Una nuova interfaccia non risolve automaticamente dati incoerenti o integrazioni fragili. Allo stesso modo, mantenere ogni componente può diventare poco ragionevole se una dipendenza non è più utilizzabile o il prodotto non rappresenta il processo reale.

Chiedi che la proposta spieghi quali parti si conservano, quali si cambiano e con quale evidenza. Per una riscrittura, devono emergere anche migrazione, convivenza temporanea e criteri per spegnere il vecchio sistema. Senza questi elementi, confrontare due preventivi soltanto sul totale può nascondere perimetri diversi.

Quando il passaggio può dirsi verificato#

• L’azienda sa chi controlla ogni servizio e come recuperare l’accesso.
• La versione del codice è identificata e l’ambiente concordato è avviabile.
• I dati e gli allegati inclusi sono disponibili e controllati.
• I flussi essenziali hanno casi di prova ed esiti registrati.
• I punti ancora aperti hanno priorità, responsabile e prossimo passo.

È possibile consegnare un inventario con limiti espliciti anche quando non tutto è recuperabile. Un accesso mancante non va trasformato in una promessa di ripristino: deve diventare una dipendenza visibile nella proposta.

Il software vi serve ancora, ma non c’è più chi lo segue?#

Se la tua azienda usa già l’applicazione e deve capire a chi affidarla, possiamo valutare la presa in carico del software esistente. Nel primo confronto gratuito di 30 minuti con Matteo valutiamo il contesto e la compatibilità con LuCz.

Racconta quale lavoro sostiene il software, cosa oggi impedisce di gestirlo e quali materiali hai disponibili. Il confronto serve a valutare il possibile primo incarico, prima di concordare accessi o attività tecniche.

Nella pagina lasci i recapiti e una breve descrizione, poi scegli giorno e ora. Eventuali analisi tecniche, accessi e interventi successivi vengono concordati separatamente, con perimetro, responsabilità e costo espliciti.

Fonti#

• GitHub Docs, Transferring a repository.
• GitHub Docs, Backing up a repository.
• PostgreSQL 18, SQL Dump.
• LuCz, Stabilizzazione e manutenzione software esistente.
• LuCz, Proprietà di un prodotto digitale.

Fonti consultate il 2 novembre 2026. Inventario e percorso di verifica sono indicazioni operative da adattare all’applicazione.