¿Hasta cuándo seguirán funcionando las aplicaciones VB6? — Estado del soporte del runtime y un camino práctico hacia la migración a .NET

«¿Hasta cuándo va a seguir funcionando este sistema en VB6?» es una de las preguntas más frecuentes en las consultas sobre sistemas existentes.

La respuesta es sorprendentemente clara: Microsoft ha publicado una política de soporte oficial. Sin embargo, su contenido es asimétrico: «el runtime seguirá funcionando durante bastante tiempo, pero el respaldo para el desarrollo ya no existe». Si no se entiende bien esta asimetría, se termina oscilando entre dos conclusiones extremas: «todavía funciona, así que no hay problema» y «hay que reescribirlo todo ahora mismo».

En este blog, en «Prolongar o migrar aplicaciones VB6 / Access de negocio — Tabla de decisión entre mantener, envolver y reemplazar», organizamos los criterios para decidir cómo tratar los activos en VB6. Este artículo es la continuación: después de decidir «reemplazar (migrar)», o para llegar a esa decisión, profundiza en cómo llevar a la práctica la migración de VB6 a .NET.

Términos usados en este artículo

Es probable que parte de las personas que lean esto no hayan conocido directamente la generación VB6, así que antes de nada aclaramos la terminología.

1. Conclusión inicial

• El IDE de VB6 (el entorno de desarrollo) dejó de tener soporte el 8 de abril de 2008. Ya no existe ningún medio con soporte para crear o mantener aplicaciones VB6, y Microsoft recomienda encarecidamente reemplazarlas por tecnología moderna.³
• En cambio, el runtime de VB6 está dentro del soporte «mientras dure el soporte de la versión de Windows con la que se distribuye». La lista de sistemas operativos cubiertos incluye Windows 11, Windows 10 y Windows Server 2025, entre otros, y el objetivo es que las aplicaciones existentes «simplemente funcionen» (It Just Works).⁴ Es decir, la respuesta a «¿hasta cuándo funciona?» es, si solo se trata de ejecutarlo, mientras dure el soporte de Windows.
• Sin embargo, ese alcance del soporte se limita a atender regresiones graves y problemas de seguridad críticos en aplicaciones existentes. Además, el runtime es exclusivamente de 32 bits, y en Windows de 64 bits solo se admite dentro del entorno WOW64.⁴
• El verdadero riesgo no es «que deje de funcionar», sino que deje de poder repararse. Conseguir y mantener el IDE es cada año más difícil, el soporte del proveedor de los OCX referenciados se acaba, y las personas que saben programarlo se van jubilando o cambiando de trabajo. Estos tres factores avanzan con independencia del período de soporte de Windows.
• Hay tres grandes enfoques para llevar a cabo la migración: reescritura completa, conversión automatizada y migración por etapas. Lo primero que hay que decidir no es el método, sino el inventario: hay que conocer el número de pantallas, las integraciones externas, los OCX y la cantidad de declaraciones de API antes de elegir el método.
• En cuanto al lenguaje de destino, para todo lo que se escriba de nuevo se recomienda C#. Microsoft ha declarado oficialmente que VB.NET (Visual Basic) sigue una vía de estabilidad, sin nueva sintaxis ni extensión a nuevas cargas de trabajo.⁵

2. La respuesta exacta a «¿hasta cuándo funciona?» — Cómo leer la política de soporte

La política de soporte de VB6 de Microsoft explica VB6 dividiéndolo en tres componentes.⁴

En la tabla de sistemas operativos cubiertos se indica explícitamente «runtime: con soporte» e «IDE: sin soporte» para Windows 11, Windows 10 y Windows Server 2012 a 2025.⁴

Hay tres puntos clave para interpretar esto.

En primer lugar, el soporte del runtime depende por completo del ciclo de vida de Windows. No existe una fecha independiente de «vencimiento del soporte del runtime de VB6»: el fin del soporte de la versión de Windows que se esté usando es, directamente, ese vencimiento.

En segundo lugar, el contenido del soporte se acerca más a una garantía de «seguir funcionando». Solo se atienden regresiones graves (cuando una actualización del sistema operativo rompe una aplicación existente) y problemas de seguridad críticos; no incluye investigaciones individuales ni mejoras de funciones.⁴

