Il fornitore del gestionale ha chiuso: come recuperare software e dati

La conclusione prima di tutto

Se il fornitore del tuo gestionale ha chiuso, i primi giorni contano più di tutti quelli dopo: quello che fai adesso decide quanto sarà complicato il resto. Questa guida ti dice esattamente cosa fare, in quale ordine, e dove di solito si sbaglia. Il resto dell’articolo dimostra perché questo ordine conta.

Passo 1: blocca tutto e fai un inventario

Non aspettare di capire cosa è successo davvero al fornitore. La prima mossa è difensiva.

Cosa fare

Accedi al sistema con le credenziali amministrative e blocca tutti gli utenti non necessari. Se il gestionale gira su server del fornitore, scarica subito un backup completo del database. Se gira su un tuo server, fai uno snapshot dell’intera macchina virtuale.
Poi apri una cartella condivisa con il tuo team e raccogli tutto quello che trovate: contratti firmati, email con allegati tecnici, manuali utente, credenziali di accesso ai server, eventuali repository Git che il fornitore vi aveva condiviso. Ogni documento conta.

Cosa va storto di solito

La maggior parte delle aziende perde tempo a cercare di contattare il fornitore, sperando in una risposta che non arriverà. Nel frattempo il server potrebbe andare offline, il dominio scadere, i backup automatici smettere di girare. Agisci prima di capire tutto, non dopo.

Passo 2: verifica cosa possiedi legalmente

Qui entra in gioco il contratto, e spesso è la brutta sorpresa.
Molti contratti di sviluppo software non trasferiscono la proprietà del codice sorgente al cliente. Il cliente paga per usare il software, non per possederlo. Se il tuo contratto non dice esplicitamente che il codice sorgente ti appartiene, potresti trovarti in una posizione difficile.
Leggi il contratto cercando queste parole: “cessione dei diritti patrimoniali”, “proprietà intellettuale”, “codice sorgente”, “escrow”. Se non trovi nulla di esplicito, consulta un legale prima di muoverti sul codice: scaricare qualcosa che non ti appartiene, anche da un fornitore fallito, può creare problemi.
Se invece il contratto è chiaro sulla tua proprietà, hai campo libero per procedere.

Passo 3: recupera il codice sorgente

Con i diritti chiari, il passo successivo è mettere le mani sul codice.

Tre scenari possibili

Scenario A: hai già il repository. Il fornitore ti aveva dato accesso a un repository Git (su GitHub, GitLab o simili). Clona tutto in locale subito, prima che l’account venga disattivato.
Scenario B: il codice è sul server. Se il gestionale gira su un server che controlli tu, entra via SSH e comprimi l’intera directory del progetto. Poi spostala su un tuo storage sicuro.
Scenario C: non hai accesso a nulla. Qui serve un tecnico esterno. Un professionista con accesso al server (o con le credenziali che riesci a recuperare) può estrarre il codice. Se il fornitore è fallito formalmente, il curatore fallimentare gestisce i beni digitali: puoi richiedere il codice come parte della procedura, ma i tempi si allungano di molto.

Cosa va storto di solito

Spesso il codice esiste ma non è documentato. Trovi file senza struttura chiara, dipendenze non dichiarate, variabili d’ambiente mancanti. Non è un problema insormontabile, ma significa che la fase di analisi successiva richiederà più tempo di quanto pensavi.

Passo 4: metti al sicuro i dati del database

Il codice si può riscrivere. I dati storici, no.
Questa è la priorità assoluta se sei costretto a scegliere dove concentrare le energie nelle prime ore. Un database relazionale (MySQL, PostgreSQL, SQL Server) è leggibile indipendentemente dall’applicazione che ci gira sopra. Anche senza il codice del gestionale, un tecnico può aprire il database, leggere le tabelle e estrarre i dati in formato CSV o JSON.
Fai un dump completo del database, verificane l’integrità aprendo almeno tre tabelle principali, e conserva il file in almeno due posti fisicamente separati. Un hard disk esterno e un bucket cloud vanno bene.
Se il database è cifrato e non hai la chiave, la situazione si complica. In quel caso serve sapere se la chiave era gestita dal fornitore o da te: guarda nelle variabili d’ambiente o nei file di configurazione del progetto.

Passo 5: analizza cosa hai recuperato

A questo punto hai un quadro. Prima di decidere cosa fare, fai un’analisi di quello che hai raccolto.
Chiedi a un tecnico di rispondere a queste domande:

1. Il codice sorgente è completo e avviabile?
2. Il database è leggibile e i dati sono integri?
3. Quali dipendenze esterne usa il software (librerie, API di terzi, servizi cloud)?
4. Ci sono parti del sistema che dipendono da infrastrutture del fornitore che non esistono più?

