Migrazione da VB6, .NET Framework e sistemi legacy con metodo, priorita e riduzione del rischio
Qui trovi come affrontare software legacy e modernizzazione in modo progressivo: meno trauma, meno slogan da replatforming, piu priorita, piu messa in sicurezza e piu controllo economico del cambiamento.
Legacy non è una parolaccia: è un problema economico con soluzioni graduali
Il software legacy non è il software vecchio.
È il software che costa più di quanto produce: lento da modificare, difficile da capire, costoso da testare, rischioso da rilasciare.
Un sistema scritto ieri con un'architettura caotica è già legacy.
Un sistema scritto vent'anni fa con un'architettura pulita e documentata non lo è.
Il problema economico del legacy è reale e misurabile: ogni nuova feature richiede il doppio del tempo rispetto a un sistema equivalente moderno, ogni rilascio genera ansia perché nessuno sa con certezza cosa potrebbe rompersi, il team di sviluppo perde pezzi perché i senior non vogliono più lavorare su quel codice e i junior non riescono a orientarsi.
La modernizzazione non è la riscrittura.
La riscrittura è quasi sempre la risposta sbagliata: richiede anni, congela le nuove funzionalità, introduce nuovi bug e quasi mai mantiene la parità funzionale con il sistema originale.
La modernizzazione è un processo graduale, chirurgico e misurabile che riduce il costo del cambiamento un passo alla volta.
Questa categoria esiste per dare metodo a questo processo: non slogan sul cloud-native o sul microservizio, ma strumenti concreti per ridurre il rischio e aumentare la velocità di evoluzione di sistemi reali.
Strangler Fig e altri pattern per modernizzare senza fermare il business
Lo Strangler Fig è il pattern di modernizzazione più efficace per sistemi in produzione: invece di riscrivere tutto, si costruisce il nuovo sistema intorno a quello vecchio, si sposta il traffico gradualmente e si elimina il codice legacy man mano che il nuovo è pronto.
In pratica significa costruire un proxy o un facade che instradata le richieste: quelle che il nuovo sistema sa gestire vanno al nuovo, le altre continuano ad andare al legacy.
La migrazione avviene funzionalità per funzionalità, release per release, senza mai bloccare la produzione.
Altri pattern utili: Branch by Abstraction per sostituire componenti interni senza cambiare le interfacce esterne; Parallel Run per eseguire il vecchio e il nuovo sistema in parallelo e confrontare i risultati prima di fare il cutover definitivo; Anti-Corruption Layer per isolare il dominio nuovo dai modelli di dati del legacy.
Il punto comune di tutti questi pattern è l'incrementalità: nessuna big bang release, nessun momento in cui tutto il sistema è rotto allo stesso tempo, sempre una via di ritorno sicura se qualcosa non va come previsto.
Migrazione da VB6 e .NET Framework a .NET moderno: il percorso reale
VB6 e .NET Framework (1.x-4.8) sono le due tecnologie legacy più comuni che si trovano nell'ecosistema Microsoft.
Le strategie di migrazione sono diverse.
Da VB6: non esiste una migrazione automatica. Il codice VB6 non si converte in C# o VB.NET in modo affidabile: la semantica del linguaggio, il modello COM, i controlli ActiveX e i pattern tipici del VB6 non hanno equivalenti diretti. La strategia è isolare prima la logica di business (spesso sepolta nei form), riscriverla in .NET con test, e poi costruire la nuova UI sopra quella logica. L'interop COM permette di usare componenti VB6 esistenti durante la transizione.
Da .NET Framework a .NET moderno: dotnet upgrade-assistant automatizza la parte meccanica. Il vero lavoro è sui pacchetti NuGet che non supportano .NET 8/10, sulle API rimosse (System.Web è la più impattante per le web app MVC), e sui target framework multipli se la libreria deve supportare entrambi temporaneamente.
Il fattore più sottovalutato in entrambi i casi è la documentazione dei comportamenti impliciti: il sistema legacy ha comportamenti che nessuno ha mai scritto, che esistono solo nel codice e nella memoria delle persone.
Prima di migrare, bisogna documentarli come test di accettazione.
Sono quei test che certificano che la migrazione ha preservato il comportamento reale.
Come misurare il progresso della modernizzazione
La modernizzazione senza metriche diventa una missione senza fine dove non si sa mai se si sta avanzando o girando in tondo.
Le metriche che uso per tracciare il progresso sono pratiche e legate al business.
La percentuale di codice coperta da test automatici misura la riduzione del rischio di regressione.
Il tempo medio di una feature dalla specifica al deploy misura la riduzione del costo del cambiamento.
Il numero di incidenti in produzione per release misura la stabilità.
Il tempo di onboarding di un nuovo sviluppatore misura la comprensibilità del sistema.
Queste metriche non si migliorano tutte nello stesso momento.
Si sceglie quella che ha l'impatto maggiore sul costo attuale e si lavora su quella, misurando prima e dopo ogni intervento.
Il secondo strumento è la mappa del debito tecnico: un documento che categorizza le aree del sistema per costo di modifica e impatto sul business.
Le aree ad alto costo e alto impatto sono le prime da modernizzare.
Le aree a basso impatto si lasciano per ultime o si ignorano se il costo supera il beneficio.
La modernizzazione è un investimento, non una spesa.
Va giustificata, pianificata e misurata come qualsiasi altro investimento tecnologico.
Analisi, casi e articoli su legacy, migrazione e modernizzazione software
5 articoli trovati
I costi nascosti che nessuno ti dice quando costruisci o mantieni un team tecnico
Quanto costa davvero un team di sviluppo .NET nel 2026? Stipendi, costi nascosti, outsourcing vs interno: la guida completa per CTO e CEO.
Quanto ti costa davvero il software legacy: i costi nascosti che nessuno calcola e come costruire il business case per la modernizzazione
Il software legacy costa più di quanto pensi. Calcola il costo reale, i rischi GDPR e il business case per la modernizzazione.
Come costruire un team di sviluppo .NET che scala senza diventare un collo di bottiglia
Guida per CTO: come strutturare un team .NET che scala senza perdere qualità e controllo. Modelli organizzativi e metriche.
Come usare il bonus formazione 4.0 per ridurre davvero i costi
Il bonus formazione 4.0 può alleggerire il costo dei corsi e delle ore uomo. Guida pratica per chi vuole formare un team senza sprechi
Quando modernizzare diventa inevitabile
Modernizzare diventa inevitabile quando ogni modifica costa troppo, ogni rilascio fa paura e il software trattiene l'azienda invece di sostenerla. In quel momento servono metodo, migrazioni progressive e scelte tecniche che riducano il rischio senza bloccare il business.
Tecnologie chiave per uscire dal legacy
Cos'è VB.NET
Scopri VB.NET, il linguaggio per applicazioni aziendali, integrazioni complesse e per sfruttare l'ecosistema Microsoft con efficienza.
Migrazione da VB6 a .NET
Migrazione VB6: scopri come passare a .NET per migliorare efficienza, ridurre costi e garantire un futuro scalabile alle tue applicazioni legacy.
Cos'è Visual Basic
Cos'è Visual Basic e perché è popolare? Scopri tutto sul linguaggio di programmazione VB, come iniziare, le sue evoluzioni a .NET e molto altro.
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.
Fonti e riferimenti
Martin Fowler, Strangler Fig Application
Lo Strangler Fig Pattern di Fowler e il pattern architetturale piu pratico e meno rischioso per modernizzare sistemi legacy senza un big-bang rewrite. Lo cito come riferimento fondamentale perche descrive l'idea di sostituire gradualmente le funzionalita del vecchio sistema con quelle nuove, mantenendo entrambi attivi durante la transizione. E la strategia che consiglio in quasi tutti i progetti di modernizzazione.