En tercer lugar, las aplicaciones VB6 solo podrán seguir existiendo como procesos de 32 bits. El runtime es exclusivamente de 32 bits, y en sistemas operativos de 64 bits solo tiene soporte dentro del entorno de emulación WOW64.⁴ En cuanto surge la necesidad de integrarse con una DLL o un SDK exclusivos de 64 bits, ya no es posible resolverlo dentro de un único proceso. La forma de salvar esta barrera se trata en «Ejemplo práctico de puente COM para llamar a una DLL de 64 bits desde una aplicación de 32 bits».

3. «Funcionar» y «poder mantenerse» son problemas distintos

Si solo se mira la política de soporte, puede parecer que «no hay que darse prisa». Pero en la práctica, el entorno de desarrollo y mantenimiento se deteriora antes que el entorno de ejecución.

• No se puede conseguir el IDE. El IDE de VB6 no tiene soporte en los sistemas operativos actuales, y mantener una vía oficial para obtenerlo e instalarlo es cada año más difícil. No es raro encontrar situaciones donde «solo hay un equipo en la empresa donde se puede reparar».
• El soporte del proveedor de los OCX de terceros se ha acabado. La propia política de soporte especifica que los controles de terceros son responsabilidad del proveedor.⁴ Es habitual que los OCX de cuadrículas o informes ya no se puedan conseguir, y en ese caso se aplica directamente lo que organizamos en «Cómo tratar hoy ActiveX / OCX».
• Deja de haber quien sepa programarlo. No es un problema de la especificación del lenguaje, sino de las personas. Casi no hay nuevos técnicos que aprendan VB6, así que el número de personas capaces de mantenerlo disminuye de forma constante.
• Los requisitos periféricos chocan con la barrera de los 32 bits. Los nuevos SDK de dispositivos, las bibliotecas de autenticación, la integración con la nube y otros elementos dan por sentado el uso de 64 bits y de .NET, y cada vez hay más requisitos que no se pueden incorporar a un proceso VB6.

Es decir, «hasta cuándo funciona» es solo la mitad del problema. La otra mitad es «si, la próxima vez que haga falta una corrección, todavía existirá un equipo capaz de hacerla». El plan de migración debe elaborarse mientras aún queden personas y entornos capaces de repararlo, no después de que ocurra un fallo.

4. Tabla de decisión de los métodos de migración

Incluso una vez decidido «reemplazar», hay margen en cómo llevarlo a cabo. A continuación organizamos los principales métodos.

La elección no depende solo del número de líneas de código. La propia Microsoft, junto con su guía oficial, recomienda recurrir a socios de actualización y migración (incluyendo proveedores de herramientas de migración)³, por lo que la conversión mecánica es una opción real. Sin embargo, lo que se necesita en común para cualquier método es el inventario del siguiente capítulo.

4.1 Qué es concretamente una «herramienta de conversión»

Hemos escrito «herramienta de conversión automatizada» como si fuera algo único, pero Microsoft publica una página que presenta por su nombre productos de socios para VB6. Se describen como «herramientas y soluciones gratuitas y de pago de socios que ayudan a completar mejor la migración de Visual Basic 6.0 a Visual Basic .NET», y se mencionan las tres siguientes.⁶

Lo anterior es un resumen de las descripciones publicadas en la página de Microsoft, y no constituye una recomendación ni una garantía por nuestra parte. La selección debe hacerse siempre después de probar con el propio código de la empresa. Los puntos que conviene revisar son los siguientes.

El último punto, «posibilidad de repetir», es un aspecto que se suele pasar por alto. Durante el período de migración, el lado VB6 seguirá recibiendo correcciones por incidencias. Si la herramienta solo permite una conversión única, esas correcciones habrá que introducirlas a mano tanto en el sistema nuevo como en el antiguo, de forma continua.

Por cierto, la práctica para cuando se elige «mantener el estado actual + documentación» (fijar el entorno de ejecución, copias de seguridad, cómo asumir el riesgo) se trata en el artículo anterior sobre VB6 / Access.

5. Inventario previo a la migración — Qué investigar antes que el código

La precisión de la estimación y de la elección del método depende de la precisión del inventario. Como mínimo, hay que catalogar lo siguiente.

