Migrare un software legacy significa portare un gestionale vecchio, ancora funzionante ma costruito su tecnologie superate, su una base nuova. Il problema non e tecnico: e come farlo senza fermare l’azienda che ci lavora sopra ogni giorno. Questo articolo spiega la strategia che riduce il rischio al minimo.
Cos’e un software legacy e perche prima o poi va rifatto
Un software legacy e un sistema che funziona ancora ma e diventato difficile da modificare, costoso da mantenere, e con sempre meno persone in grado di metterci mano. Le tecnologie su cui e costruito non ricevono piu aggiornamenti, trovare sviluppatori che le conoscono e sempre piu raro e caro, e ogni piccola modifica richiede piu tempo di quanto dovrebbe.
A un certo punto il costo di tenerlo in vita supera il costo di rifarlo. Il momento giusto per affrontare la migrazione e prima che diventi un’emergenza, quando puoi ancora pianificarla con calma.
Perche non si rifa tutto in una volta
La tentazione e chiara: si sviluppa il nuovo sistema in parallelo per mesi, e un giorno si spegne il vecchio e si accende il nuovo. Questo approccio, chiamato big bang, e quello che fa fallire piu migrazioni.
Il motivo e semplice. Per mesi paghi lo sviluppo senza vedere nulla in produzione, i requisiti cambiano mentre lavori perche l’azienda non si ferma, e il giorno del passaggio scopri tutti i problemi insieme, con il sistema fermo e le persone che non possono lavorare. Il rischio e concentrato tutto in un momento, il peggiore possibile.
La strategia a piccoli passi per migrare un software legacy
Si sostituisce il vecchio sistema un pezzo alla volta. Si sceglie una funzione, la si ricostruisce sulla base tecnologica nuova, la si mette in produzione, la si collega al resto del vecchio sistema che continua a girare. Poi si passa alla funzione successiva.
Il vecchio e il nuovo convivono per tutta la durata della migrazione. Ogni pezzo che passa alla base nuova e gia in uso e gia testato dalle persone vere, non in un ambiente di prova. Quando l’ultimo pezzo e migrato, il vecchio sistema si spegne senza traumi, perche non gestisce piu niente di vivo.
Come si gestisce il rischio
- Si parte dai pezzi a basso rischio. Una funzione usata da poche persone, o una che se si ferma per un’ora non blocca la produzione. Cosi i primi passaggi servono anche a collaudare il metodo prima di toccare le parti critiche.
- Si tiene sempre una via di ritorno. Per ogni pezzo migrato si puo tornare al vecchio in poche ore se qualcosa non va come previsto.
- Si migrano i dati con controlli automatici. Ogni volta che si spostano dati dal vecchio al nuovo, un controllo verifica che numeri, totali e conteggi coincidano. Se non coincidono, il passaggio non si fa.
- Si coinvolgono le persone che usano il sistema. Sono loro ad accorgersi per prime se un pezzo nuovo si comporta in modo anche solo leggermente diverso dal vecchio.
Un esempio concreto
Ho seguito la migrazione di una piattaforma contabile usata dai clienti di uno studio professionale: da una versione ormai vecchia della tecnologia a una nuova, e da un’architettura monolitica a una organizzata in servizi separati. Il software e rimasto in uso per tutta la durata del lavoro, che si e misurata in mesi.
I clienti non hanno mai avuto un’interruzione di servizio. In parallelo alla migrazione e stata ricostruita anche la pipeline di rilascio, cioe il modo in cui gli aggiornamenti vanno in produzione, per rendere ogni passaggio successivo piu rapido e piu sicuro del precedente.
Quanto tempo serve
Dipende da quanto e grande il sistema e da quanti pezzi lo compongono. Una migrazione a piccoli passi, sulla carta, dura piu a lungo di un big bang. In pratica pero finisce prima, perche non ci sono i mesi di blocco e correzione che seguono sempre un passaggio fatto tutto in una volta.
E soprattutto, durante la migrazione a piccoli passi l’azienda continua a lavorare. Con il big bang, spesso, no.
Hai un software che sta diventando difficile da mantenere? Guarda la pagina sul servizio, oppure prenota una call gratuita.