Il primo obiettivo è ricostruire ciò che esiste
Quando un fornitore non segue più un software, l’azienda può temere di dover ripartire da zero. Non è sempre così. Prima di decidere serve capire quali componenti sono disponibili, come vengono eseguiti e quali conoscenze mancano.
Un progetto può essere recuperabile anche con documentazione incompleta, ma repository, accessi e dati determinano il punto di partenza. La priorità iniziale non è aggiungere nuove funzioni: è rendere il sistema osservabile, riproducibile e gestibile.
Raccogliere repository e codice sorgente
Il repository dovrebbe contenere il codice necessario a costruire l’applicazione e la sua storia utile. Va verificato se esistono più repository, branch non integrati, librerie interne o file conservati soltanto su computer e server.
Avere una cartella con il codice non garantisce che il progetto sia completo. Occorre provare a ricostruire dipendenze, configurazioni e processo di build senza alterare l’ambiente operativo.
Verificare accessi e responsabilità
Servono accessi amministrativi e tecnici ai servizi realmente coinvolti: repository, server, hosting, database, domini, certificati, servizi cloud, store, sistemi di monitoraggio e fornitori esterni. Gli accessi personali del precedente fornitore non dovrebbero diventare la base della continuità aziendale.
È importante sapere anche chi può autorizzare interventi, fornire dati di prova e validare il funzionamento. Il recupero non è soltanto tecnico: richiede responsabilità chiare.
Database, documentazione e infrastruttura
Il database va compreso prima di eseguire migrazioni o correzioni. Schema, dimensioni, backup, procedure di ripristino e qualità dei dati aiutano a valutare rischio e priorità. Le credenziali non devono essere copiate nella documentazione operativa o nel repository.
Anche una documentazione parziale può essere utile: diagrammi, manuali, ticket, log e procedure raccontano decisioni che il codice non rende immediatamente visibili. L’infrastruttura completa il quadro con ambienti, processi di rilascio, servizi pianificati e dipendenze esterne.
Un esempio concreto: applicazione funzionante ma non più distribuibile
Un’azienda dispone di un’applicazione ancora operativa e del codice sorgente, ma non sa come produrre una nuova versione. Prima di riscriverla, si può verificare il repository, ricostruire dipendenze e configurazioni in un ambiente separato, confrontare il risultato con la produzione e documentare il rilascio. Se il codice è completo e il database è comprensibile, il primo traguardo può essere tornare a costruire e testare il software in modo controllato.
Checklist di presa in carico
| Area | Verifica minima |
|---|---|
| Repository | Codice completo, branch, cronologia e dipendenze interne |
| Accessi | Account aziendali per server, servizi, domini e store |
| Database | Schema, backup verificabile e procedura di ripristino |
| Build | Dipendenze, configurazioni e risultato riproducibile |
| Infrastruttura | Ambienti, servizi, certificati e attività pianificate |
| Test | Scenari essenziali e persone che possono validarli |
| Operatività | Log, monitoraggio, incidenti noti e priorità |
Stabilizzare prima di evolvere
Dopo l’inventario tecnico, conviene separare incidenti bloccanti, rischi di continuità, difetti ricorrenti e richieste evolutive. Correggere tutto insieme rende difficile capire l’effetto di ogni intervento.
Una fase di stabilizzazione può includere riproduzione della build, backup verificati, correzione dei problemi più critici, logging sufficiente e definizione di un rilascio controllato. Solo dopo diventa più semplice organizzare il debito tecnico e una roadmap progressiva.
Dipendenze, test e debito tecnico
Le dipendenze obsolete non vanno aggiornate tutte senza una valutazione. Alcune sono urgenti per sicurezza o compatibilità; altre richiedono modifiche applicative e test. Il debito tecnico va ordinato per rischio e impatto, non per preferenza estetica.
Quando i test automatici mancano, si possono prima definire scenari essenziali ripetibili. Anche verifiche manuali documentate sono una base migliore di una modifica senza criteri di accettazione.
Quando una riscrittura può essere necessaria
Una riscrittura può diventare ragionevole se il codice sorgente indispensabile non è disponibile, il sistema non può più essere costruito, dipende da componenti irrecuperabili oppure il modello esistente non supporta più il processo aziendale. Anche in questi casi, dati, regole e comportamenti del software attuale restano materiale da analizzare: ripartire da zero non significa ignorare ciò che l’azienda ha imparato.
Quando non serve cambiare fornitore o avviare un recupero
Se il software è supportato, gli accessi sono sotto controllo aziendale e i problemi possono essere gestiti nel rapporto esistente, un passaggio di consegne può non essere necessario. Prima di avviare un intervento parallelo è utile chiarire responsabilità, disponibilità della documentazione e obiettivi reali.
Domande frequenti
Si può lavorare senza documentazione?
È possibile, ma aumenta l’attività di ricostruzione. Codice, log, database e confronto con gli utenti diventano le fonti principali e vanno valutati prima di promettere tempi o risultati.
Bisogna avere subito accesso alla produzione?
Serve comprendere la produzione, ma le prime analisi dovrebbero limitare i rischi e privilegiare copie, backup e ambienti separati. Gli accessi vanno assegnati secondo necessità.
È possibile continuare a usare il software durante il recupero?
Spesso sì, se si separano analisi e interventi e si pianificano modifiche compatibili con l’operatività. Dipende però dallo stato reale del sistema.
Quando si possono aggiungere nuove funzioni?
Dopo aver chiarito build, dati, rischi e modalità di rilascio. Anticipare evoluzioni su una base non governata può aumentare il problema.
Una presa in carico basata su evidenze
Per approfondire consulta Manutenzione e recupero software esistente, l’articolo su come modernizzare un software legacy e l’esperienza di recupero di un progetto software critico.
Se devi prendere in carico un software sviluppato da altri, indicaci quali sorgenti, accessi e ambienti sono disponibili: Trinaware Group può partire da un inventario tecnico e definire i primi passi senza presupporre una riscrittura.