1. Lista de pantallas e informes — número de formularios, pantallas realmente usadas (migrar pantallas que no se usan es un desperdicio), tipos de informes y su destino de salida (impresión directa en impresora o a través de Excel)
2. Lista de integraciones externas — base de datos (cuál de ADO/DAO/RDO y a qué se conecta), entrada y salida de archivos, comunicación serie o por sockets, llamadas a otros sistemas
3. Lista de referencias a OCX / ActiveX / COM — se puede extraer de forma mecánica a partir de las referencias del archivo de proyecto (.vbp). La disponibilidad de cada componente y si existe una alternativa influyen directamente en la elección del método
4. Lista de declaraciones de API de Win32 (sentencias Declare) — clasificar según el uso de cada API (impresión, lectura/escritura de INI, manejo de ventanas, etc.) si se puede sustituir por una función estándar de .NET
5. Reglas de negocio que solo existen en el código — redondeos, cierres de fecha, excepciones por cliente, etc. Los puntos donde «nadie sabe por qué está escrito así» son precisamente el caldo de cultivo de errores tras la migración
6. Existencia de medios de prueba — con qué se compara para confirmar que la migración es correcta. En la mayoría de los casos, el cotejo con la salida del sistema anterior (informes, CSV, contenido de la base de datos) es el medio de verificación más práctico

Este inventario no es en vano incluso si no se elige la reescritura completa. Al contrario, es habitual que sus resultados revelen enfoques para una migración por etapas, como descubrir que «pensábamos que hacía falta una reescritura completa, pero en realidad la lógica principal se puede trasladar al lado de la base de datos» o que «con migrar antes estas diez pantallas ya se salva la barrera de los 64 bits».

5.1 Qué significa «se puede extraer de forma mecánica» — Cómo identificar los componentes referenciados a partir de .vbp

En el tercer punto escribimos que «se puede extraer de forma mecánica a partir de las referencias del .vbp». A continuación mostramos el método en concreto.

El archivo de proyecto (.vbp) es un archivo de texto ASCII. La documentación oficial de Microsoft incluye un ejemplo de su contenido, y cada referencia configurada se registra como una línea con el siguiente formato.⁷

Type=Exe
Form=B_Form.frm
Reference=*\G{00020430-0000-0000-C000-000000000046}#2.0#0#..\..\..\WINDOWS\SYSTEM\STDOLE2.TLB#OLE Automation
Form=A_Form.frm
Module=CModule; C_Module.bas
Class=DClass; D_Class.cls
Startup="BForm"
Name="Project1"

El valor de Reference= está separado por # y sigue el orden GUID (identificador de la biblioteca de tipos) → versión → configuración regional → ruta del archivo → descripción (nombre de la biblioteca). En el ejemplo anterior, OLE Automation corresponde a la descripción. Los controles ActiveX (OCX) colocados en la pantalla se registran como líneas Object=, así que reuniendo estos dos tipos de línea se obtiene «la lista de componentes externos de los que depende este proyecto».

En sistemas con decenas de proyectos, se puede extraer todo de una vez con un script como el siguiente.

# Extrae de todos los .vbp bajo la carpeta las líneas de componentes referenciados y genera un CSV
# Entorno de ejecución: Windows PowerShell 5.1
Get-ChildItem -Path . -Filter *.vbp -Recurse | ForEach-Object {
    $project = $_.FullName
    Get-Content -LiteralPath $project | Where-Object {
        $_ -like 'Reference=*' -or $_ -like 'Object=*'
    } | ForEach-Object {
        $kind, $value = $_ -split '=', 2
        [pscustomobject]@{
            Project = $project
            # Reference = biblioteca de tipos referenciada / Object = control ActiveX colocado en la pantalla
            Kind    = $kind
            Entry   = $value
        }
    }
} | Sort-Object Kind, Entry | Export-Csv .\vb6-components.csv -NoTypeInformation -Encoding UTF8

Si se elimina duplicados en el CSV resultante y se ordena, en medio día se obtiene la lista de «de qué componentes COM depende realmente este sistema». Después solo queda ir rellenando, componente por componente, si está disponible, si tiene soporte del proveedor y si existe una alternativa en .NET. Esta tabla se convierte tal cual en la base de la elección de método y la estimación del capítulo 4.

