Fino a quando funzioneranno le applicazioni VB6? — Lo stato del supporto al runtime e un percorso pratico verso la migrazione a .NET

“Questo sistema in VB6, fino a quando continuerà a funzionare?” — è una delle domande più frequenti nelle consulenze su sistemi legacy.

La risposta è sorprendentemente chiara: Microsoft ha pubblicato una politica di supporto ufficiale. Il contenuto, però, è asimmetrico: “il runtime continuerà a funzionare ancora per un po’, ma non c’è più alcun sostegno sul fronte dello sviluppo”. Senza comprendere correttamente questa asimmetria, si finisce per oscillare tra due conclusioni estreme: “funziona ancora, quindi va bene così” e “bisogna rifare tutto subito”.

Su questo blog, l’articolo “Prolungare la vita e migrare le applicazioni business VB6 / Access — una tabella di decisione tra mantenere, avvolgere e sostituire” ha messo in ordine la decisione su come trattare gli asset VB6. Questo articolo ne è la continuazione: una volta deciso di sostituire (migrare) — o per aiutare a decidere — approfondisce come portare avanti concretamente una migrazione da VB6 a .NET.

1. Prima di tutto, la sintesi

• Il supporto dell’IDE VB6 (ambiente di sviluppo) è terminato l’8 aprile 2008. Non esiste più alcun modo supportato per creare o mantenere applicazioni VB6, e Microsoft raccomanda fortemente di sostituirle con tecnologie moderne.¹
• Il runtime VB6, invece, è supportato “finché è supportata la versione di Windows con cui viene distribuito”. L’elenco dei sistemi operativi coperti include Windows 11, Windows 10 e Windows Server 2025, e l’obiettivo è che le applicazioni esistenti “continuino semplicemente a funzionare” (It Just Works).² In altre parole, la risposta a “fino a quando funzionerà” è: per la sola esecuzione, finché è supportata Windows stessa.
• Tale supporto, tuttavia, è limitato alla gestione di regressioni gravi e problemi di sicurezza critici nelle applicazioni esistenti. Il runtime è inoltre esclusivamente a 32 bit e, su Windows a 64 bit, è supportato solo all’interno dell’ambiente WOW64.²
• Il vero rischio non è “smettere di funzionare”, ma perdere la capacità di correggere. Ottenere e mantenere l’IDE diventa più difficile ogni anno, il supporto dei fornitori dei controlli OCX utilizzati si esaurisce, e le persone ancora in grado di scrivere VB6 vanno in pensione o cambiano lavoro. Questi tre fattori procedono indipendentemente dalla durata del supporto di Windows stessa.
• Esistono tre approcci generali alla migrazione: riscrittura completa, conversione automatica e migrazione graduale. La prima cosa da decidere non è l’approccio, ma l’inventario: occorre valutare il numero di schermate, le integrazioni esterne, il volume di controlli OCX e di dichiarazioni API prima di scegliere l’approccio.
• Per il linguaggio target della migrazione, C# è consigliato per tutto ciò che viene scritto da zero. Microsoft ha dichiarato ufficialmente che VB.NET (Visual Basic) è su un percorso di design stabile, senza nuova sintassi e senza estensione a nuovi tipi di carico di lavoro.³

2. La risposta precisa a “fino a quando funzionerà” — come leggere la politica di supporto

La politica di supporto VB6 di Microsoft spiega VB6 suddividendolo in tre componenti.²

Nella tabella dei sistemi operativi coperti, Windows 11, Windows 10 e Windows Server dal 2012 al 2025 sono esplicitamente indicati come “runtime: supportato”, “IDE: non supportato”.²

Ci sono tre punti chiave per leggere correttamente questa politica.

Primo, il supporto del runtime è interamente subordinato al ciclo di vita di Windows. Non esiste una data indipendente chiamata “fine del supporto del runtime VB6”: la fine del supporto della versione di Windows in uso è, di fatto, la scadenza stessa.

Secondo, il contenuto sostanziale del supporto è più vicino a una garanzia che le cose “continuino a funzionare” che a qualsiasi altra cosa. Ciò che viene gestito si limita alle regressioni gravi (quando un aggiornamento del sistema operativo rompe un’applicazione esistente) e ai problemi di sicurezza critici; non include indagini individuali o miglioramenti delle funzionalità.²

