Modernizzare software legacy senza bloccare il business e senza rifare tutto da zero
Domande frequenti
La modernizzazione conviene quando i costi di manutenzione annuali del legacy (bug difficili da correggere, sviluppatori scarsi, impossibilita di usare nuove librerie) superano il costo stimato del porting. Un indicatore semplice: se la modifica di una funzionalita richiede settimane invece di giorni, se l'onboarding di un nuovo sviluppatore richiede mesi, o se l'applicazione non puo girare in cloud, la modernizzazione e economicamente giustificabile.
La migrazione piu comune e dal .NET Framework 4.x a .NET 8. Il percorso e: analisi delle dipendenze con .NET Upgrade Assistant, sostituzione delle librerie non compatibili (es. System.Web con ASP.NET Core), migrazione del progetto al formato SDK-style, e testing progressivo. Per applicazioni grandi si usa la tecnica dello Strangler Fig: si costruisce il nuovo sistema a fianco del vecchio, migrando modulo per modulo.
VB6 non ha un percorso di migrazione diretto verso .NET. Le opzioni sono: riscrittura completa in C# (costosa ma pulita), conversione a VB.NET come primo step e successiva migrazione a C#, o wrapping dell'applicazione VB6 esistente tramite COM interop in un layer .NET che la chiama. La scelta dipende dalla complessita, dal budget e dalla disponibilita di documentazione sulla logica di business.
Il debito tecnico si gestisce con una strategia deliberata, non con una riscrittura totale. Si identificano le aree a piu alto costo (quelle che causano piu bug o rallentano di piu le modifiche), si stima il costo di riduzione, e si negozia una quota fissa di capacita del team dedicata al miglioramento tecnico (tipicamente 20-30%). Senza questa quota esplicita il debito cresce sempre piu velocemente delle nuove funzionalita.