Con la misma lógica, la lista de sentencias Declare también se puede generar recogiendo las líneas que contienen Declare en .bas / .frm / .cls. Lo único del inventario que debe depender del trabajo manual son las «reglas de negocio que solo existen en el código»; todo lo demás se puede automatizar casi por completo.

5.2 Cómo estimar el esfuerzo y el plazo

Una cifra como «tantos días por pantalla» puede variar fácilmente en un orden de magnitud según la complejidad de la pantalla, si tiene OCX, la densidad de la lógica de negocio y el rigor de las pruebas exigidas. Traer directamente cifras de casos de otras empresas no da en el blanco. En su lugar, aquí dejamos el procedimiento para generar cifras propias.

1. Contar. Con el inventario, fijar el número de pantallas, informes, integraciones externas, tipos de OCX, sentencias Declare y tablas.
2. Clasificar por dificultad. Dividir las pantallas en unos tres niveles (listados/consultas simples; pantallas con entrada y validación; pantallas con cuadrículas o vista previa de informes).
3. Migrar realmente una pantalla de cada nivel (piloto). Medir el tiempo real que incluye diseño, implementación, pruebas unitarias y el cotejo de la salida con el sistema anterior. Esto se convierte en el coste unitario de la estimación.
4. Multiplicar y sumar. Multiplicar el coste unitario obtenido en el paso 3 por el número de pantallas del paso 2 y sumarlo todo.
5. Añadir una partida aparte. La parte común (autenticación, registro, base de impresión, distribución, configuración del entorno) y el tiempo de descifrar las «reglas de negocio que solo existen en el código» no son proporcionales al número de pantallas. Una estimación a la que le falte esta partida aparte siempre se quedará corta.
6. Si no cuadra, volver al método. Si la medición real del piloto resulta mucho peor de lo previsto, no es un error de estimación, sino una señal de que el método elegido es incorrecto. Hay que volver al capítulo 4 y elegir de nuevo entre reescritura completa, conversión automatizada y migración por etapas.

El punto clave es basar la estimación en la medición real del propio piloto, no en cifras de casos de otras empresas. Conviene pensar en el piloto no como un gasto, sino como una inversión que compra precisión en la estimación.

6. Principales puntos de incompatibilidad entre VB6 y .NET

VB6 y VB.NET/C# son lenguajes más distantes entre sí de lo que sugiere su nombre. Tanto en la conversión mecánica como en la reescritura manual, las siguientes diferencias siempre exigen decisiones de diseño.

Lo importante aquí es no dejarse abrumar por la cantidad de incompatibilidades y concluir que la única opción es la reescritura completa. Al contrario, el propio hecho de que los activos del lado izquierdo de la tabla (VB6) sigan funcionando correctamente hoy es, en sí mismo, la mejor especificación para la migración. En la práctica, lo más seguro es hacer funcionar el sistema antiguo en paralelo como «especificación viva» y avanzar cotejando las salidas.

7. Patrones prácticos de migración por etapas

Cuando la migración se hace sin detener la operación, la configuración de convivencia entre el sistema nuevo y el antiguo es la clave. A continuación presentamos tres patrones representativos. En una palabra, la diferencia entre ellos es «dónde se coloca el límite entre lo nuevo y lo antiguo».

flowchart TB
    accTitle: Patrones de convivencia entre VB6 y .NET en la migración por etapas
    accDescr: Diagrama que muestra tres patrones de migración por etapas: migrar primero la capa de datos con la base de datos como límite, conectar mediante interoperabilidad COM dentro del mismo proceso, y separar en procesos distintos comunicados por IPC
    subgraph P1["7.1 Migrar primero la capa de datos — el límite es la base de datos"]
      A1["Aplicación VB6 — solo se cambia el destino de conexión"] --> DB["Base de datos tras la migración — SQL Server, etc."]
      A2["Nuevas pantallas en .NET — se añaden progresivamente"] --> DB
    end
    subgraph P2["7.2 Conectar mediante interoperabilidad COM — el límite es la interfaz COM, mismo proceso"]
      B1["Aplicación VB6 — proceso de 32 bits"] --- B2["Interfaz COM"]
      B2 --- B3["Componente .NET — debe compilarse en 32 bits"]
    end
    subgraph P3["7.3 Separar en procesos distintos — el límite es la IPC, proceso distinto"]
      C1["Aplicación VB6 — proceso de 32 bits"] --- C2["Canalización con nombre / archivo / comunicación localhost"]
      C2 --- C3["Aplicación .NET — puede ser de 64 bits"]
    end