Le risposte determinano il percorso. Se il codice è completo e avviabile, puoi pensare di continuare a usarlo con un nuovo team di manutenzione. Se è parziale o illeggibile, devi valutare se ricostruire o cambiare approccio.
Questa analisi è il primo passo di un intervento di software rescue: prendere in carico un software rimasto senza chi lo manteneva e stabilire, con dati alla mano, cosa regge e cosa va rifatto.
Se ti trovi in questa fase e non sai da dove partire, raccontaci il tuo caso: un’analisi tecnica iniziale chiarisce le opzioni concrete in tempi brevi.

Passo 6: decidi il percorso di continuità

Tre strade, ognuna con le sue implicazioni.
Strada 1: manutenzione del codice esistente. Se il sorgente è recuperato e leggibile, puoi affidare la manutenzione a un nuovo fornitore. È la strada più veloce per tornare operativo. Il rischio è che il codice abbia debito tecnico accumulato che il nuovo team scoprirà nel tempo. Vale la pena leggere cosa significa gestire manutenzione software custom prima di firmare un nuovo contratto.
Strada 2: refactoring parziale. Il codice esiste ma ha parti critiche non funzionanti o non documentate. Si interviene solo sulle aree problematiche, mantenendo il resto. Richiede un’analisi tecnica precisa per capire dove si può tagliare e dove no. Se parti del gestionale erano state generate con strumenti AI, il problema cambia forma: il codice gira ma la logica non è documentata da nessuna parte, e serve un percorso specifico di manutenzione di software creato con l’AI.
Strada 3: sostituzione. Se il gestionale era poco personalizzato o se i costi di recupero superano il valore, può avere senso valutare un SaaS o una riscrittura da zero. La scelta dipende da quanto i tuoi processi erano modellati sul software precedente. Un confronto ragionato tra i due approcci lo trovi nell’articolo su software custom vs SaaS.
La terza strada viene scelta troppo in fretta. Buttare via un gestionale costruito su processi specifici significa spesso perdere anni di ottimizzazioni implicite che nessuno ha documentato. Prima di decidere, fai fare un’analisi tecnica seria.

Passo 7: cambia i contratti futuri

Questo è il passo che quasi nessuno fa, e che invece è l’unico modo per non trovarsi di nuovo nella stessa situazione.
Qualunque nuovo contratto di sviluppo software deve contenere:

• Cessione esplicita dei diritti patrimoniali sul codice sorgente al cliente
• Obbligo di consegnare il repository aggiornato a ogni rilascio
• Accesso diretto al server o all’infrastruttura, senza intermediari
• Clausola di escrow del codice (il codice viene depositato presso terzi e rilasciato al cliente in caso di cessazione del fornitore)

Un contratto senza queste clausole difficilmente ti protegge. Non è una questione di fiducia nel fornitore: è che le aziende chiudono, cambiano proprietà, smettono di seguire certi clienti. Avere il codice in mano, o un escrow che lo depositi per te, è la garanzia più solida di continuità.

Domande frequenti

Q: Cosa faccio subito se il fornitore del mio software ha chiuso?
A: Blocca gli accessi al sistema, fai un backup completo di tutti i dati e recupera tutta la documentazione contrattuale. Poi valuta se il codice sorgente è in tuo possesso o se devi richiederlo tramite procedure legali o tecnici terzi.
Q: Posso recuperare i dati dal database se non ho il codice sorgente?
A: Sì, nella maggior parte dei casi. Un database relazionale è leggibile indipendentemente dall’applicazione. Serve un tecnico che mappi la struttura delle tabelle e estragga i dati in formato standard. I dati storici spesso si recuperano, ma dipende da dove sono ospitati e da chi controlla il server; le logiche applicative quasi mai.
Q: Quanto tempo ci vuole per rimettere in piedi il gestionale?
A: Con il sorgente completo e un database leggibile, qualche settimana per stabilizzare l’ambiente. Senza sorgente, prima serve una fase di analisi e poi una decisione su ricostruzione o sostituzione: i tempi si allungano sensibilmente. Non esistono stime valide prima di vedere cosa c’è da recuperare.
Q: Conviene ricostruire il gestionale da zero o passare a un SaaS?
A: Dipende da quanto il gestionale era personalizzato sui tuoi processi. Se la personalizzazione era alta, ricostruire ha senso. Se usavi funzioni standard, un SaaS copre la maggior parte dei casi con meno rischi. La scelta si fa dopo aver visto cosa si riesce a recuperare, non prima.

Se il tuo fornitore ha chiuso e non sai da dove partire, in Press Start affrontiamo analisi di codice ereditato e recupero di ambienti non documentati: è il nostro servizio di software rescue. Richiedi l’analisi del software: capiamo insieme cosa c’è da fare.