Non seguo più la manutenzione di progetti tecnicamente obsoleti, ma mi capita spesso di portarli su tecnologie attuali. È un lavoro che richiede una cura particolare: dietro un cambio di versione si nascondono spesso librerie da sostituire, architetture da ristrutturare e configurazioni da ripensare.
In ambienti con controlli di sicurezza stretti, una versione senza aggiornamenti diventa presto un problema.
Quando il supporto finisce non arrivano più correzioni di sicurezza. Dove ci sono vincoli di sicurezza e privacy, questo può bloccare un rilascio o emergere in un audit.
Il caso più lineare: lo stesso prodotto, in una versione più recente.
Anche qui il salto può essere grande. Da AngularJS ad Angular si tratta in pratica di riscrivere l'interfaccia; tra versioni di Angular si procede una versione principale alla volta, verificando a ogni passo le modifiche incompatibili.
Spesso vanno riscritte parti basate su librerie obsolete, soprattutto lato client ma anche lato server.
Molte librerie JavaScript nascondono dietro un cambio di versione un pesante re-engineering. Lato server, alcune hanno cambiato licenza: è il caso delle applicazioni che usano iTextSharp 4.1.6, l'ultima versione con licenza LGPL. Le versioni successive sono disponibili solo con licenza AGPL o commerciale, e per .NET attuale esiste solo un porting non ufficiale della 4.1.6.
Adeguarsi agli standard attuali significa ristrutturare, non solo ricompilare.
Molte applicazioni .NET Framework usano pattern superati, come classi statiche e dipendenze create a mano, mentre il .NET attuale si basa sulla dependency injection. Alcune tecnologie, poi, non hanno un equivalente diretto.
Ho migrato applicazioni Web Forms verso web app moderne, convertendo il code-behind in Web API, e in un caso verso Blazor, per restare su uno stack interamente Microsoft. Allo stesso modo ho portato servizi WCF su API REST: qui la parte delicata è spesso il formato dei dati, perché i client davano per scontata la serializzazione di WCF.
Da un server tradizionale al cloud, la migrazione non è solo applicativa.
Configurazioni, architettura, permessi e accesso ai dati vanno analizzati e ripensati per arrivare a una soluzione pronta per il cloud. Sono gli elementi che ho incontrato nelle migrazioni di questo tipo.
Inventario di dipendenze, librerie, licenze e integrazioni. Per ognuna si decide se aggiornarla, sostituirla o riscriverla, e quali ristrutturazioni servono.
Le funzionalità necessarie a verificare che la nuova architettura regga, in esecuzione il prima possibile.
Un piano passo per passo, con test di regressione a ogni passaggio.
Chi usa il sistema comincia a provare le parti migrate man mano che sono pronte.
Quando possibile, i due applicativi lavorano affiancati. Da AngularJS ad Angular gli utenti li hanno usati insieme, per confrontarli e per le funzioni non ancora migrate.
Ogni migrazione è un percorso unico: dipende da dove si parte, da dove si vuole arrivare e da tutti questi fattori. Quello che non cambia è il metodo: rischi analizzati prima, passi graduali e verificabili.
L'analisi iniziale può essere anche una prestazione a sé. Più spesso, con i clienti diretti, è il primo passo di un percorso che arriva fino all'applicazione migrata e in produzione, senza che il cliente debba portarsi lo sviluppo in casa.
Nelle migrazioni uso i coding agent con il metodo spec-driven: partendo dal codice esistente stabilisco la sequenza dei passi, e alterno i test eseguiti dall'agente con prove dirette.
L'agente è meno affidabile proprio sul codice legacy, ed è lì che l'analisi a priori serve di più. Anche Microsoft ha sostituito il suo strumento di aggiornamento, Upgrade Assistant, con un agente basato sull'IA.
I casi pubblicati sono una selezione: le altre migrazioni descritte in questa pagina vengono da progetti non riportati sul sito.