Figura 1: Los tres patrones de migración por etapas — dónde colocar el límite entre lo nuevo y lo antiguo

7.1 Migrar primero la capa de datos

Es una configuración en la que primero se traslada la información de la aplicación VB6 desde archivos Access o un formato propio hacia SQL Server u otro motor, y el lado VB6 sigue funcionando cambiando únicamente el destino de conexión. Si los datos ya están modernizados, las nuevas pantallas (del lado .NET) pueden ir aumentando por etapas mirando la misma base de datos. Para el procedimiento concreto relacionado con Access, consulte el capítulo de upsizing del artículo anterior.

7.2 Crear nuevas funciones y pantallas en .NET y conectarlas mediante interoperabilidad COM

Es una configuración en la que las pantallas VB6 existentes se dejan tal cual y las nuevas funciones se crean en .NET para que convivan con ellas. Hay dos direcciones posibles.

• Llamar desde VB6 a un componente del lado .NET: si se expone una clase de .NET como COM, se puede referenciar desde VB6 como un componente COM normal. Explicamos cómo exponerla de forma tipada incluso en .NET 8 o posterior en «Cómo usar una DLL de .NET 8 tipada desde VBA — exposición COM y dscom TLB», y el planteamiento es el mismo aunque quien llame sea VB6.
• Llamar desde .NET a un activo del lado VB6: una DLL ActiveX creada en VB6 se puede referenciar desde .NET mediante interoperabilidad COM. Se usa cuando se quiere aprovechar la lógica tal cual, en bloque, y pasar a .NET solo la pantalla primero. Sin embargo, como persiste la restricción de los 32 bits, hay que asumirlo como un puente durante el período de migración, no como una solución permanente.

La implementación del puente, en su configuración mínima, son unas pocas líneas. Primero, la dirección de llamar desde VB6 a un componente del lado .NET. Se añaden atributos a la interfaz y a la clase que se quieren exponer.⁸

// Lado .NET (C# / .NET 8) — se expone como COM para poder llamarlo desde VB6
using System.Runtime.InteropServices;

[ComVisible(true)]
[Guid("fe103d6e-e71b-414c-80bf-982f18f6c1c7")]   // IID de la interfaz. Hay que generarlo siempre de nuevo
[InterfaceType(ComInterfaceType.InterfaceIsIDispatch)]
public interface ITaxCalculator
{
    decimal CalcTax(decimal amount);
}

[ComVisible(true)]
[Guid("9f35b6f5-2c05-4e7f-93aa-ee087f6e7ab6")]   // CLSID de la clase. Este también hay que generarlo de nuevo
[ClassInterface(ClassInterfaceType.None)]
[ProgId("Komura.TaxCalculator")]
public class TaxCalculator : ITaxCalculator
{
    public decimal CalcTax(decimal amount) => Math.Floor(amount * 0.1m);
}

Se indica en el csproj que genere el host COM, se compila, y el .comhost.dll resultante se registra desde un símbolo del sistema con permisos de administrador.⁸

<PropertyGroup>
  <EnableComHosting>true</EnableComHosting>
</PropertyGroup>

regsvr32 TaxLib.comhost.dll

Del lado de quien llama, en VB6, es igual que con cualquier objeto COM habitual.

' Lado VB6 — llamada con enlace tardío usando el ProgId
Dim calc As Object
Set calc = CreateObject("Komura.TaxCalculator")
MsgBox calc.CalcTax(12345)
Set calc = Nothing

Aquí hay dos trampas en las que siempre se tropieza. Ambas están descritas en la documentación oficial.⁸