Terzo, le applicazioni VB6 potranno continuare a esistere d’ora in poi solo come processi a 32 bit. Il runtime è esclusivamente a 32 bit, e sui sistemi operativi a 64 bit è supportato solo all’interno dell’ambiente di emulazione WOW64.² Nel momento in cui emerge la necessità di interagire con una DLL o un SDK esclusivamente a 64 bit, un singolo processo non è più sufficiente a portare a termine il compito da solo. Abbiamo trattato come superare questo ostacolo in “Un caso di studio di ponte COM: chiamare una DLL a 64 bit da un’applicazione a 32 bit”.

3. “Funzionare” e “restare mantenibile” sono problemi diversi

Guardando solo alla politica di supporto, si potrebbe pensare che “non c’è fretta”. In pratica, però, l’ambiente di sviluppo e manutenzione si deteriora molto prima dell’ambiente di esecuzione.

• Non si riesce a procurarsi l’IDE. L’IDE VB6 non è supportato sui sistemi operativi attuali, e mantenere un modo ufficiale per ottenerlo e installarlo diventa più difficile ogni anno. Non è raro trovare aziende in cui “esiste una sola macchina in tutta l’azienda ancora in grado di correggere il codice”.
• Il supporto dei fornitori per i controlli OCX di terze parti è terminato. La stessa politica di supporto dichiara chiaramente che i controlli di terze parti rientrano nella responsabilità del fornitore.² È frequente che i controlli OCX per griglie o report siano già irreperibili, e la logica decisionale che abbiamo delineato in “Come gestire oggi ActiveX / OCX” si applica direttamente anche qui.
• Le persone in grado di scriverlo scompaiono. Non è un problema di specifica del linguaggio, ma un problema di persone. Quasi nessun nuovo ingegnere sta imparando VB6, quindi il numero di persone in grado di occuparsene in manutenzione può solo diminuire.
• I requisiti circostanti si scontrano con il muro dei 32 bit. Nuovi SDK per dispositivi, librerie di autenticazione, integrazioni cloud presuppongono sempre più spesso 64 bit e .NET, e i requisiti che non possono essere integrati direttamente in un processo VB6 continuano ad aumentare.

In altre parole, “fino a quando funzionerà” è solo metà del problema. L’altra metà è: “quando servirà la prossima correzione, ci saranno ancora le persone e l’ambiente per realizzarla?” I piani di migrazione vanno redatti non dopo che qualcosa si è rotto, ma mentre le persone e l’ambiente in grado di sistemare le cose sono ancora disponibili.

4. Una tabella di decisione per gli approcci di migrazione

Anche una volta deciso di sostituire il sistema, esiste una gamma di modi per procedere. Ecco una panoramica degli approcci principali.

Quale scegliere non è determinato solo dal numero di righe di codice. La stessa Microsoft, oltre alle guide ufficiali, indirizza verso partner di upgrade e migrazione (inclusi i fornitori di strumenti di migrazione) per questo tipo di progetto¹, quindi la conversione meccanica è un’opzione reale e concreta. Indipendentemente dall’approccio scelto, però, l’inventario del prossimo capitolo è un prerequisito comune.

Da notare che gli aspetti pratici della scelta di “mantenere lo stato attuale + documentare” (fissare l’ambiente di esecuzione, i backup, come accettare il rischio) sono trattati nell’articolo precedente su VB6 / Access.

5. Inventario prima della migrazione — cosa esaminare prima di toccare il codice

L’accuratezza della stima e la scelta dell’approccio dipendono entrambe dall’accuratezza dell’inventario. Elencate almeno quanto segue.

1. Un elenco delle schermate e dei report — il numero di form, le schermate effettivamente utilizzate (migrare schermate inutilizzate è uno sforzo sprecato), i tipi di report e dove vengono generati (stampa diretta o tramite Excel)
2. Un elenco delle integrazioni esterne — quale tra ADO/DAO/RDO è usato per il database e a cosa si connette, l’I/O su file, la comunicazione seriale o via socket, le chiamate ad altri sistemi
3. Un elenco dei riferimenti a OCX / ActiveX / COM — è possibile estrarli meccanicamente dai riferimenti nel file di progetto (.vbp). La reperibilità di ciascun componente e l’esistenza di alternative influiscono direttamente sulla scelta dell’approccio
4. Un elenco delle dichiarazioni di API Win32 (istruzioni Declare) — classificate ciascuna in base all’uso dell’API (stampa, lettura/scrittura di file INI, manipolazione di finestre, ecc.) e valutate se può essere sostituita con una funzionalità standard di .NET
5. Le regole di business che esistono solo nel codice — arrotondamenti, date di chiusura, eccezioni specifiche per partner, e così via. I punti in cui “nessuno sa perché è scritto così” sono esattamente il terreno fertile per i bug post-migrazione
6. La disponibilità di un metodo di test — con cosa confrontare il comportamento migrato per confermarne la correttezza. Nella maggior parte dei casi, confrontare l’output con quello del vecchio sistema (report, CSV, contenuto del database) è il metodo di verifica più pratico