• De forma predeterminada, solo se puede usar desde clientes de 64 bits. A diferencia de la época de .NET Framework, en .NET Core / .NET 5 y posteriores, aunque se compile como «Any CPU», el *.comhost.dll resultante es de 64 bits por defecto. Como VB6 es un proceso de 32 bits, no puede cargarlo tal cual (es exactamente la restricción de WOW64¹). Ajuste la configuración de compilación para que se genere una versión de 32 bits de comhost.dll.
• No se admite la distribución autocontenida (self-contained) de componentes COM. Solo está soportada la distribución dependiente del framework. Decida primero el modo de distribución antes de diseñar.

Por otro lado, la dirección de llamar desde .NET a un activo de VB6 consiste simplemente en añadir la DLL ActiveX creada en VB6 como referencia COM.

// Lado .NET — llama a una DLL ActiveX creada en VB6 mediante referencia COM
// Preparación previa: añadir una "referencia COM" al proyecto y compilar en 32 bits (x86)
var legacy = new LegacyBiz.OrderCalc();      // Clase escrita en VB6
decimal total = legacy.CalcTotal(orderId);   // La lógica de negocio permanece del lado VB6
Marshal.ReleaseComObject(legacy);            // El objeto COM se libera de forma explícita

En este caso también es necesario compilar el lado .NET que hace la llamada en 32 bits (x86). Esto se debe a que la DLL ActiveX de VB6 es una DLL de 32 bits, y un proceso de 64 bits no puede cargar una DLL de 32 bits para ejecutarla.¹ Un requisito como «quiero incorporar nuevas funciones de 64 bits pero también quiero llamar a la lógica de VB6» ya no es viable dentro de un mismo proceso llegados a este punto. Aquí es donde entra en juego el apartado 7.3.

7.3 Separar en procesos distintos y conectarlos

Cuando se hacen convivir en el mismo proceso mediante interoperabilidad COM, el número de bits (32/64) y el arrastre de fallos se convierten en restricciones. Cuando se necesitan nuevas funciones de 64 bits, o se quiere aislar los fallos entre el sistema nuevo y el antiguo, se separan en procesos distintos y se conectan mediante archivos, canalizaciones con nombre, comunicación localhost, etc. Las opciones de comunicación entre procesos están recogidas en la «Tabla de decisión de IPC en Windows», y un ejemplo práctico del puente de 32 a 64 bits en el «Ejemplo práctico de puente COM».

El principio común a todos los patrones es «concentrar el límite entre lo nuevo y lo antiguo en un solo punto y fijar el formato de los datos que lo cruzan». Si los límites se multiplican de forma dispersa por pantalla o por función, el coste del período de convivencia acaba anulando los beneficios de la migración.

8. El lenguaje de destino — ¿C# o VB.NET?

Se suele pensar que «viniendo de VB6, lo natural es VB.NET», pero si se tiene en cuenta la estrategia de lenguajes actual de Microsoft, la cosa no es tan simple.

En la estrategia oficial de lenguajes, Visual Basic (VB.NET) se posiciona como «un lenguaje claro y accesible que mantiene un diseño estable», y se declara explícitamente la política de que las funciones nuevas, en principio, serán solo de consumo (consumption-only), sin añadir nueva sintaxis, y sin extenderse a nuevas cargas de trabajo. Por otro lado, se indica que continuará la inversión en escenarios centrales como Windows Forms y las bibliotecas, así como la mejora de la experiencia de desarrollo en Visual Studio.⁵

Leído esto desde el punto de vista de la migración, resulta lo siguiente.

• Aunque se elija VB.NET, los escenarios existentes (aplicaciones de negocio en WinForms) seguirán funcionando sin problemas por el momento. Es una elección razonable para equipos con muchas personas con experiencia en VB6, donde la cercanía de la sintaxis reduce el coste de aprendizaje.
• Sin embargo, como base de los activos que se escriban de nuevo a partir de ahora, se recomienda C#. Su lenguaje y su ecosistema siguen evolucionando, y la disponibilidad de ejemplos, bibliotecas y personal también se concentra en C#. Es una elección para no repetir dentro de diez años, con VB.NET, el mismo problema de «no hay personal de mantenimiento» que hoy existe con VB6.
• Como solución intermedia, también se puede optar por una configuración en la que la salida de la herramienta de conversión se reciba en VB.NET y el desarrollo nuevo se escriba en C#. En .NET, los ensamblados de ambos lenguajes se pueden referenciar mutuamente, así que mezclar lenguajes no supone en sí mismo un obstáculo.