Questo inventario non va sprecato nemmeno se alla fine non si sceglie la riscrittura completa. Anzi, è normale che i risultati dell’inventario rivelino uno spunto per una migrazione graduale — “pensavamo servisse una riscrittura completa, ma in realtà la logica centrale può essere spostata sul lato database”, oppure “migrare prima solo queste dieci schermate basta a superare il muro dei 64 bit”.

6. Principali incompatibilità tra VB6 e .NET

VB6 e VB.NET/C# sono linguaggi più distanti tra loro di quanto suggeriscano i nomi. Sia con la conversione meccanica sia con la riscrittura manuale, le seguenti differenze richiederanno sempre decisioni progettuali.

Ciò che conta qui è non lasciarsi sopraffare dalla mole di incompatibilità al punto da considerare la riscrittura completa come unica opzione. Al contrario, il semplice fatto che gli asset sul lato sinistro di questa tabella (VB6) funzionino ancora correttamente oggi è la migliore specifica disponibile per la migrazione. Far girare il vecchio sistema in parallelo come “specifica vivente” e confrontare gli output man mano che si procede è, in pratica, l’approccio più affidabile.

7. Pattern pratici per la migrazione graduale

Quando si migra senza fermare il business, il modo in cui vecchio e nuovo coesistono diventa il punto cruciale. Ecco tre pattern rappresentativi.

7.1 Migrare prima lo strato dati

In questa configurazione, i dati dell’applicazione VB6 vengono migrati per primi da un file Access o da un formato proprietario verso, ad esempio, SQL Server, mentre il lato VB6 continua a funzionare semplicemente cambiando la destinazione della connessione. Una volta che i dati sono stati modernizzati per primi, le nuove schermate (sul lato .NET) possono essere aggiunte gradualmente, facendo riferimento allo stesso database. Per i passaggi concreti relativi ad Access, vedere il capitolo sull’upsizing dell’articolo precedente.

7.2 Costruire nuove funzionalità e schermate in .NET, collegate tramite interoperabilità COM

Questa è una configurazione in cui le schermate VB6 esistenti restano invariate, e nuove funzionalità vengono costruite in .NET per coesistere con esse. Sono possibili due direzioni.

• Chiamare componenti lato .NET da VB6: esponendo una classe .NET come COM, VB6 può referenziarla come un normale componente COM. Abbiamo spiegato come esporla in modo tipizzato anche su .NET 8 e versioni successive in “Chiamare in modo tipizzato una DLL .NET 8 da VBA — dscom e il TLB”; la stessa logica si applica anche quando chi chiama è VB6 anziché VBA.
• Chiamare asset lato VB6 da .NET: una DLL ActiveX costruita in VB6 può essere referenziata da .NET tramite interoperabilità COM. È utile quando si vuole mantenere la logica intatta come blocco unico, modernizzando prima solo le schermate verso .NET. Il vincolo dei 32 bit rimane comunque, quindi va trattato come un ponte per il periodo di migrazione, non come una soluzione permanente.

7.3 Separare i processi e integrarli tra loro

Ospitare vecchio e nuovo nello stesso processo tramite interoperabilità COM si scontra con vincoli legati al numero di bit (32/64) e alla propagazione dei guasti. Quando serve una nuova funzionalità a 64 bit, o si desidera isolare i guasti tra vecchio e nuovo, li si separa in processi distinti e li si integra tramite file, named pipe, comunicazione localhost e simili. Abbiamo riassunto le opzioni per l’integrazione tra processi in “Una tabella di decisione per l’IPC su Windows”, e un esempio concreto di ponte 32 bit→64 bit nel “Caso di studio di ponte COM”.

Il principio comune a tutti i pattern è questo: “concentrare il confine tra vecchio e nuovo in un unico punto, e fissare il formato dei dati che lo attraversano”. Se i confini si moltiplicano in modo frammentario per schermata o per funzionalità, il costo del periodo di coesistenza finisce per erodere il beneficio che la migrazione avrebbe dovuto portare.