Para la elección del framework de pantallas (WinForms / WPF / WinUI), consulte la «Tabla de decisión entre WinForms, WPF y WinUI»; para los puntos a verificar al migrar directamente al .NET actual en lugar de a .NET Framework, consulte la «Lista de verificación previa a la migración de .NET Framework a .NET». No hay ninguna razón, salvo restricciones de bibliotecas referenciadas, para adoptar deliberadamente .NET Framework 4.8 como nueva plataforma al migrar desde VB6.

9. Resumen

• La respuesta a «¿hasta cuándo funciona VB6?» es que el runtime está dentro del soporte mientras dure el soporte de Windows (incluido Windows 11). Sin embargo, el IDE dejó de tener soporte en 2008, por lo que se trata de una situación asimétrica en la que ya no existe un respaldo oficial para reconstruirlo o repararlo.⁴³
• El verdadero plazo no lo determina el sistema operativo, sino si quedan entorno y personas capaces de repararlo. El plan de migración debe elaborarse mientras el sistema antiguo todavía sirva como «especificación viva», no después de que ocurra un fallo.
• Hay tres enfoques para llevarlo a cabo: reescritura completa, conversión automatizada y migración por etapas. Antes de elegir el método, hay que hacer el inventario de pantallas, integraciones externas, OCX, declaraciones de API y reglas de negocio que solo existen en el código.
• En una migración que no detiene la operación, se hace convivir el sistema nuevo y el antiguo mediante alguna de estas vías: capa de datos primero, interoperabilidad COM o separación de procesos, y se concentra el límite en un solo punto.
• Para la parte que se escriba de nuevo, se recomienda C# como lenguaje. La vía de estabilidad de VB.NET es una política oficial⁵, y como base para el mantenimiento a largo plazo, C# tiene ventaja.

9.1 El siguiente paso — Qué hacer en la primera semana

Esta es una lista de comprobación con tareas concretas para no quedarse solo en «estudiar la migración». No se escribe ni una sola línea de código.

• Confirmar dónde está el conjunto completo del código fuente. Cotejarlo con el ejecutable de producción más reciente para verificar que ese código fuente es realmente la versión vigente (como se indica en el capítulo 3, si esto no coincide, todo lo posterior será en vano)
• Confirmar en qué equipos funciona el IDE de VB6. Cuántos hay, qué sistema operativo tienen, y si se podrían reconstruir en caso de avería
• Catalogar los componentes referenciados a partir de .vbp. Ejecutar directamente el script del capítulo 5 y generar el CSV
• Añadir y rellenar tres columnas —«disponibilidad / soporte del proveedor / alternativa en .NET»— para cada componente de la lista. Las celdas que no se puedan rellenar son los puntos difíciles de la migración
• Contar las pantallas y los informes. Y a continuación, confirmar con el personal del negocio cuáles son las «pantallas que realmente se usan». El esfuerzo cambia mucho con solo no migrar las pantallas que no se usan
• Extraer las sentencias Declare de forma transversal. Clasificarlas por uso y determinar si se pueden sustituir por una función estándar de .NET
• Decidir a qué se va a comparar la verificación. Fijar de antemano un único criterio (informes, CSV, contenido de la base de datos) con el que comprobar la corrección tras la migración
• Confirmar si hay requisitos que tienen problemas por los 32 bits. Si los hay, ese único punto se convierte en la condición prioritaria de la elección del método

Con esto ya se dispone de lo necesario para avanzar hacia la elección de método del capítulo 4 y el piloto del capítulo 5.

Artículos relacionados

• Prolongar o migrar aplicaciones VB6 / Access de negocio - Tabla de decisión entre mantener, envolver y reemplazar
• Cómo tratar hoy ActiveX / OCX - Tabla de decisión entre mantener, envolver y reemplazar
• Ejemplo práctico de puente COM para llamar a una DLL de 64 bits desde una aplicación de 32 bits
• Cómo usar una DLL de .NET 8 tipada desde VBA - Exposición COM y dscom TLB
• Lista de verificación previa a la migración de .NET Framework a .NET
• Tabla de decisión entre WinForms, WPF y WinUI
• Qué es VBA - Límites, futuro, cuándo conviene reemplazarlo y patrones prácticos de migración