8. Il linguaggio target della migrazione — C# o VB.NET?

Viene spontaneo pensare che “venendo da VB6, VB.NET sia la scelta naturale”, ma alla luce dell’attuale strategia linguistica di Microsoft non è così semplice.

La strategia linguistica ufficiale posiziona Visual Basic (VB.NET) come “un linguaggio accessibile e familiare che mantiene un design stabile”, dichiarando esplicitamente che, in linea di principio, le nuove funzionalità sono limitate al consumo (consumption-only), che non verrà aggiunta nuova sintassi e che non sarà esteso a nuovi tipi di carico di lavoro. Allo stesso tempo, si afferma che proseguiranno gli investimenti sugli scenari centrali come Windows Forms e le librerie, oltre ai miglioramenti dell’esperienza di sviluppo su Visual Studio.³

Letto dal punto di vista della migrazione, ciò si traduce così.

• Anche scegliendo VB.NET, gli scenari esistenti (applicazioni business WinForms) continueranno a funzionare senza problemi nel prossimo futuro. Per i team con molte persone esperte di VB6, dove la vicinanza sintattica riduce il costo di apprendimento, è una scelta ragionevole.
• Tuttavia, come base per tutto ciò che verrà scritto da zero d’ora in avanti, è consigliato C#. Il suo linguaggio e il suo ecosistema continuano a evolversi, e l’offerta di esempi, librerie e talenti è concentrata su C#. È una scelta fatta per non ripetere, tra dieci anni, il problema di “nessuno più in grado di mantenere VB6” sotto forma di “nessuno più in grado di mantenere VB.NET”.
• Come opzione intermedia, si può anche ricevere l’output dello strumento di conversione in VB.NET mentre si scrive il nuovo sviluppo in C#. In .NET, gli assembly di entrambi i linguaggi possono referenziarsi a vicenda, quindi mescolare i linguaggi di per sé non costituisce un ostacolo.

Per la scelta del framework dell’interfaccia (WinForms / WPF / WinUI), vedere “Una tabella di decisione per WinForms, WPF e WinUI”; per cosa verificare quando si migra direttamente verso .NET attuale anziché verso .NET Framework, vedere la “Checklist pre-migrazione da .NET Framework a .NET”. Salvo vincoli imposti da librerie referenziate, non c’è alcuna buona ragione per adottare deliberatamente .NET Framework 4.8 come nuovo target quando si migra da VB6.

9. Sintesi

• La risposta a “fino a quando funzionerà VB6” è: il runtime è supportato finché è supportata Windows stessa (Windows 11 incluso). Ma il supporto dell’IDE è terminato già nel 2008, quindi non esiste più alcun sostegno ufficiale per ricostruire o correggere il codice — una situazione asimmetrica.²¹
• La vera scadenza non è fissata dal sistema operativo, ma da se l’ambiente e le persone necessari per sistemare le cose siano ancora disponibili. Definite il piano di migrazione non dopo che qualcosa si è rotto, ma finché il vecchio sistema può ancora servire come “specifica vivente”.
• Esistono tre approcci: riscrittura completa, conversione automatica e migrazione graduale. Prima di sceglierne uno, fate l’inventario delle schermate, delle integrazioni esterne, dei controlli OCX, delle dichiarazioni API e delle regole di business che esistono solo nel codice.
• Per le migrazioni che non possono fermare il business, usate la priorità sullo strato dati, l’interoperabilità COM o la separazione dei processi per far coesistere vecchio e nuovo, e concentrate il confine in un unico punto.
• Per tutto ciò che viene scritto da zero, è consigliato C#. Il percorso di stabilità di VB.NET è una politica ufficiale³, e C# ha un vantaggio come base per la manutenzione a lungo termine.

Articoli correlati

• Prolungare la vita e migrare le applicazioni business VB6 / Access - una tabella di decisione tra mantenere, avvolgere e sostituire
• Come gestire oggi ActiveX / OCX - una tabella di decisione tra mantenere, avvolgere e sostituire
• Un caso di studio di ponte COM: chiamare una DLL a 64 bit da un’applicazione a 32 bit
• Chiamare in modo tipizzato una DLL .NET 8 da VBA - dscom e il TLB
• Checklist pre-migrazione da .NET Framework a .NET
• Una tabella di decisione per WinForms, WPF e WinUI
• Cos’è VBA - vincoli, prospettive future, casi in cui va sostituito e pattern di migrazione realistici

Aree di consulenza correlate

KomuraSoft LLC (合同会社小村ソフト) si occupa dell’inventario degli asset esistenti, incluso VB6, e della definizione della strategia di migrazione, della progettazione e implementazione di architetture di coesistenza tra vecchio e nuovo tramite ponti COM e separazione dei processi, oltre a progetti di sostituzione graduale verso .NET.

• Riutilizzo di asset esistenti e supporto alla migrazione
• Modifica e manutenzione di software Windows esistenti
• Sviluppo di applicazioni Windows
• Consulenza tecnica e revisione del design
• Contattaci

Link di riferimento

Articoli correlati

Articoli recenti con gli stessi tag per approfondire argomenti vicini.

Argomenti correlati

Queste pagine collocano l’argomento in un contesto più ampio di servizi e decisioni.

Servizi collegati all’argomento

L’articolo è direttamente collegato ai servizi seguenti.

Domande frequenti

Domande che ricorrono nelle consulenze sull’argomento dell’articolo.

Le applicazioni VB6 funzionano ancora su Windows 11?

Sì, rientrano nell'ambito del supporto. Secondo la politica di supporto Microsoft, il runtime VB6 (msvbvm60.dll e file correlati) rimane supportato finché è supportata la versione di Windows con cui viene distribuito, e l'elenco dei sistemi operativi coperti include Windows 11, Windows 10 e Windows Server 2025. Tale supporto, tuttavia, si limita alla gestione di regressioni gravi e problemi di sicurezza critici nelle applicazioni esistenti. Inoltre il runtime VB6 è esclusivamente a 32 bit e, su Windows a 64 bit, è supportato solo all'interno dell'ambiente di compatibilità WOW64.

Una migrazione da VB6 a .NET può essere completata usando solo uno strumento di conversione automatica?

È meglio partire dal presupposto che non sia possibile. Gli strumenti di conversione possono ridurre il lavoro di riscrittura delle definizioni delle schermate e della logica semplice, ma elementi come la gestione degli errori basata su On Error, il codice che dipende dal tipo Variant o dalle proprietà predefinite, i controlli ActiveX e le dichiarazioni delle API Win32 richiedono decisioni progettuali e correzioni manuali. Anziché mettere in produzione l'output grezzo dello strumento così com'è, occorre stimare l'intero progetto includendo il 'lavoro umano di rifinitura dopo la conversione' e stabilire in anticipo il metodo di verifica del risultato convertito, ad esempio l'esecuzione in parallelo o il confronto degli output.

Come target della migrazione conviene scegliere VB.NET o C#?

Per tutto ciò che viene scritto da zero è consigliato C#. La strategia linguistica di Microsoft posiziona Visual Basic (VB.NET) come un linguaggio che mantiene un design stabile, dichiarando esplicitamente che non verrà aggiunta nuova sintassi e che non sarà esteso a nuovi tipi di carico di lavoro. Gli investimenti sugli scenari esistenti come Windows Forms proseguono, quindi VB.NET non diventa inutilizzabile, ma come base per codice che dovrà essere mantenuto per il prossimo decennio, C# — il cui linguaggio ed ecosistema continuano a evolversi — offre un vantaggio in termini di reperibilità di competenze. I team con molti sviluppatori esperti di VB6 possono ragionevolmente scegliere di passare attraverso VB.NET, data la vicinanza sintattica.

Prima di una riscrittura completa, cosa bisogna fare per primo?

Bisogna fare un inventario prima ancora di scrivere una riga di codice. Nello specifico: un elenco delle schermate e dei report, un elenco delle integrazioni esterne (database, file, comunicazione seriale, altri sistemi), un elenco dei controlli OCX/ActiveX e dei componenti COM referenziati, un elenco delle dichiarazioni delle API Win32 (istruzioni Declare) e una ricognizione delle regole di business che esistono solo nel codice. I risultati di questo inventario rivelano molto spesso che una migrazione graduale — isolando solo una parte del sistema, oppure migrando prima lo strato dati — è più realistica di una riscrittura completa.

Profilo dell’autore

Pagina di presentazione dell’autore dell’articolo.

Go Komura

Rappresentante di KomuraSoft LLC

Specializzato nello sviluppo di software Windows, nella consulenza tecnica e nell’analisi dei malfunzionamenti, soprattutto nei progetti con sistemi esistenti e guasti difficili da riprodurre.