Áreas de consultoría relacionadas

KomuraSoft LLC se ocupa del inventario de activos existentes —incluido VB6— y de la organización de la política de migración, del diseño e implementación de configuraciones de convivencia entre lo nuevo y lo antiguo mediante puentes COM y separación de procesos, y de la sustitución progresiva hacia .NET.

• Aprovechamiento de activos existentes y apoyo a la migración
• Modificación y mantenimiento de software Windows existente
• Desarrollo de aplicaciones Windows
• Consultoría técnica y revisión de diseño
• Contacto

Referencias

Artículos relacionados

Artículos recientes con las mismas etiquetas para profundizar en temas cercanos.

Temas relacionados

Estas páginas sitúan el tema en un contexto más amplio de servicios y decisiones.

Servicios relacionados con este tema

El artículo está directamente relacionado con los siguientes servicios.

Preguntas frecuentes

Preguntas habituales en las consultas sobre el tema del artículo.

¿Las aplicaciones VB6 siguen funcionando en Windows 11?

Sí, están dentro del alcance del soporte. Según la política de soporte de Microsoft, el runtime de VB6 (msvbvm60.dll y archivos relacionados) permanece compatible mientras lo esté la versión de Windows con la que se distribuye, y la lista de sistemas operativos cubiertos incluye Windows 11, Windows 10 y Windows Server 2025. Sin embargo, ese soporte se limita a atender regresiones graves y problemas de seguridad críticos en aplicaciones existentes. Además, el runtime de VB6 es exclusivamente de 32 bits, y en Windows de 64 bits solo se admite dentro del entorno de compatibilidad WOW64.

¿Se puede completar una migración de VB6 a .NET solo con una herramienta de conversión automatizada?

Conviene asumir que no se puede. Las herramientas de conversión pueden reducir el trabajo de reescribir definiciones de pantalla y lógica sencilla, pero cosas como el manejo de errores basado en On Error, el código que depende del tipo Variant o de propiedades predeterminadas, los controles ActiveX y las declaraciones de API de Win32 requieren decisiones de diseño y correcciones humanas. En lugar de llevar la salida bruta de la herramienta directamente a producción, hay que estimar el proyecto completo incluyendo el 'trabajo humano de acabado tras la conversión', y decidir de antemano el método para verificar el resultado convertido, por ejemplo mediante operación en paralelo o comparación de salidas.

¿Conviene elegir VB.NET o C# como destino de la migración?

Para todo lo que se escriba de nuevo, se recomienda C#. La estrategia de lenguajes de Microsoft posiciona a Visual Basic (VB.NET) como un lenguaje que mantiene un diseño estable, y declara explícitamente que no se añadirá nueva sintaxis ni se extenderá a nuevos tipos de carga de trabajo. La inversión en escenarios existentes como Windows Forms continúa, por lo que VB.NET no se vuelve inutilizable, pero como base para código que habrá que mantener durante la próxima década, C# —cuyo lenguaje y ecosistema siguen evolucionando— tiene ventaja a la hora de conseguir talento. Los equipos con muchos desarrolladores con experiencia en VB6 pueden optar razonablemente por pasar por VB.NET dada la cercanía de su sintaxis.

Antes de una reescritura completa, ¿qué hay que hacer primero?

Hay que hacer un inventario antes de escribir una sola línea de código. En concreto: una lista de pantallas e informes, una lista de integraciones externas (bases de datos, archivos, comunicación serie, otros sistemas), una lista de los controles OCX/ActiveX y componentes COM referenciados, una lista de declaraciones de API de Win32 (instrucciones Declare), y un relevamiento de las reglas de negocio que solo existen en el código. Los resultados de este inventario muestran muy a menudo que una migración por etapas —extrayendo solo una parte del sistema, o migrando primero la capa de datos— es más realista que una reescritura completa.

Perfil del autor

Página de presentación del autor del artículo.

Go Komura

Representante de KomuraSoft LLC

Especializado en desarrollo de software para Windows, consultoría técnica e investigación de fallos, sobre todo en proyectos con sistemas existentes y errores difíciles de reproducir.